EDIT: The text below turned out to be unnecesarily long-winded. Feel free to skip it, as it’s not like this is such an important topic. I’ll leave it untouched, but in a way I wish I hadn’t written it. It feels weird having strong feelings towards a text file content format
[quote=28251:@Dave S]SInce when does EXCEL not recognize “,” in a CSV? By DEFAULT that it the delimiter for a CSV File
A PROPER CSV doesn’t have to worry about regional setting… since IF there are number containing “,” they had better be inside of QUOTES or they do not meet the proper CSV requirements[/quote]
While CSV is a convenient shorthand for a type of file content definition, there is not a PROPER CSV format, as CSV is not a format. The “csv” extension wasn’t even common until Excel “formalized” it (although comma-separated lists have been common since the days of punch cards).
Even so, one of the most common conventions of “CSV” is that integers and floats are never double-quoted, strings (which might have the separator) usually are (except for Excel, which doesn’t double-quote anything ).
Since CSV is, in the end, a TEXT format, there’s no abstraction of value and format. In european countries this usually means decimal numbers are shown as 123,45 instead of 1234.45 and programs will dutifully export floats unquoted and with commas.
So, if normal CSV (as understood by Excel, if we want to go that way) doesn’t quote floats or integers and the values saved are regionalized, then it becomes immediately obvious that “comma” can’t be used as a separator in places where floats contain commas for decimals. In these regions Excel exports (and imports) using semicolon by default, just as it uses semicolons in formulas.
I wish CSV was an actual format, but it isn’t. And the place where CSVs are used the most by end users, Excel, agrees with me here: Floats and integers are never double-quoted, regardless of the regional setting, but the default separator is changed.
I personally prefer to use tab or pipe separated fields, myself. Always thought using a character as common as a comma was stupid after 1990.
Wikipedia also agrees with me, for what that is worth: A comma-separated values (CSV) (also sometimes called character-separated values, because the separator character does not have to be a comma)
The original CSV format quote fields (which means commas were forbidden) and when it “evolved” (not as a standard, but out of common sense) double-quotes were added to strings, not to all fields or to fields whose content has a comma, since space and memory was at a premium. It was also designed around 7-bit ASCII and period decimal separator since it was american-centric (not a bad thing, in itself).
The CSV format, nowadays is a bit like setting up modem handshake settings: If CSV is agreed, then other things need to be agreed along with it: Line terminators, encoding and separator, quoting and escape characters.
The 2005 RFC4180 defining CSV, while well-intentioned, comes almost 50 years after the format has been in common use, but recognizes the chaotic nature of this “non-standard standard” by leaving pretty much everything optional (and the only thing it sets as a rule, which is that quotes within quoted fields should be escaped by prepending another quote, is summarily ignored by every program I have encountered in the last 30 years).
IANA corrected all the glaring ommissions and limitations of CSV by pretending it didn’t exist and defining the MIME type “text/tab-separated-values” only, but the Internet Society brought this hellspawn back in 2005 by requesting registration of “text/csv” in the RFC above.
Agreeing on using CSV is like agreeing on going to watch a movie with others. Even when agreed several things still need to be defined and confirmed.