5 ms·
This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some f
by seanwoods 12y ago
This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity.
When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who want to import data are non-programmer types who all use Excel.
I'll often include the basic rules in the screen that accepts the import. If I ever had to accept data from something that was _not_ Excel I'd probably include a combo box on the web form that lets you pick the dialect. So far I haven't had to do that.
The only thing I might not be totally covering is how Excel handles newlines, but in practice I've never had to deal with that.
- blablabla123 12y agoMakes total sense to focus on the format the user actually uses. Still...why don't you use a library?
- leni536 12y agoDoes it work with Hungarian Ms Excel? It uses semicolons as delimiters.
- Moto7451 12y agoIf all you care about is Excel compatibility you can add "sep=," on the first line. You can also use the Text Import Wizard. Changing the extension to .txt should cause Excel to show the Wizard upon opening the file.
- alayne 12y agoI found out that Windows Excel and Mac OS Excel use different character encodings for CSV.
- chrismcb 12y agoWhat is wrong with trying to be all things to all people? If you use a good solid library you don't need to tell people "this works with some versions of MS Excel" And that is the main point of the article.