对于 JSON 键使用带引号的字符串有什么实际原因吗？

根据克罗克福德的 Json.org，一个 JSON 对象是由 成员组成的，而 成员又是由 成对组成的。

每一对都由 绳子和 价值组成，绳子被定义为:

字符串是一个零或更多的序列 Unicode 字符，包装为双精度 引号，使用反斜杠转义符 字符表示为单个 字符串。字符串非常 非常类似于 C 或 Java 字符串。

但实际上，大多数程序员甚至不知道 JSON 键应该被双引号包围，因为大多数浏览器不需要使用双引号。

用双引号包围您的 JSON 有意义吗？

有效例子:

{
"keyName" : 34
}

与病人相反:

{
keyName : 34
}
34665 次浏览
小开

Yes, it's invalid JSON and will be rejected otherwise in many cases, for example jQuery 1.4+ has a check that makes unquoted JSON silently fail. Why not be compliant?

Let's take another example:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

...all of these would be valid with quotes, why not be consistent and use them in all cases, eliminating the possibility of a problem?

One more common example in the web developer world: There are thousands of examples of invalid HTML that renders in most browsers...does that make it any less painful to debug or maintain? Not at all, quite the opposite.

Also @Matthew makes the best point of all in comments below, this already fails, unquoted keys will throw a syntax error with JSON.parse() in all major browsers (and any others that implement it correctly), you can test it here.

小开
最佳答案

The real reason about why JSON keys should be in quotes, relies in the semantics of Identifiers of ECMAScript 3.

Reserved words cannot be used as property names in Object Literals without quotes, for example:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

While if you use quotes the property names are valid:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

The own Crockford explains it in this talk, they wanted to keep the JSON standard simple, and they wouldn't like to have all those semantic restrictions on it:

....

That was when we discovered the unquoted name problem. It turns out ECMA Script 3 has a whack reserved word policy. Reserved words must be quoted in the key position, which is really a nuisance. When I got around to formulizing this into a standard, I didn't want to have to put all of the reserved words in the standard, because it would look really stupid.

At the time, I was trying to convince people: yeah, you can write applications in JavaScript, it's actually going to work and it's a good language. I didn't want to say, then, at the same time: and look at this really stupid thing they did! So I decided, instead, let's just quote the keys.
That way, we don't have to tell anybody about how whack it is.

That's why, to this day, keys are quoted in JSON.

...

The ECMAScript 5th Edition Standard fixes this, now in an ES5 implementation, even reserved words can be used without quotes, in both, Object literals and member access (obj.function Ok in ES5).

Just for the record, this standard is being implemented these days by software vendors, you can see what browsers include this feature on this compatibility table (see Reserved words as property names)

小开

YAML, which is in fact a superset of JSON, supports what you want to do. ALthough its a superset, it lets you keep it as simple as you want.

YAML is a breath of fresh air and it may be worth your time to have a look at it. Best place to start is here: http://en.wikipedia.org/wiki/YAML

There are libs for every language under the sun, including JS, eg https://github.com/nodeca/js-yaml

小开

If I understand the standard correctly, what JSON calls "objects" are actually much closer to maps ("dictionaries") than to actual objects in the usual sense. The current standard easily accommodates an extension allowing keys of any type, making

{
"1" : 31.0,
1 : 17,
1n : "valueForBigInt1"
}

a valid "object/map" of 3 different elements.

If not for this reason, I believe the designers would have made quotes around keys optional for all cases (maybe except keywords).


提交答案