Javascript 是否有任何实际理由使用带引号的字符串作为 JSON 键？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4201441/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there any practical reason to use quoted strings for JSON keys?
提问by Mark Rogers
According to Crockford's json.org, a JSON objectis made up of members, which is made up of pairs.
根据 Crockford 的json.org，JSON对象由members 组成，而members由pair 组成。
Every pair is made of a stringand a value, with a stringbeing defined as:
每对由一个string和一个value 组成，其中一个string被定义为：
A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string. A string is very much like a C or Java string.
字符串是零个或多个 Unicode 字符的序列，用双引号括起来，使用反斜杠转义。一个字符表示为单个字符串。字符串非常类似于 C 或 Java 字符串。
But in practice most programmers don't even know that a JSON key should be surrounded by double quotes, because most browsers don't require the use of double quotes.
但实际上大多数程序员甚至不知道 JSON 键应该用双引号括起来，因为大多数浏览器不需要使用双引号。
Does it make any sense to bother surrounding your JSON in double quotes?
用双引号将 JSON 括起来是否有意义？
Valid Example:
有效示例：
{
"keyName" : 34
}
As opposed to the invalid:
与无效相反：
{
keyName : 34
}
回答by CMS
The real reason about why JSON keys should be in quotes, relies in the semantics of Identifiers of ECMAScript 3.
为什么 JSON 键应该用引号引起来的真正原因取决于 ECMAScript 3 标识符的语义。
Reserved wordscannot be used as property namesin 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:
自己的 Crockford 在本次演讲中解释了这一点，他们希望保持 JSON 标准简单，并且他们不希望对它有所有这些语义限制：
....
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.
...
....
那是我们发现未引用名称问题的时候。事实证明，ECMA Script 3 有一个 whack 保留字策略。保留字必须在关键位置引用，这真的很麻烦。当我着手将其制定为标准时，我不想将所有保留字都放在标准中，因为这看起来非常愚蠢。
当时，我试图说服人们：是的，你可以用 JavaScript 编写应用程序，它实际上可以工作，而且它是一种很好的语言。然后，我不想同时说：看看他们所做的这件非常愚蠢的事情！所以我决定，相反，让我们只引用键。
这样，我们就不必告诉任何人它有多糟糕。这就是为什么直到今天，键都在 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.functionOk in ES5).
ECMAScript 第 5 版标准修复了这个问题，现在在 ES5 实现中，甚至可以在不带引号的情况下使用保留字，在对象字面量和成员访问中（obj.function在 ES5 中为 Ok）。
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)
只是为了记录，这个标准最近由软件供应商实施，您可以在此兼容性表上看到哪些浏览器包含此功能（请参阅保留字作为属性名称）
回答by Nick Craver
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 notbe compliant?
是的，它是无效的 JSON 并且在许多情况下会被拒绝，例如 jQuery 1.4+ 有一个检查，使未加引号的 JSON 静默失败。为什么不合规？
Let's take another example:
让我们再举一个例子：
{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }
...all of these wouldbe 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.
Web 开发人员世界中的一个更常见的示例：在大多数浏览器中呈现的无效 HTML 的示例数以千计……这是否可以减轻调试或维护的痛苦？完全没有，恰恰相反。
Also @Matthewmakes the best point of all in comments below, this alreadyfails, 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.
另外@Matthew在下面的评论中提出了最好的观点，这已经失败了，未加引号的键将JSON.parse()在所有主要浏览器（以及任何其他正确实现它的浏览器）中引发语法错误，您可以在此处进行测试。
回答by user1649339
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 实际上是 JSON 的超集，支持您想要做的事情。尽管它是一个超集，但它可以让您随心所欲地保持简单。
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
YAML 是一股清新的空气，值得您花时间看一看。最好的起点是这里：http: //en.wikipedia.org/wiki/YAML
There are libs for every language under the sun, including JS, eg https://github.com/nodeca/js-yaml
太阳底下的每种语言都有库，包括 JS，例如https://github.com/nodeca/js-yaml
