11–20 of 29 posts
0x1d and 0x1e in the ascii standard exist for exactly this reason and don’t need more than one byte unlike this goofy thing.
Not long ago there was also a post about "Unicode Separated Value" https://github.com/sixarm/usv https://news.ycombinator.com/item?id=39679378
I was sure that's where this post was going to pivot to. The characters are right there!
Perhaps naive, but we escape with \ everywhere else, so why not here? If you're typing in CSV manually, escape with \ If you're exporting to CSV, the program already know which part is data and which part is the next cell, so again the program can escape with \
Most good implementations are flexible enough that they might be configurable to your proposed pseudo CSV. (Or even DSV. Or USV. Etc.) But I'd rather just not need to, and the sanest default for any CSV library is the standard format.
(Or even better … just emit newline-terminated JSON. Richer format, less craziness than CSV, parsers still abound.)
¹(RFC 4180. "," is field sep, CRLF is row sep. You can escape a comma or a CRLF by surrounding the entire field in double-quotes, and a double quote itself can be escaped by escaping the field, doubling the internal double quote.)
CSO is a stormwater industry term for "Combined Sewer Overflow." They happen in older cities where storm runoff and raw sewage (poop) go into the same sewer system. When there is a lot of rain, the wastewater treatment plants overflow, and then raw sewage runs into waterways.
https://en.wikipedia.org/wiki/Combined_sewer#Combined_sewer_...
No! The poop symbol is used in data, and thus is a terrible separator. If you have to quote it anyway, use commas, as that is already in use. Or use "Unicode" separated values.
What if my data contains a new line? People focus on the comma then forget the newline is just as significant. That still needs to be escaped and we're right back where we started. Meanwhile, RFC4180 takes less time to read than this entire article.
So true about RFC4180. Admittedly this post kind of got out a little early, support for the format was slated for the first of next month...
0x1d and 0x1e in the ascii standard exist for exactly this reason and don’t need more than one byte unlike this goofy thing.
> We tried using the control characters, and also tried configuring various editors to show the control characters by rendering the control picture characters.
> First, we encountered many difficulties with editor configurations, attempting to make each editor treat the invisible zero-width characters by rendering with the visible letter-width characters.
> Second, we encountered problems with copy/paste functionality, where it often didn't work because the editor implementations and terminal implementations copied visible letter-width characters, not the underlying invisible zero-width characters.
>Third, users were unable to distinguish between the rendered control picture characters (e.g. the editor saw ASCII 31 and rendered Unicode Unit Separator) versus the control picture characters being in the data content (e.g. someone actually typed Unicode Unit Separator into the data content).
https://github.com/SixArm/usv/tree/main/doc/faq#why-use-cont...
Perhaps naive, but we escape with \ everywhere else, so why not here? If you're typing in CSV manually, escape with \ If you're exporting to CSV, the program already know which part is data and which part is the next cell, so again the program can escape with \
Because those of us that have to read your data would highly prefer you just emit standard¹ CSV, and not invent "CSV+my oddball customizations". If you're going to muck about outside the standard format, then you might as well just use DSV from the OP. Most good implementations are flexible enough that they might be configurable to your proposed pseudo CSV. (Or even DSV. Or USV. Etc.) But I'd rather just not need to,…
And why would you "highly prefer you just emit standard CSV"? What is the benefit to insisting adherence to the original standard, especially if the modification fixes something that is broken?