JSON parser grammar

Garrett Smith dhtmlkitchen at gmail.com
Tue Jun 22 21:09:41 PDT 2010


On 6/22/10, Luke Smith <lsmith at lucassmith.name> wrote:
> On Jun 22, 2010, at 7:20 PM, Oliver Hunt wrote:
>
>>
>> On Jun 22, 2010, at 7:07 PM, Dean Landolt wrote:
>>
>>>
>>>
>>> On Tue, Jun 22, 2010 at 9:34 PM, Oliver Hunt <oliver at apple.com>
>>> wrote:
>>>
[...]

>>
>> As far as I can tell, all the major browsers accept tabs, as do many
>> other json parsers, at brief inspection it seems that the defacto
>> (vs. actual) JSON spec allows tabs.
>

Most but not all. Look: IE9b and BESEN (though not a browser) both
throw SyntaxError on U+0009 in JSONString:

  alert( JSON.parse('  "\t"  ') );

(error message in IE9 says: "Invalid Character".)

> And regarding js library abstractions, I disagree that there is enough
> stability in the JSON implementations to state that major libraries
> *rely* on the parsing of tabs.  I think "tolerate" is closer to the
> truth.  I certainly do not rely on native implementations continuing
> not to conform to a spec that, relatively speaking, is fresh out of
> the gate.  I would rather see the implementations get cleaned up and
> follow spec than agree this early to disregard it.
>

Prototype and jQuery don't check to make sure the string doesn't
contain \0-\x1f. json2.js doesn't and I would not be surprised if
other libraries didn't either. Basically, these scripts do minimal
feature tests on global JSON (json2.js merely checks for existence).
If global JSON exists, it is used, and if it does not exist, then a
fallback is used. The result can be guaranteed to be widely
inconsistent depending on the browser, version, and in IE, even
document mode.

Any application that uses any library that uses unfiltered JSON.parse
or json2.js may be expecting TAB to continue to work so changing that
will probably break things for some environments. I can see why
implementations might want to allow TAB, and most major browsers do,
despite the fact that such extensions are explicitly forbidden.

I mean, I can see why Opera would allow \t in JSONString because
otherwise, people would be complaining "it doesn't work in Opera."

Having varied behavior depending on the environment and the input
supplied to JSON.parse is no good and having a de facto standard that
contradicts the spec is no good.

| 15.12 The JSON Object
|
| [...]
|
| Conforming implementations of JSON.parse and JSON.stringify must support
| the exact interchange format described in this specification without
any deletions
| or extensions to the format. This differs from RFC 4627 which permits a
| JSON parser to accept non-JSON forms and extensions.

If all major implementations are going to start disallowing U+0009 in
JSONString -- and according to what Doug wrote earlier today they are
-- then the spec can stay as-is. Otherwise, if major implementations
want to allow \t in JSONString, then they should argue for that case
here and argue that the spec be changed and if they lose that
argument, then they must not continue to violate the spec.

Garrett


More information about the es-discuss mailing list