4 ms·

JSON 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 c

by hajile 2y ago

JSON 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 ago
Not 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 ago
  That’s why we just email the sheets around like it’s 1999 :)
dwattttt 2y ago
You 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 ago
It falls down under very large integers -- think large valid uint64_t values.
- hajile 2y ago
  JSON 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 ago
    And 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!

by hajile 2y ago

whizzter 2y ago

Not 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 ago
That’s why we just email the sheets around like it’s 1999 :)

dwattttt 2y ago

You 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 ago

It falls down under very large integers -- think large valid uint64_t values.

hajile 2y ago
JSON 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 ago
  And 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!