Joerg Mayer wrote:
On Tue, Feb 06, 2007 at 01:47:49PM +0100, Jaap Keuter wrote:
I'm sorry but your barking up the wrong tree here. If this is true then go
ask Bill to have access read COMMA SEPERATED VALUE aka .csv files
regardless of locale.
I don't think so: If we print the character that is used to separate
the fields inside a field, then we'll either need to allow users to
change the separator or we'll need to surround the whole value by "",
because no importing app will be able to reliably tell whether the
character was meant as a decimal separator or as a field separator.
The locale also affects, obviously, the way non-integral numeric values
are printed.
Should CSV's be printed in the C locale - meaning "." as decimal
indicator - with commas as field separators, or should they be printed
in the, well, local locale - meaning the appropriate choice of "." or
"," as decimal separator, and something else as field separator?
If the former, we obviously hard-code "," as the field separator.
If the latter, perhaps we should get the decimal separator by calling
localeconv(), and, based on whether it's "," or not, choose the
appropriate field separator, if there's a standard for that. (*Is*
there a standard for "C"SV's field separator if the decimal indicator is
the "C" in "CSV"?)
