>For starters, it’s rather unreadable when opened in a text editor. But I bet you don’t really do that with your CSVs all that often anyway!
I really wish that were true.
CSVs Are Kinda Bad. DSVs Are Kinda Good
111–120 of 133 posts
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#112Love it. I’m gonna use this. Thank you for sharing!
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#113The 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]
Where does Excel fall down when exporting CSVs?
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#114Earlier quoted context omitted.
> Don't accept broken CSV. If people keep ignoring standards, thats their problem. From the very memo you link to (RFC 4180): > Implementors should "be conservative in what you do, be liberal in what you accept from others" (RFC 793 [8]) when processing CSV files.
Oh, I am nothing but liberal when it comes to CSV: Clients get the liberty to either have their requests processed, or get a 400 BAD REQUEST And yes, I am aware that the standard says this. My counter question to that is: How much client-liberty do I have to accept? Where do I draw the line? How much is too much liberty? And the answer is: there is no answer. Wherever any system draws that line, it's an arbitrary dec…
I think the suggestion reflected a deep understanding that transitioning from decades of wild-west to standardized in the smooth fashion most likely to succeed would require that strategy.
If you don’t accept whatever some org’s data is encoded with, they won’t consider it a win for standards, or swap out whatever is producing that data for something more compliant. They’ll consider it a bug, and probably use some other more flexible processor.
On the other hand, if you can be flexible enough to allow quirks on import while not perpetuating them on export, eventually you and other software built with the same philosophy standardize the field.
I do think there’s a point where things are standardized enough that you can safely stop doing that—when all the extra quirk code is so rarely used as to be irrelevant—but I’m unsure if we’ve reached it yet. It would be something to actually analyze, though, rather than just a philosophical decision.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#115Earlier quoted context omitted.
[flagged]
Don't use broken tools. The key phrase is "in control of producing data". If you're forced to use Excel, then it's not really you in control, is it?
This is some next level response where Excel is called a “broken tool”. You may not agree with their choices or design or anything else. But calling the entirety of the product isn’t making a strong case towards the prior point.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#116> CSVs are kinda bad. Not really. What's bad is when people keep insisting on coming up with new and amazing CSV dialects. https://www.ietf.org/rfc/rfc4180.txt is very clear about what CSV files are supposed to look like, and the fact that people keep ignoring this for whatever reason, is not the formats problem. And no, "using another format" is not a solution to this. Because: I can just invent a new DSV dialect. O…
> In fact I even have an amazing vim plugin just for them
So this is gold. Editing xSV files has been an ongoing pain, and this plugin is just amazingly awesome. Thanks for the link to it.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#117I was wondering what DSV is and saw it's a term the author created. I have seen this format usually called ASV (ASCII Separated Values).
There's also a more modern USV (Unicode Separated Values) which has visible separators.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#118Earlier quoted context omitted.
> https://www.ietf.org/rfc/rfc4180.txt is very clear about what CSV files are supposed to look like Mm, not really. By its own admission, it is descriptive, not prescriptive : > This section documents the format that seems to be followed by most implementations And it came out in 2005, by which date CSVs had already been in use for some twenty or thirty years.
It doesn't matter when it came out, it doesn't matter that it it descriptive. It is the standard, period. Yes, CSV is much, much older. In fact it predates personal computers. And it went through changes. Again: None of that matters. We have a standard, we should use the standard, and systems should demand the standard. Standards are meant to ensure minimal-friction interoperability. If systems don't enforce standard…
"This memo provides information for the Internet community. It does not specify an Internet standard of any kind."
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#119The 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]
Can you get DSVs out of Excel? If not, it's kinda moot.
Re: CSVs Are Kinda Bad. DSVs Are Kinda Good
#120> CSVs are kinda bad. Not really. What's bad is when people keep insisting on coming up with new and amazing CSV dialects. https://www.ietf.org/rfc/rfc4180.txt is very clear about what CSV files are supposed to look like, and the fact that people keep ignoring this for whatever reason, is not the formats problem. And no, "using another format" is not a solution to this. Because: I can just invent a new DSV dialect. O…
> In fact I even have an amazing vim plugin just for them So this is gold. Editing xSV files has been an ongoing pain, and this plugin is just amazingly awesome. Thanks for the link to it.
My pleasure :-)