IMHO if it's not going to support octal anyway, it makes zero(!) sense to artificially limit/special-case things like this, because then it's much simpler and more consistent to have leading zeros behave like any other digit.
Unintuitive JSON Parsing
21–30 of 77 posts
Re: Unintuitive JSON Parsing
#22> The parser will not complain about leading zeros because JSON has no concept of leading zeros. Of course there is no logical reason why the parser shouldn't have this concept just because the spec doesn't require. IMO, beyond basic correctness, user friendly error messages are the main differentiator between excellent parsers and crappy parsers.
Reporting the last valid input and the start of the first invalid location (possibly repeating the first couple characters of invalid content, filtered for safety) is what I'd generally prefer in an error message.
For some reason the author truncated the error messages reported by Chrome and Firefox to not include the line/column.
The message in Firefox is: JSON.parse: expected ',' or ']' after array element at line 1 column 3 of the JSON data
In Chrome: Unexpected number in JSON at position 2
Re: Unintuitive JSON Parsing
#23Its possible the parser was laid out to choke on octals as a way to protect the 'standard'. Its one decision to not support octals, and its another to make octal-style an error so those numbers are not parsed as base10.
Re: Unintuitive JSON Parsing
#24Why is concatenated json a thing? In what sense is: {0}{1} better than [{0},{1}]? Presumably, if a few bytes are a major concern, you aren't using JSON anyway.
A non-online/non-streaming parser can parse [0][1] in an online/streaming way by first parsing one text ([0]) then the next ([1]), whereas it has to parse all of [[0],[1]] to produce a result. Similarly on the encoding side.
Concatenated JSON is ambiguous, so you need to put some whitespace between any JSON texts where both aren't arrays or objects.
This is a widely used technique.
Re: Unintuitive JSON Parsing
#25So is it incorrect (Technically, at any rate) for a parser to support leading zeroes in its implementation?
Yep. It's technically incorrect.
It seems honoring this type of technical correctness matters a lot. For example, imagine if ECMA added a new feature (e.g. 0-prefixed octal literals) in 2020..
Another issue: security. Imagine a hacker figured out that you used a mix of JSON parsers on your application (e.g. V8 and jq), and they produced different output.
For a vaguely related example, consider that some URL parsers interpret Ｎ (U+FF2E - fullwidth latin N) as ".", meaning you can sneakily add a ".." to the URL with ＮＮ (see https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-Ne...)
Re: Unintuitive JSON Parsing
#26Why is concatenated json a thing? In what sense is: {0}{1} better than [{0},{1}]? Presumably, if a few bytes are a major concern, you aren't using JSON anyway.
When I was writing something (partly) as a learning exercise the easiest way to handle errors was to have an error handler on the server-side JSON encode any errors. The client-side JS would then split the string it got back on newlines and then parse each part. Each chunk of JSON had a field to say if it were an error message and if so the error would be logged to the browser console. I don't recommend, by any means, that people do this generally.
Re: Unintuitive JSON Parsing
#27> Either the leading zero is ignored, or it indicates octal, as it does in many languages, including JavaScript.
This is false. In JavaScript, a leading zero, unless accompanied by a lowercase oh ('o') does indicate the number is written in octal.
08 === 0o10; // true
Here, the left side is still base 10, while the right side is base 8.
Re: Unintuitive JSON Parsing
#28I think JSON would be vastly improved if it were to just allow comments. Maintaining configuration in JSON is unnecessarily painful due to this pointless feature gap.
While I agree, that seems off-topic and it comes up most every time issues with JSON are brought up.
I found this to be a rather interesting article, and it'd be a shame if the discussion around it centered on such a well-tread topic.
Re: Unintuitive JSON Parsing
#29Why is concatenated json a thing? In what sense is: {0}{1} better than [{0},{1}]? Presumably, if a few bytes are a major concern, you aren't using JSON anyway.
As another commenter said: streaming.
To elaborate:
{0}{1} is better than [{0},{1}] because, when streamed, {0} is still valid, while [{0}, is not.
Re: Unintuitive JSON Parsing
#30IMHO if it's not going to support octal anyway, it makes zero(!) sense to artificially limit/special-case things like this, because then it's much simpler and more consistent to have leading zeros behave like any other digit.
JSON was made to be "based on a subset" of Javascript. The only way to be compatible with JS while removing octals is to disallow leading zeroes entirely. Doing otherwise would lead to JSON and JS behaving differently with the same input.
Of course, until recently JSON wasn't a strict subset of JS but that was an oversight rather than by design.