4 ms·
JSON is a textual encoding no different than CSV. It's just that people tend to use specialized tools for encoding and decoding it instead of like ",".join(row
by benwilber0 2y ago
JSON is a textual encoding no different than CSV.
It's just that people tend to use specialized tools for encoding and decoding it instead of like ",".join(row) and row.split(",")
I have seen people try to build up JSON strings like that too, and then you have all the same problems.
So there is no problem with CSV except that maybe it's too deceptively simple. We also see people trying to build things like URLs and query strings without using a proper library.
- int_19h 2y agoThe problem with CSV is that there's no clear standard, so even if you do reach for a library to parse it, that doesn't ensure compatibility.
- rcbdev 2y agoSame for JSON though. What Python considers a valid JSON might not be that if you ask a Java library.
- hajile 2y agoJSON has a clearly-defined standards: ISO/IEC 21778:2017, IETF RFC 7159, and ECMA-404. Additionally, Crockford has had a spec available on json.org since it's creation in 2001. Do you have any examples of Python, Java, or any of the other Tiobe top 40 languages breaking the JSON spec in their standard library? In contrast, for the few of those that have CSV libraries, how many of those libraries will simply fail to parse a large number of the .csv variations out there?
- whizzter 2y agoNot to mention that stuff like Excel loves to export CSV files in "locale specific ways". Sometimes commas to delimiter, sometimes semicolons, floating point values might have dots or commas to separate fraction digits. Not to mention text encodings, Ascii, western european character sets, or maybe utf-8 or whatever... It's a bloody mess.
- ohgr 2y agoThat’s why we just email the sheets around like it’s 1999 :)
- dwattttt 2y agoYou need more than a standard; that standard has to be complete and unambiguous. What you're looking for is https://github.com/nst/JSONTestSuite https://github.com/nst/JSONTestSuite EDIT: The readme's results are from 2016, but there's more recent results (last updated 5 years ago). Of the 54 parsers /versions tested, 7 gave always the expected result per the spec (disregarding cases where the spec does not define a result).
- noitpmeder 2y agoIt falls down under very large integers -- think large valid uint64_t values.
- hajile 2y agoJSON doesn't fail for very large values because they are sent over the wire as strings. Only parsers may fail if they or their backing language doesn't account for BigInts or floats larger than f64, but these problems exist when parsing any string to a number.
- girvo 2y agoAnd indeed applies to CSV as well: it's just strings at the end of the day, its up to the parser to make sense of it into the data types one wants. There is nothing inherently stopping you from parsing a JSON string into a uint64: I've done so plenty!
- zeroimpl 2y agoExample? I know there's some ambiguity over whether literals like false are valid JSON, but I can't think of anything else.
- tubthumper8 2y agoThat _shouldn't_ be ambiguous, `false` is a valid JSON document according to specification, but not all parsers are compliant. There's some interesting examples of ambiguities here: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
- recursive 2y agoTrailing commas, comments, duplicate key names, for a few examples.
- int_19h 2y agoTrailing commas and comments are plainly not standard JSON under any definition. There are standards that include them which extend JSON, sure, but I'm not aware of any JSON library that emits this kind of stuff by default.
- recursive 2y agoI'm not aware of any CSV library that doesn't follow RFC4180 by default, and yet... this whole thread.
- gopher_space 2y agoThere is a clear standard and it's usually written on an old Word '97 doc in a local file server. Using CSV means that you are the compatibility layer, and this is useful if you need firm control or understanding of your data. If that sounds like a lot of edge-case work keep in mind that people have been doing this for more than half a century. Lots of examples and notes you can steal.
- Kinrany 2y agohttps://datatracker.ietf.org/doc/html/rfc4180 https://datatracker.ietf.org/doc/html/rfc4180 exists
- gthompson512 2y ago> It's just that people tend to use specialized tools for encoding and decoding it instead of like ",".join(row) and row.split(",") You really super can't just split on commas for csv. You need to handle the string encodings since records can have commas occur in a string, and you need to handle quoting since you need to know when a string ends and that string may have internal quote characters. For either format unless you know your data super well you need to use a library.
- benwilber0 2y agoRight, obviously.
- pasc1878 2y agoYes but people don't