JSON parser grammar
Christian Plesner Hansen
christian.plesner.hansen at gmail.com
Thu Jun 4 09:02:56 PDT 2009
> "Sure" is never an option ;). Our relative confidence comes from our
> knowledge of the behavior of various popular json emitters. In
> particular, we know of none that emit octal.
It takes just one home-made emitter on a popular site somewhere for
this to break down. On the other hand if there are already browsers
that never interpret numbers as octal and haven't experienced any
problems with it then that's pretty close to "sure".
> Since octal syntax will currently be interpreted as decimal on some
> browsers and octal on others, even by json.js (since it delegates to
> eval), there is no safe way to allow this syntax. By allowing them,
> one's JSON.parse is no longer validating. It will not complain about
> data that will be interpreted differently by different browsers.
That sounds reasonable, though I'm unsure if the value of validation
justifies making the language more complex. If we're already in a
situation where nobody uses octal numbers in their json then
validation would seem unnecessary.
> Recall that we felt we needed to add JSON support to the spec because
> JS library code cannot provide parsers that are simultaneously fast,
> safe, and validating. If all you want is safe and fast, json_sans_eval
> is a fine solution that works on existing browsers.
I wasn't aware of the validation aspect. Also, I don't know of any
truly safe and fast json implementations that work on existing
browsers (no offense to json2.js).
More information about the es-discuss