Ok, but which tool can you use to edit csvs with the same power as excel… without messing with the csv?
CSVs Are Kinda Bad. DSVs Are Kinda Good
41–50 of 133 posts
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#42The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
[flagged]
Importing data generated from Excel: don't, or force RFC 4180-compliant CSV data.
Exporting data into Excel: provide RFC 4180-compliant CSV data, or just generate minimal XLSX files.
Most Excel users generally don't export to CSV (or practice any data sanity conventions); they seem to believe XLSX is a perfectly fine data exchange format for automated use. (“Oh the import broke? I just added an empty row above the headers, because it looked sloppy.”) Those that do understand that automated data processing means you need to be stricter in what you do in the sheet you are exporting tend to understand how to export proper CSV's from Excel as well.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#43I had to LOL a bit about this. I built a career that lasted over 30 years writing software that deciphered clients' attempts to produce sales data files in CSV format.
Many times they just couldn't seem to find the comma. Other times there were commas in the item description (unescaped). My favourite though was when files were edited collaboratively using a Mac, Windows and Linux machines - multiple line-end types FTW! Like I said, a long and somewhat inglorious career..
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#44If you're not concerned with the size of the file, you might consider just using NDJSON.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#45I've read a comment here some years ago of someone discovering ASCII field delimiters and excited to use them. They then discovered that those characters are only used in three places: the ASCII spec, their own code, and the data from the first client where he tried to use this solution.
Any file format needs a well-specified escape strategy, because every file format is binary and may contain binary data. CSV is kinda bad not only because, in practice, there's no consensus escaping, but also because we don't communicate what the chosen escaping is!
I think a standard meta header like follows would do wonders to improve interchangeability, without having to communicate the serialization format out-of-band.
``` #csv delim=";" encoding=utf8 quote=double locale="pt-BR" header=true ```
(RFC-4180 does specify that charset and header may be specified in the MIME type)
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#46When we get to CSVs I tell my Python students that while the CSV module does do a lot of nice things for you, CSVs are still a minefield and you really have to look at the file in a text editor first if you're not the one who created it.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#47> Because these are non-printing characters that should never appear in a text-stream data set.
Good luck with that.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#48Earlier quoted context omitted.
You can’t put comments in JSON, while that’s fairly easy in CSV. This makes JSON unusable most of the time for human-editable data.
There is no such thing as a comment in CSV.
In many dialects there are. Usually you start the line with #.
Comments will happen. If your file format doesn’t allow comments, then people will make up an extension to allow it. This is true even for binary formats.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#49['Alice', 'She said, "Hello" and waved.', 'Fred''s Car is broken']
You still have the issue described by "" with '' if I read the examples correctly.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#50The article talks about reading and parsing CSV data of unknown variants, but then skips to the solution being using a different format altogether. But you can only switch to a different format if you are producing data, not if you are reading it! And if you are in control of producing data, just produce strict RFC 4180-compliant CSV data and everybody will be able to read it just fine. There is no need to make your…
I just had a look at RFC 4180. This is the grammar they suggest:
> file = [header CRLF] record *(CRLF record) [CRLF]
I find it kind of wild that you have to have at least one record. Suppose I have a program that lists the events that occurred on a given day. How do I represent the fact that the program ran successfully but that there weren't any events on that day?