Почему запятая является плохим разделителем / разделителем записей в файлах CSV?

Я читал эту статью, и мне любопытно найти правильный ответ на этот вопрос.

Единственное, что мне приходит в голову, это, возможно, то, что в некоторых странах десятичный разделитель - это запятая, и это может быть проблемой при обмене данными в CSV , но я не совсем уверен в своем ответе.

CSV format specification is defined in RFC 4180. This specification was published because

there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files

Unfortunately, since 2005 (date of publishing the RFC), nothing has changed. We still have a wide variety of implementations. The general approach defined in RFC 4180 is to enclose fields containing characters such as commas in quotation marks, this recommendation however is not always meet by different software.

The problem is that in various European locales comma character serves as the decimal point, so you write 0,005 instead of 0.005. Yet in other cases, commas are used instead of spaces to signal digit groups, e.g. 4,000,000.00 (see here). In both cases using commas would possibly lead to errors in reading data from csv files because your software does not really know if 0,005, 0,1 are two numbers or four different numbers (see example here).

Last but not least, if you store text in your data file, then commas are much more common in text than, for example, semicolons, so if your text is not enclosed in quotation marks, that such data can also be easily read with errors.

Nothing makes commas better, or worse field separators as far as CSV files are used in accordance with recommendations as RFC 4180 that guard from the problems described above. However if there is a risk of using the simplified CSV format that does not enclose fields in quotation marks, or the recommendation could be used inconsistently, then other separators (e.g. semicolon) seem to be safer approach.

Technically comma is as good as any other character to be used as a separator. The name of the format directly refers that values are comma separated (Comma-Separated Values).

The description of CSV format is using comma as an separator.

Any field containing comma should be double-quoted. So that does not cause a problem for reading data in. See the point 6 from the description:

6. Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes.

For example the functions read.csv and write.csv from R by default are using comma as a separator.

In addition to being a digit separator in numbers, it is also forms part of address (such as customer address etc) in many countries. While some countries have short well-define addresses, many others have, long-winding addresses including, sometimes two commas in the same line. Good CSV files enclose all such data in double quotes. But over-simplistic, poorly written parsers don't provide for reading and differentiating such. (Then, there is the problem of using double quotes as part of the data, such as quote from a poem).

While @Tim s answer is correct - I would like to add that "csv" as a whole has no common standard - especially the escaping rules are not defined at all, leading to "formats" which are readable in one program, but not another. This is excarberated by the fact that every "programmer" under the sun just thinks "oooh csv- I will build my own parser!" and then misses all of the edge cases.

Moreover, csv totally lacks the abillity to store metadata or even the data type of a column - leading to at several documents which you must read to unterstand the data.

If you can ditch the comma delimiter and use a tab character you will have much better success. You can leave the file named .CSV and importing into most programs is usually not a problem. Just specify TAB delimited rather than comma when you import your file. If there are commas in your data you WILL have a problem when specifying comma delimited as you are well aware.

ASCII provides us with four "separator" characters, as shown below in a snippet from the ascii(7) *nix man page:

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

This answer provides a decent overview of their intended usage.

Of course, these control codes lack the human-friendliness (readability and input) of more popular delimiters, but are acceptable choices for internal and/or ephemeral exchange of data between programs.

The problem is not the comma; the problem is quoting. Regardless of which record and field delimiters you use, you need to be prepared for meeting them in the content. So you need a quoting mechanism. AND THEN you need a way for the quoting character(s) to appear too.

Following the RFC 4180 standard makes everything simpler for everybody.

I have personally had to write a script to probably fix the output from a program that got this wrong, so I am a bit militant about it. "probably fix" means that it worked for MY data, but I can see situations where it would fail. (In that program's defense, it was written before the standard.)