这是有效的json吗?

{
    "a" : "x",
    "a" : "y"
}

http://jsonlint.com/的答案是肯定的。

http://www.json.org/没有说任何关于它是禁止的。

但显然这没什么意义,不是吗? 大多数实现可能使用哈希表,所以无论如何它都会被覆盖。


当前回答

问目的,有不同的答案:

使用JSON序列化对象(JavaScriptObjectNotation),每个字典元素映射到一个单独的对象属性,因此不同的条目为同一个属性定义一个值是没有意义的。

然而,我从一个非常具体的用例中得到了同样的问题: 为API测试编写JSON样本,我想知道如何在不破坏可用性的情况下向JSON文件添加注释。JSON规范不知道注释,所以我想出了一个非常简单的方法:

使用重复的键来注释JSON样本。 例子:

{ "property1": "value1", "REMARK": "…"Prop1控制…", "property2": "value2", "REMARK": "…Value2引发异常…", }

我们使用的JSON序列化器对这些重复的“REMARK”没有任何问题,我们的应用程序代码简单地忽略了这个小开销。

因此,尽管在应用层没有任何意义,但这些副本为我们提供了一个有价值的解决方案,可以在不破坏JSON可用性的情况下向测试示例添加注释。

其他回答

应该是独一无二的并不意味着必须是独一无二的。但是,如上所述,一些解析器会失败,而另一些解析器只使用解析的最后一个值。然而,如果规范被清理了一点,允许重复,那么我可以看到一个使用,你可能有一个事件处理程序,将JSON转换为HTML或其他格式…在这种情况下,解析JSON并创建另一种文档格式是完全有效的……

[
  "div":
  {
    "p": "hello",
    "p": "universe"
  },
  "div":
  {
    "h1": "Heading 1",
    "p": "another paragraph"
  }
]

然后可以很容易地解析为HTML,例如:

<body>
 <div>
  <p>hello</p>
  <p>universe</p>
 </div>
 <div>
  <h1>Heading 1</h1>
  <p>another paragraph</p>
 </div>
</body>

我知道这个问题背后的原因,但就目前情况而言……我不会相信它。

因为有很多过时的想法和对标准的困惑。截至2017年12月,有两个相互竞争的标准:

RFC 8259 - https://www.rfc-editor.org/rfc/rfc8259

ECMA-404 - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

json.org建议ECMA-404是标准,但本网站似乎不是权威。虽然我认为将ECMA视为权威是公平的,但这里重要的是,标准之间的唯一区别(关于唯一密钥)是RFC 8259说密钥应该是唯一的,而ECMA-404说它们不需要是唯一的。

rfc - 8259:

对象中的名称必须是唯一的。

像这样大写的单词“should”在RFC世界中有一个特殊的含义,在另一个标准(BCP 14, RFC 2119 - https://www.rfc-editor.org/rfc/rfc2119)中被明确定义为:

这个词或者形容词“RECOMMENDED”是这个意思吗 在特定情况下,可能存在忽视的正当理由 一个特定的项目,但必须理解全部的含义和 在选择不同的路线之前仔细权衡。

ecma - 404:

JSON语法对所使用的字符串没有任何限制 作为名称,不要求名称字符串是唯一的,也不要求 赋予名称/值对的顺序任何意义。”

无论如何分割,它都是语法上有效的JSON。

RFC 8259中给出的唯一密钥建议的原因是,

在某种意义上,名称都是唯一的对象是可互操作的 所有接收该对象的软件实现都会同意 名称-值映射。当对象中的名称不是时 唯一的,软件接收这样一个对象的行为是 不可预测的。许多实现报告姓氏/值对 只有。属性的其他实现报告错误或未能解析 对象,一些实现报告所有的名称/值对, 包括重复。

In other words, from the RFC 8259 viewpoint, it's valid but your parser may barf and there's no promise as to which, if any, value will be paired with that key. From the ECMA-404 viewpoint (which I'd personally take as the authority), it's valid, period. To me this means that any parser that refuses to parse it is broken. It should at least parse according to both of these standards. But how it gets turned into your native object of choice is, in any case, unique keys or not, completely dependent on the environment and the situation, and none of that is in the standard to begin with.

有两个文档指定JSON格式:

http://json.org/ https://www.rfc-editor.org/rfc/rfc7159

被接受的答案引用自第一个文档。我认为第一份文件更清楚,但第二份文件包含更多细节。

第二份文件说:

对象 对象结构用一对花括号表示 包围零个或多个名称/值对(或成员)。名字就是 字符串。每个名称后面都有一个冒号,分隔名称 从值。一个逗号将值与后面的字符分隔开 的名字。对象中的名称应该是唯一的。

所以不禁止使用重复的名字,但不鼓励使用。

在处理一个同时接受XML和JSON的API时,我遇到了一个类似的问题,但没有记录它将如何处理您期望在接受的JSON中出现的重复键。

以下是示例JSON的有效XML表示:

<object>
  <a>x</a>
  <a>y</a>
</object>

当它被转换成JSON时,你会得到以下内容:

{
  "object": {
    "a": [
      "x",
      "y"
    ]
  }
}

从一种处理重复键的语言到另一种语言的自然映射,可以作为这里潜在的最佳实践参考。

希望这能帮助到别人!

问目的,有不同的答案:

使用JSON序列化对象(JavaScriptObjectNotation),每个字典元素映射到一个单独的对象属性,因此不同的条目为同一个属性定义一个值是没有意义的。

然而,我从一个非常具体的用例中得到了同样的问题: 为API测试编写JSON样本,我想知道如何在不破坏可用性的情况下向JSON文件添加注释。JSON规范不知道注释,所以我想出了一个非常简单的方法:

使用重复的键来注释JSON样本。 例子:

{ "property1": "value1", "REMARK": "…"Prop1控制…", "property2": "value2", "REMARK": "…Value2引发异常…", }

我们使用的JSON序列化器对这些重复的“REMARK”没有任何问题,我们的应用程序代码简单地忽略了这个小开销。

因此,尽管在应用层没有任何意义,但这些副本为我们提供了一个有价值的解决方案,可以在不破坏JSON可用性的情况下向测试示例添加注释。