3 ms·

CSV is totally fine, and I don't understand why people have such an issue with the format. It is very simple, here is the entire specification: the file should

CSV is totally fine, and I don't understand why people have such an issue with the format. It is very simple, here is the entire specification: the file should be encoded in UTF-8, and fields are separated by the , character. Fields may be quoted with ". If a field contains any of [",\r\n] then it must be quoted. The quote process is: replace all " characters in the field with "" and then surround the field with ". I would expect a competent programmer to be able to implement this specification as an interview question! The existence of software that produces braindead CSVs is beside the point. Don't use that software. Just do the above and everything will work.

stinos 6y ago
here is the entire specification: the file should be encoded in UTF-8, and fields are separated by the , character This exactly is part of the problem: how many people do you think would come up with this specific specification? You do realize in real life CSV gets used for anything which is plain text and separated and perhaps even quoted? Also 'should be' UTF-8? By what authority? The existence of software that produces braindead CSVs is beside the point. No, it is not. Especially not because there's so much software. And because it's not braindead, it's just doing something else. Which is bascially fine since there's no standard. Just do the above and everything will work. Yes, in your personal bubble. Beyond that it's totally insufficient.
panopticon 6y ago
The answer to your first question is in your last paragraph. CSV is an abysmal format for data exchange because the standards are weak and implementations are extremely varied. If you're writing an (en|de)coder for a specific or limited target, then sure it's fine. Otherwise I would steer clear of it.
perl4ever 6y ago
Lots of people like to use backslash escaping, and you are so used to it that you used it in your spec even though it leaves the ambiguity of whether \n and \r are literal or the LF and CR characters. I feel like it's perfectly expressing how it "contains the seeds of its own destruction". How much data expresses a double quote as "\"" instead of """"? It would be easy to use CSV if you never did any data interchange with it.

stinos 6y ago

here is the entire specification: the file should be encoded in UTF-8, and fields are separated by the , character This exactly is part of the problem: how many people do you think would come up with this specific specification? You do realize in real life CSV gets used for anything which is plain text and separated and perhaps even quoted? Also 'should be' UTF-8? By what authority? The existence of software that produces braindead CSVs is beside the point. No, it is not. Especially not because there's so much software. And because it's not braindead, it's just doing something else. Which is bascially fine since there's no standard. Just do the above and everything will work. Yes, in your personal bubble. Beyond that it's totally insufficient.

panopticon 6y ago

The answer to your first question is in your last paragraph. CSV is an abysmal format for data exchange because the standards are weak and implementations are extremely varied. If you're writing an (en|de)coder for a specific or limited target, then sure it's fine. Otherwise I would steer clear of it.

perl4ever 6y ago

Lots of people like to use backslash escaping, and you are so used to it that you used it in your spec even though it leaves the ambiguity of whether \n and \r are literal or the LF and CR characters. I feel like it's perfectly expressing how it "contains the seeds of its own destruction". How much data expresses a double quote as "\"" instead of """"? It would be easy to use CSV if you never did any data interchange with it.