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._______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
