ECMAScript 5 Strict Mode, JSON, and More
ejohn.org
ejohn.org
For example, in js code, eval, other JSON parsers etc, the following works fine as you'd expect:
{foo:"bar"}
However, using the JSON.parse function, it'll fail. The following works:
{"foo":"bar"}
If anyone can shed some light on this, I'd be interested. I'd rather not send tons of useless quotes if I don't have to.
e.g. in Safari:
var a = { new: 'Monkey' }
fails. Thus the required quotes in the JSON spec.
I don't think it's a good argument to include needless quotes in a data format just so some bad interpreters don't get confused. Fix the interpreter - or just don't use reserved words, or enclose those in quotes if you use them.
Everything adds up. Imagine you were sending a few billion JSON objects a day. Requiring quotes on every single property name is wasteful and unnecessary. It's redundant useless information.
A hack around would be to regexp a replace to add quotes, and then JSON.parse it, but then you may as well just continue using eval, or a parser that doesn't care if you omit quotes, which is a shame.
IMHO, JSON.parse should function exactly as eval does for de-serializing js objects.
"A hack around would be to regexp a replace to add quotes, and then JSON.parse it,"
That is an absolutely terrible, terrible, terrible idea. Do not do that, especially if you're shipping around a "few billion JSON objects a day"! Running regexps over things that require a grammar to fully understand is asking for disaster.
"IMHO, JSON.parse should function exactly as eval does for de-serializing js objects."
The entire purpose is to get away from "eval". How do you like '{"test": window.close()}" in your JSON?
JSON is a cross-language serialization format that was inspired heavily by the fact that Perl, Python, and Javascript had very similar object literals and underlying data structures. It is not simply Javascript in a fancy spec, and you're missing the point if you think it is or treat it like it is. If you're just moving JS around, then ship whatever you like down. Back in the days before anybody had heard of JSON, I used to do that; as long as you're in control of the JS it works fine. (It's useless for communication between different entities, though.)
And yes, I'm just sending data from server to client. I couldn't care less if it conforms to some spec or not. I want an efficient, useful data format.
>> The entire purpose is to get away from "eval". How do you like '{"test": window.close()}" in your JSON?
You're absolutely correct. but that is simple to protect against with a regexp, which is how the json parser at json.org works - regexp it, then eval().
My point is, that for my use case, the native JSON parser will mean an increase in bandwidth. Which is a pain - especially as there isn't a good reason for it.
"This provides both future-proofing against later changes in ECMAScript (adding keywords), and simplifies the grammar for conforming parsers. Simpler grammars mean less opportunity for errors and non-conformant implementations."
If it didn't require quotes, currently valid JSON may not be valid in the future if a new keyword which was use as a JSON object key was used unquoted. And there's the added complexity of supporting both quoted and unquoted keys.
var a = { foo:bar : 'Monkey' }var a = {foo:"bar"} is valid js code. It can be parsed with eval(). It should be valid for JSON.parse() as well.
{
foo: {
"bar";
};
}
There was a really good talk recently that touched on this, but I can't remember who gave it or what it was called.
For what it's worth, the corner cases in JavaScript make non-string keys very difficult to reasonably parse. For example, if {foo:"bar"} should parse to {"foo":"bar"}, then what should {1:"bar"} or {::"bar"} parse to?
The json parser at json.org parses non quoted keys just fine, since it uses eval().
{1:"bar"} would obviously create a property "1", and {::"bar"} would obviously not be valid.