This problem is easy to solve: CSV is not a file format definition (despite RFC 4180).
Excel, as an example, reads and saves csv using a localized list separator and localized data formats set by the user. Thus, βCommaβ in CSV does not mean a comma, but a common list separator (for many EU countries, this is a semicolon, as Tim Schmelter said).
If values ββare enclosed in quotation marks, they are usually treated as strings. Excel still tries to parse the quoted elements of the CSV string, so this may seem to work in very special cases.
The problem is that both the writer and the reader of the CSV file must use the same culture, otherwise problems will arise with almost everything that is not a string (numbers are one, date / time is another source of problems).
I am using an empirically derived date solution consisting of a string of the format yyyy/MM/dd HH:mm:ss
. I noticed that it allows the exchange of working dates between Excel and my programs, interchangeable in English or Italian.
I still haven't found a universal solution for decimal numbers. I suspect that scientific notation can do, but did not have time to test.
source share