JSON parser grammar

Jorge jorge at jorgechamorro.com
Wed Jun 23 02:34:38 PDT 2010


On 23/06/2010, at 06:09, Garrett Smith wrote:
> (...)
> 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.

A good reason for not accepting unescaped tab chars (nor any other control chars) inside JSONStrings is that control chars often can't be transmitted (nor even copy-pasted) safely. The web and http is not all there's to JSON.

If anybody, in any library, is depending on not escaping (any of) them properly, they ought to stop doing so.

IOW, IMO, this is ok:

[].forEach.call(a= '{"c":"\\t"}',function(c){console.log([c,c.charCodeAt(0)])})
["{", 123]
[""", 34]
["c", 99]
[""", 34]
[":", 58]
[""", 34]
["\", 92]
["t", 116]
[""", 34]
["}", 125]

JSON.parse(a).c.charCodeAt(0)
--> 9

But this isn't: it's a bug (b is not a valid JSON text):

[].forEach.call(b= '{"c":"\t"}',function(c){console.log([c,c.charCodeAt(0)])})
["{", 123]
[""", 34]
["c", 99]
[""", 34]
[":", 58]
[""", 34]
["      ", 9]
[""", 34]
["}", 125]

JSON.parse(b).c.charCodeAt(0)
--> 9

(Note how the tab in the wrong one is being displayed as ["      ", 9] a bunch of spaces, it's been converted to that -automatically, not by me- somewhere along the copy/pasting/editing of this email...)

OTOH, Crockford/this committee might want for some reason to choose to "be conservative in what you send, liberal in what you accept". Or not.
-- 
Jorge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100623/2f13b757/attachment.html>


More information about the es-discuss mailing list