3 ms·

That's not a problem inherent to CSV the format, though, any more than using Word to edit JSON means smart quotes are a problem with JSON. It's about knowing or

• qayxc 5y ago
  But the behaviour isn't unexpected at all, e.g. the user wanted to store a number in column 3 and that's exactly what's the tool did. The behaviour is both expected and reproducible, the issue is that it's not communicated by the format. The problem arises from the fact that CSV doesn't contain any metadata so while the same tool reads and writes the same data, the results will be different because the format doesn't specify what a number look like. The formats proposed in the article don't have this problem because they specify both the type and the formatting of the file content so there's no confusion. That's the difference. JSON in particular simply cannot have this problem (though it's not a suggested solution): a number has a well-defined format and that's that. So do strings. This is not the case with CSV: Number,Also a number,A String 1.0,1e15,"Hello there!" "1,0",1e15,"Bienvenue á la maison!" The first row is what you'd expect from a customer in Ireland and the second row might be sent from someone in Switzerland. Both parties agreed to use comma-separated files for data exchange and quoted strings, yet importing the first row using a French locale would fail to parse the first number and same goes for the second row and an English locale. Neither row contains unexpected or malformed data from the respective user's POV. And that's the problem with CSV.