为什么在JSON中不允许注释？

为什么在JSON中不允许注释？

---

我知道的每种标记或数据交换格式都支持注释的定义。仅有一个例外：JSON。

这些天，我经常处理JSON。最近，许多开发人员更喜欢JSON，而不是已经存在了一段时间的更复杂的XML。这就是为什么在JSON中而不是XML中实现REST -API 的普遍做法。JSON文档的另一个常见用例是各种软件系统的配置。我经常需要对此类JSON文档的某些行进行注释。也许只是为了澄清我的意图或为以后做一些笔记。

如果您大量使用JSON，那么一旦您可以对某些属性，特定值等进行注释，那将是一个很棒的选择。由于JSON是JavaScript的子集，因此人们可以认为它会允许使用本示例中的注释：

{
  "key": "value" // comment
}

但事实并非如此。在JSON网站并没有太多说的这个情况。在相应的RFC确实没有。据说发现了JSON的Douglas Crockford 在他的演讲“ JSON Saga”中给出了答案。他说，一开始，你被允许使用// comments after a double slash，以及/* block comments */在JSON。后来，他决定删除对评论的支持，原因有以下三个：

危险行为

“人们在注释中向解析器添加指令，这确实是一件坏事，因为这将完全破坏互操作性，因为整个元语言水平并不常见，而这超出了标准。”

不必要的复杂性

“ […]对于其他语言的某些移植，做事的复杂性的一半左右只是在做评论[…]”

与YAML保持一致

我真的不认为这些是删除注释之类的典型内容的正当理由，但至少有此决定的理由。

有两种方法可以解决缺少评论的问题（除了感到沮丧和将其排除在外）。

您可以在保留周围对象注释的特殊属性上达成一致。例如：

{
  "key": "value",
  "__comment": "defines a key and a value"
}

或者，您可以使用另一种支持注释的标记格式。例如XML，YAML或较新的HOCON（人为优化配置对象表示法）。

就我个人而言，我认为YAML是一个过时的规范，HOCON优选用于配置软件系统。有时，将XML引入客户端Web应用程序可能是一个真正的难题，因此JSON中的注释通常是唯一的解决方案。

翻译至----保罗·沃巴赫（Paul Vorbach）， 2013-03-13