4 ms·

Open a csv file in Excel, edit it and save (the latter is locale dependent). The result is horrible. I maintain a tool which offers csv import and export of dat

by chopin 8y ago

Open a csv file in Excel, edit it and save (the latter is locale dependent). The result is horrible. I maintain a tool which offers csv import and export of data and we have regularly bug reports from users when they use excel to use it (Excel opens csv files by default on Windows). I did not find a way to tell Excel to not alter the meta-structure (such as replacing commas with semicolons), not to start about escaping. There's an RFC for csv data (https://tools.ietf.org/html/rfc4180 https://tools.ietf.org/html/rfc4180), there's no way to tell Excel to honour it.

jchw 8y ago
>There's an RFC for csv data (https://tools.ietf.org/html/rfc4180 https://tools.ietf.org/html/rfc4180), there's no way to tell Excel to honour it. That RFC is from 2005. Excel appeared in 1987. Excel outputs CSVs in Excel dialect rather than RFC 4180. Unfortunate as it is, it's probably only sane to do that. A lot of stuff has probably relied on it for decades. Python 3, for example, defaults to excel dialect in it's CSV library. Apache Commons CSV supports Excel dialect. I imagine there's all kinds of crap relying on this by now. The fact that it doesn't have an option to output in RFC 4180 is unideal, but I can certainly see why. For almost their entire userbase, it would be the wrong option. I don't think they really want more code paths to maintain either. Seems logical enough. Of course it's relatively easy to support XLS/XLSX and it should be relatively easy to automatically detect what dialect of CSV you're taking in. So if your goal is happier customers, then you have options. It is what it is. I don't think this is a JScript type situation here. The world mostly standardized on Excel style CSV and a different standard was blessed by IETF. But much like HTML5 vs XHTML, sometimes standards should be descriptive rather than prescriptive. RFC 4180 would've been more useful had it followed Excel dialect. Instead I think it leaves Microsoft in a tough place and their decision has been to not change it in line with how they normally treat backwards compatibility. Far from a staunch fan of Microsoft myself, but I do think it's important to stay rational and have some reasonable skepticism.
- chopin 8y ago
  I understand legacy. The only wish I have is to tell Excel to honour the RFC (it's not that Excel isn't developed any longer). Just a checkbox (or whatever). I am using the Apache CSV library to parse csv. Content coming from Excel is still ... difficult. And Apache is fine with handling RFC 4180 compliant content. If the "new" Microsoft is really opening up to Open Source, it'd be nice if they honoured existing standards at least with products which are still under development. All I am asking for is one more entry in the "Save As..." dialogs drop down box. It can't be that hard...

by chopin 8y ago

jchw 8y ago

>There's an RFC for csv data (https://tools.ietf.org/html/rfc4180 https://tools.ietf.org/html/rfc4180), there's no way to tell Excel to honour it. That RFC is from 2005. Excel appeared in 1987. Excel outputs CSVs in Excel dialect rather than RFC 4180. Unfortunate as it is, it's probably only sane to do that. A lot of stuff has probably relied on it for decades. Python 3, for example, defaults to excel dialect in it's CSV library. Apache Commons CSV supports Excel dialect. I imagine there's all kinds of crap relying on this by now. The fact that it doesn't have an option to output in RFC 4180 is unideal, but I can certainly see why. For almost their entire userbase, it would be the wrong option. I don't think they really want more code paths to maintain either. Seems logical enough. Of course it's relatively easy to support XLS/XLSX and it should be relatively easy to automatically detect what dialect of CSV you're taking in. So if your goal is happier customers, then you have options. It is what it is. I don't think this is a JScript type situation here. The world mostly standardized on Excel style CSV and a different standard was blessed by IETF. But much like HTML5 vs XHTML, sometimes standards should be descriptive rather than prescriptive. RFC 4180 would've been more useful had it followed Excel dialect. Instead I think it leaves Microsoft in a tough place and their decision has been to not change it in line with how they normally treat backwards compatibility. Far from a staunch fan of Microsoft myself, but I do think it's important to stay rational and have some reasonable skepticism.

chopin 8y ago
I understand legacy. The only wish I have is to tell Excel to honour the RFC (it's not that Excel isn't developed any longer). Just a checkbox (or whatever). I am using the Apache CSV library to parse csv. Content coming from Excel is still ... difficult. And Apache is fine with handling RFC 4180 compliant content. If the "new" Microsoft is really opening up to Open Source, it'd be nice if they honoured existing standards at least with products which are still under development. All I am asking for is one more entry in the "Save As..." dialogs drop down box. It can't be that hard...