Excel is quite often useless with CSV, even if its contents are pure ASCII. Whether or not Excel will open a standard CSV file delimited with comma's (as per RFC 4180) properly also depends on the locale of the computer running Excel. So if you run Excel on Windows with a Dutch locale, it will by default fail to open the CSV normally and jam all its contents in one cell, because it expects a semi-colon as delimiter instead of a comma. To open standard CSV you have to import the file instead.
Someone at some point decided that the Dutch use semi-colons instead of commas to delimit tabulated data, and decided to apply this logic to CSV files as well. I would like to know the history behind such a decision! Switch your locale to English US, and it opens normally.
LibreOffice just opens the CSV and asks the user to confirm the delimiter and what not regardless of locale.
Yes, this is so horrible.
As a workaround I sometimes put "sep=," on the first line of the spreadsheet. This forces Excel to use the comma as a separator, regardless of the locale.
The downside of course is that every other tool on the planet shows the extra row, so it's not very useful.
I suffer from the reverse problem. I need to ingest CSV files produced by excel in various locales. Or is there some generally available alternative to excel that would produce valid RFC CSVs?
RFC 4180¹ has been in existence since 2005 and seems perfectly straight forward. The basic syntax is two pages of very understandable text. I hold that to be the definition of valid CSV.
CSV libraries tend to adhere to it (and often support additional options encountered in the wild as well); e.g., Apache Commons CSV².
Seems is the correct word here. Alas, it's one of multiple attempts at standardization ("I hold it" - good thing about standards is there's so many to choose from, as this RFC acknowledges), ignores charset altogether (a flaw of CSV, not of standard), and anything touched by MSO is unlikely to fit this. So, while useful for emitting CSV, no use at all for processing.
Probably, but what will it achieve realistically? This (both what OP reports and this locale-dependent behaviour) is likely a WONTFIX type of bug, as there are workarounds (don't double-click to open normal CSV if you are in a locale where different delimiters are used, use import; don't start your CSV files with "ID"; etc.).
A VBA import routine will always run in the US locale. However, csv files containing dates formatted according to other locales will have their days and months switched as long as the day is not bigger than 12.
Exactly. Unfortunately, double-clicking the file does not trigger that dialogue. You would be surprised how many IT-staffers simply give up at that point („Can I get the raw data?”, „Sure, here is the automatically generated CSV dump.”, „I can't open it…”).
I can't remember the last time double clicking on a CSV file did the right thing in Excel. I always use the clunky import dialog. Even then it often requires a few tries before I get what I want.
For an operation that is done literally millions of times around the world each year, Microsoft seems to pretend that it's some bizarre corner case. I know CSV is a messy format, but you can do better Microsoft. Even a week or two of work on that could make it much much better.
Surprisingly, Excel can import CSV from UTF8 with BOM (at least new versions of Excel). However, be careful, as Ctrl+S will save it in some arbitrary codepage and you'll probably end up with a document like:
ID,Name
1,??? ????
2,Kevin Dub?is
so take care to always save such documents as .xmlx.
(If you convert them to your local codepage and import that - when at all relevant - it will be saved in the local codepage, so less risk of data loss.)
> Surprisingly, Excel can import CSV from UTF8 with BOM (at least new versions of Excel).
A BOM is abnormal and not recommended in UTF-8, it's basically a shitty MS hack: the BOM is necessary to detect endianness differences between the document and the host system, endianness has no impact impact on UTF-8.
And as freak_nl above notes, Excel uses locale-dependent field separators, so in some countries/locales it will try to import "CSV" with semicolon separators.
It actually does have CSV and UTF-8, but finding the correct settings is very hidden. I'm always amazed at how unable Microsoft is to improve the base of Excel and instead just keeps piling UI layers on top to hide the ugly places.
