3

根据 RFC 4627 第 2.2 节：2.2。对象

对象结构表示为一对围绕零个或多个名称/值对（或成员）的花括号。名称是一个字符串。每个名称后面都有一个冒号，将名称与值分开。单个逗号将值与后面的名称分开。 对象中的名称应该是唯一的。

但是“应该是独一无二的”是否符合行业最佳实践？大多数 JSON 编码器/解码器是否强制执行“必须是唯一的”。JSONlint.com 强制执行“必须是唯一的”。

例如 { "foo":"value1", "foo":"value2" } 返回有效 JSON，{ "foo":"value2" }

而第二个同名，替换第一个同名条目。

4

2 回答 2

2

RFC 4627：

对象中的名称应该是唯一的。

道格拉斯·克罗克福德（作者）谈到它：

这是 RFC 中最大的错误。应该是必须的。

可悲的是，修复它为时已晚。

最近的ecma json 标准不需要唯一性以避免使现有的 json 文档无效，这些文档正在向 rfc 确认并且可能包含重复的名称。

换句话说{ "foo":"value1", "foo":"value2" }，它是一个有效的 json，但不建议在新的 json 文档中使用重复的名称。

不同的解析器可以有不同的行为（或者可以配置为不同的行为）：

于 2013-11-06T03:39:54.643 回答
1

无论好坏，规范都允许 JSON 中的重复名称。

问题是解码器在面对这种重复时的行为是不确定的。

一些解析器会将此类 JSON 视为无效而拒绝（这是唯一可以说是“错误”恕我直言的行为）。大多数其他人将返回遇到的最后一个。至少我知道的一个（因为我写了它:)）将 JSON 严格视为独立于任何 JavaScript 解析规则或执行结果的数据结构，并允许通过包含对象内的序号索引分别访问每个命名值（作为替代通过键名访问，在这种情况下将返回第一次出现）。

尽管有些人认为解码器在构造 JSON 描述的对象时应该复制 JavaScript 解析器和执行环境的行为（也就是说，最后一个命名的值将覆盖任何早期的同名值），但简单的事实是JSON 只是一种数据结构标准，虽然受到 JavaScript 语法的启发和借鉴，但它并不要求 JavaScript 执行或反映这种执行的行为。

因此，RFC 和 ECMA 标准都没有规定解码器在面对重复时必须甚至应该如何表现，因此除了完全拒绝重复名称的解析器之外，接受重复的各种行为都不能说是“正确的” “ 一。

如果您在自己控制的进程之间生成和使用 JSON，那么可能很容易找到一个以适合您的方式工作的 JSON 编码器/解码器并采用它。但我建议不要这样做。

这让我想到了底线：

尽管 JSON 标准允许重复，但它并不要求您使用它们，因此最明智的方法是避免它们并完全避免产生或遇到问题。:)

于 2013-11-06T04:18:53.683 回答