我可以在JSON文件中使用注释吗？如果是这样，怎么办？
@Stingyjack：解释那些不明显的事情，或者用评论来解释其他事情。我个人经常在数据文件中发表评论。XML、INI文件和许多其他格式包括注释的规定。
如果您和我一样，想知道//comments 是否适用于高级文本配置文件的特定用例，那么答案是肯定的(从版本2开始)。崇高的文本不会抱怨它，至少，它会抱怨控制台中的{"__comment": ...} ，因为它是一个意想不到的字段。
也许这就是为什么创建Toml的原因之一。
虽然有点不熟，但我也尝试使用//在JSON中获取评论。现在我意识到它被严格用于交换。叹息！我再也不能评论了：(。人生注定！.
查看highcharts.com/samples/data/&hellip；？你会看到评论。不过，这是JSONP，而不是纯JSON。请看下面我的回答。
@戴维派克：我想说，现在是时候开始为yaml编写一个objective-c绑定了，并且忘记了手工编写json所需要输入的所有代码。
JSON5支持注释：stackoverflow.com/a/7901053/108238
Ruby的JSON解析器是支持注释的解析器的另一个例子。
如果您想要一种带有注释的配置语言，请参阅toml。
不允许评论，因为支持评论为时已晚。重大监督。讽刺的是，Yaml支持评论。
oreilly.com/learning/adding-comments-in-json有两种方法可以为JSON文件添加注释功能。
这是一个很好的技巧gist.github.com/moox/5271067
这就是山药优越的原因。
查找RFC 4627及相关信息。
JSON的一个关键目标是消除XML这样的格式。所有这些都是关于数据和最小标记。这是一种明确阻止您使用注释的固定格式。JSON模式将有助于帮助人们以类似于XML模式的方式理解数据，但需要改进工具支持。JSON现在已经进入了互联网传输之外的其他领域，我也同意它可以很方便地为这种使用提供评论。
不。
JSON应该都是数据，如果您包含一个注释，那么它也将是数据。
您可以有一个名为"_comment" 的指定数据元素(或其他东西)，这些元素将被使用JSON数据的应用程序忽略。
您最好在生成/接收JSON的进程中拥有注释，因为它们应该事先知道JSON数据是什么，或者至少知道它的结构。
但如果你决定：
1
{
如果有一个名为comment的有效字段："__comment":"comment text goes here...", ，那么在实际注释上使用某种前缀可能是值得的。
关于为什么json中没有评论(或者更准确地说，为什么会在早期删除评论)的一个相当新的解释/理由：plus.google.com/118095276221607585885/posts/rk8qyggasr也可以参见，tech.groups.yahoo.com/group/json/message/156和其他相关讨论。
顺便说一下，Java谷歌GSON的JSON库支持评论。
如果我想对Accronym 和Abbrev 属性进行单独的评论呢？我以前用过这个模式，但现在停了，因为它不允许我这样做。这是一个黑客。如果我用__comment__ 作为属性名的首字母，也许可以。这是"评论"，仍然是一个黑客，但会让我对所有的文章发表评论。
@娟门德斯：你可以多次拥有同一把钥匙。
我们可以为此选择更多独特的注释键格式。像{"":"Comment text"} 这样的东西看起来不错。也有。
为什么GlossList 不是数组(GlossList: [ { .. }, { .. } ] )？
如果您使用一个模式来验证JSON，那么它可能会由于额外的字段而失败。
您也可以使用"/"：这看起来更原始，并且在同一父级中仍然可以重复。
@juanmendes可能太晚了，无法提供帮助，但对于多行注释，请将comment元素的值设置为字符串数组：["line 1", "line 2", "line 3" ] 。
问题是它改变了JSON的语义，例如改变了数组的长度。
当JSON用于人类预期的配置文件时，应该对它们进行注释，以便人类更好地理解。注释，这样的文件不再是有效的JSON，但有解决方案。例如，谷歌的Gyp支持风格的评论。JNESS.MIN将帮助您从输入文件中丢弃C/C++风格的注释。
有json5(5 指ecmascript 5(及更高版本))。
现在有许多库和框架支持JSON文件中的注释。在C Land中，newtonsoft的json.net支持它们，因此您将看到各种json的整个.NET核心配置文件中使用的注释。
如果您通过API返回JSON，那么客户机应该使用HTTP选项动词来读取JSON描述/注释。
XML想要返回其文档。
是的，你可以试着用{"//":"Your comment"} 。
但是要小心！一些完全解析引擎需要@jsonignorperites注释，否则它们会将未知字段视为错误。
仅捕获@michaelburr提供的第一个链接的相关摘录(第二个似乎无法恢复)："假设您使用JSON保存配置文件，您希望对其进行注释。继续，插入所有你喜欢的评论。然后把它通过JSMin 传输，然后把它交给JSON解析器。
我2012年6月评论中的一个链接不再有效。另一位读者(@douglasgross)提供了当前链接：groups.yahoo.com/neo/groups/json/conversations/topics/156
谢谢你的回答！在编写JSON脚本时，我考虑添加一个普通的注释(//)，vscode的jslint用一条红线永久地突出显示了注释，说"JSON中不允许有注释"。
@Danger89可以，但这会更改数组的长度。但是，我看到在教程中确实使用了这一点，在这些教程中，代码不会在生产中使用。
_comment 也是作曲家seldaek在98b0af1年所承诺的composer.json内部的官方解决方案。@但是如果我们有一个叫做__comment 的场呢？我们将需要一个新的领域，___comment 。
不允许，JSON中不允许使用//… 或/*…*/ 格式的注释。此答案基于：
网址：http://www.json.org
RFC 4627：用于javascript对象表示法(JSON)的application/json 媒体类型
RFC7159 JavaScript对象表示法(JSON)数据交换格式-废弃：46277158
如果您想用注释来注释您的JSON(从而使它成为无效的JSON)，那么在解析或传输之前将其缩小。Crockford本人在2012年的配置文件中承认了这一点。
@alkuzad：当涉及到正式语法时，必须有一些明确表示它们是允许的，而不是相反的方式。例如，选择您的编程语言：仅仅因为某个期望的(但缺少的)特性没有被明确地禁止，并不意味着您的编译器会神奇地识别它。
对。JSON格式在元素之间有很多死区，并且在这些区域中不区分空间，所以您没有理由不能在其中使用单行或多行注释。许多解析器和小型化器也支持JSON注释，所以只要确保您的解析器支持它们就行了。JSON经常用于应用程序数据和配置设置，因此现在需要注释。"官方规范"是一个不错的主意，但它是不够的和过时的，所以太糟糕了。如果您关心有效负载的大小或性能，请缩小JSON。
虽然你的回答是绝对正确的，但应该说这是B。由于有如此多的最终用户遇到了对JSON配置的需求，所以注释非常有用。仅仅因为一些锡箔帽决定JSON是并且必须始终是机器可读的，而忽略了人类需要阅读它的事实，这是对小头脑的嘲弄。
@你显然不是第一个抱怨JSON限制的人…这就是为什么我们有允许注释的解析器，以及其他格式(如yaml和json5)的原因。然而，这并不能改变JSON是什么的事实。相反，我发现有趣的是，考虑到所讨论的局限性，人们开始将JSON用于一开始显然不够的目的。不要责怪JSON格式；责怪我们自己坚持在不太适合的地方使用它。
如果您选择，请包含注释；在解析或传输之前，请用一个小型化器将它们去掉。
我刚刚发布了json.minify()，它从一个JSON块中删除注释和空白，并使其成为可以解析的有效JSON。因此，您可以像这样使用它：
1
JSON.parse(JSON.minify(my_str));
当我发布它的时候，我受到了很多人的强烈反对，他们甚至不同意我的想法，所以我决定写一篇综合性的博客文章来解释为什么JSON中的评论有意义。其中包括来自JSON创建者的这一著名评论：
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. - Douglas Crockford, 2012
希望这对那些不同意json.minify()为什么会有用的人有帮助。
我对json.minify()唯一的问题是它真的很慢。所以我自己做了一个实现，做了同样的事情：gist.github.com/1170297。在一些大型测试文件中，实现需要74秒，而我的实现需要0.06秒。
如果您可以将建议的替代算法提交给github repo for json.minify()，以便将其移植到所有支持的语言：github.com/getify/json.minify，那就太好了。
Perl的JSON支持注释。
JSON中的注释没有意义。JSON并不是一种文件格式，只是一种数据包交换格式。如果您需要类似于注释JSON的东西，请使用yaml。
@维克托，你为什么要在数据包里写评论？浪费空间。如果出于教学目的，只需把它们放在别处，或者接受你破坏了格式。在实际应用中，它们不应该是必需的。
从JSON的作者那里，你可能会发现很有趣地听到为什么注释被遗漏在规范之外：youtu.be//c-joynuqjs？T＝48 M53S
@我已经听过道格关于这个话题的想法很多次了。很久以前，我在我的博客博文：blog.getify.com/json-comments中提到过这些问题。
@Marnenlaibow-Koser仍然可以有效地使用注释，甚至用于数据流(甚至数据包)的使用：包含诊断元数据(如创建时间或源)是XML的常见用法，并且对JSON数据也非常敏感。反对注释的论点是肤浅的，任何文本数据格式都应该允许注释，不管暗示的预期用途如何(没有任何规范建议JSON不能在其他地方使用，fwiw)
@数据流中的statxman no.注释只是浪费的字节。如果不能从流本身推断出创建时间之类的元数据，那么为什么不让它成为流中实际的、可解析的内容呢？评论的理由很肤浅：如果某件东西值得包括在内，那么它就值得作为数据包括在内。
@斯塔克曼，我相信我会用事实来支持我所说的每一句话，以免让它成为我个人的观点。如果有什么我没有充分备份的，请告诉我。"你认为所有元数据都应该是数据的说法是胡说八道："不，你在这里显然是错的。我认为包含元数据的唯一原因是它可以被解析。如果要对它进行解析，那么只需将其变成真实的数据，而不是注释。您是否有一个不起作用的用例？
@Staxman"大多数其他文本格式都能识别这一点(XML和Yaml都有注释)"XML和Yaml是为文件设计的；JSON只是从JavaScript中提取出来的，我认为它使文件语法变得糟糕(在这种情况下，Yaml甚至XML的工作效果更好)。的确，JSON文件有时可能需要注释，但当Yaml做得更好时，JSON文件本身就是一个坏主意。：)
我的标准用例是流式传输的日志文件，它们被聚合或存储；因此流/文件的区别是虚拟的和暂时的。关于跳过：所有的属性都是可见的，有两种主要的方法来处理它：(a)经典的，你必须知道所有的东西是什么(至少在某种程度上你可以跳过它)，或者(b)"任何东西都去"，即只使用你知道的。在后一种情况下，跳过元数据是很简单的。但是我看到你不能想象诊断只是评论的简单概念——在这里没有必要互相争论。
@statxman"我的规范用例是日志文件"-本身就有问题；JSON不是一种好的日志格式(与yaml或xml相比，标点太多)。在后一种情况下，跳过元数据是很简单的事情。"—这是不使用"经典"方法的有力理由(一般来说，它太容易破坏)。但是我看到你不能想象诊断评论这个简单的概念——你所说的仅诊断评论是什么意思？如果你不解释的话，我无法想象。：)
与XML相比，JSON的标点符号太多了？你能解释一下你的意思吗？下面是一个json示例，用于在django：["model"："foo.bar"，"pk"：1，"fields"："name"："foo"，"customer_number"：12345]中加载设备，XML中的情况与此类似：<？xml version="1.0"encoding="utf-8"？>foo 12345
@manicdee您对XML中的标点符号是正确的；我试图简短一些，但最终在这方面不准确。修改后的语句：与yaml相比，json标点太多，与yaml或xml相比，它是一种糟糕的面向文件的语法。(对于记录，我每次都会为流选择JSON，为文件选择YAML，而不选择XML，除非有特定的外部XML需求。)
这个答案的问题在于JSON是一种序列化格式，因此必须为每种语言编写一个小型化程序(或者为每种解析器编写一个内置的小型化程序)。现在我该如何为C找到一个JSON迷你放大器？
如果JSON要得到普遍的接受(它基本上是这样做的)，那么它应该具有普遍的应用。示例：JSON可以用作应用程序配置文件。此应用程序需要注释。
@Kylesimpson 404在你的博客链接上，如果你有新的副本，更新链接
博客帖子链接(json中的注释很有意义)被破坏：Server not found 。你能更新你的答案吗(例如，如果没有博客文章的新位置，删除链接等)？
博客文章链接已修复。
这个答案滥用了crockford的评论——jsmin是一个javacript小型化程序，而不是一个json小型化程序。Javascript小型化程序接受Javascript作为输入，而不是JSON，因此支持注释。Crockford的评论绝不能被扭曲，意味着JSON中的评论是可以接受的，或者JSON的微型化器应该支持评论。充其量，这是一个扩展，充其量，这是一个安全漏洞，因此，反弹是可以理解的，使用Crockfords的评论来证明这是一个漏洞。
有趣的是，从JSON中删除了注释能力。无论何时何地，我都会被提醒去评论我的代码。现在，我在JSON中有一个巨大的配置/数据文件，它不能被评论以供将来参考，因为出于某种原因，有人认为评论是不必要的/愚蠢的。
为了投入我自己的两分钱，如果JSON应该是一种纯粹的"数据包交换格式"，那么它应该被实现为一种严格的二进制格式。正如它所代表的那样，数据被表示为一种人类可读的基于字符串的语法，逻辑上它遵循的是，任何设计为人类可读的东西都应该允许注释。
通过设计，注释从JSON中删除。
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
资料来源：Douglas Crockford关于G的公开声明+
我认为JSON应该比XML更具可读性？注释是为了可读性。
无论如何，您可能会很淘气，在json中添加解析指令："uu directives"："n"："datetime.now"，"validate"："n"……看起来山药是前进的道路…
删除/* */ 的注释也使json成为yaml的更好的子集。
@但是Yaml允许# 的评论，所以你的观点是有点不正确的。
@Juanmendes我不明白为什么这会使我对JSON/YAML兼容性的观点变得毫无意义。你认为我的观点是什么？
@我认为你的观点是，它不应该有评论，因为它使它不是Yaml的一个子集。我是说Yaml确实有评论，所以使用它作为您不愿意在JSON中发表评论的原因似乎是错误的。
@Juanmendes并不是"不应该"，因为它只是一个变化的好处(我个人觉得这是一个痛苦，我不能在JSON文件中评论)。请记住，JSON也是javascript的一个子集，而yaml和javascript具有相互不兼容的注释语法。yaml使用# ，而javascript使用// 和/* */ 。JSON不能使用# 作为注释而不与javascript不兼容。JSON不能既是yaml和javascript的子集，也不能有注释。
就像莉斯·莱蒙说的那样，"成交破坏者，女士们"！耶稣……所以用一句"省略"来测试某件事，又称"评论"(在正常宇宙中)。你必须删除行吗？不，谢谢！随时给我一些好的、令人讨厌的、不完整的XML！
@克丽斯纳什，它并不意味着比XML更可读，只是人类很容易阅读。json.org和，json很容易被人阅读。评论增加了额外的信息，但并不能让人们更容易阅读。
个人意见：不允许评论是站不住脚的。除了构建一个忽略注释的非标准JSON解析器之外，我别无选择，只能对我的配置文件进行解码。
@为定义良好的格式编写自己的解析器总是不够完美。我发现像Java属性或普通的旧IN这样的格式更适合配置文件。Java、C++、Python和NoDEJs都有一个或另一个内置或库支持。我特别喜欢ini文件。要么就是这样，要么总是用一个健壮的自述文件来补充配置。
@Arturczajka我仍然不喜欢json不支持评论这一事实，但我尝试了一下，我必须承认，在json上使用这些评论对于配置文件更有意义。感谢你的回应，希望更多的人在阅读这段对话时会改变主意。(做一个解析器更像是一个练习：)
经典。我不认为你必须限制可用性，因为有人可能会滥用某个特性。这只是教条和短视。正确的做法是创建一种机制，在JSON中包含注释，就像其他语言一样。我们不应该把带宽浪费在关于保持"纯洁"的毫无意义的哲学圣战上。克服它，添加评论，继续前进。
"我从JSON中删除了注释，因为我看到人们使用它们来保存解析指令"。根据这个逻辑，他还应该删除字符串类型。糟糕的决定。
Crockford后来继续写道："假设您使用JSON来保存配置文件，您希望对其进行注释。继续，插入所有你喜欢的评论。然后通过jsmin将其传递给JSON解析器。"有关更多信息，请参见@kyle simpson关于json.minify的答案。
谁会在意有人在JSON中使用注释来包含解析指令？说真的？荒谬的因此，如果您将自己的解析器的非标准解析指令放在注释中，遵循官方规范的解析器将忽略它们。否则，人们要么不使用JSON，要么利用黑客将注释作为数据包含进来，这肯定比在注释中使用自定义解析指令要好得多。为此，人们还将把他们的自定义解析指令作为数据放到JSON流中。这是一个愚蠢的论点，不能使用评论是令人讨厌的。
老实说，是否从来没有人将XML中的注释用于自己的自定义处理指令？它是否破坏了XML互操作性？是否有其他语言或数据格式允许在文件中添加评论？
在JSON中没有评论感觉是错误的。JSON中允许格式化(空格、换行符)，并且格式化和注释之间没有根本区别。
这就像要求所有的自行车都有训练轮，因为有些人不能骑自行车。删除一个重要的功能，因为愚蠢的人滥用它是糟糕的设计。数据格式应该优先考虑可用性而不是防白痴。
@但那个特定的模型有训练轮。用三轮车做类比会更好。如果您不喜欢，请使用另一个类似yaml的文件或属性文件。并不是所有的东西都应该被设计来掌握你能想到的每一个可能的特性。
JSON的关键是它只包含数据。如果您觉得需要注释，那么应该使用XML，而不是JSON。处理指令也是如此(XML也有这些指令)。真的，真的……如果您在矩形数据(行和列)之外使用JSON，那么您可能是错的，应该使用XML。
删除注释是一个"坏主意"。由于注释也是阅读注释的人的数据，因此删除注释是一个错误的参数，因为它们不是数据。此外，可以认为任何语言、规范文件、配置文件等中的所有注释都是数据。仅仅因为它不适用于机器，并不意味着它不是数据。
免责声明：您的保证无效
正如已经指出的，这种黑客利用了规范的实现。并不是所有的JSON解析器都能理解这种类型的JSON。流解析器尤其会阻塞。
这是一个有趣的好奇心，但你真的不应该把它用于任何事情。下面是原始答案。
我发现了一个小技巧，它允许您在JSON文件中放置注释，这些注释不会影响解析，也不会以任何方式更改表示的数据。
似乎在声明对象文本时，可以使用相同的键指定两个值，最后一个值优先。不管你信不信由你，JSON解析器的工作原理是一样的。因此，我们可以使用它在源JSON中创建注释，这些注释不会出现在解析的对象表示中。
1
({a: 1, a: 2});
如果我们应用此技术，您的注释JSON文件可能如下所示：
1
{
上述代码是有效的JSON。如果你分析它，你会得到这样一个对象：
1
{
这意味着没有评论的痕迹，也不会有奇怪的副作用。
快乐黑客！
从规范：对象中的名称应该是唯一的。
对，但这不是语法错误，所有的实现都处理相同的错误。所以我觉得使用起来很安全。不是哲学上的，而是实践上的。
"所有的实现都处理相同的问题"-这是一件很难证明的事情。
JSON中的元素顺序不受保证。这意味着"最后一个"项目可能会改变！
@sep332是手工编辑的json/config文件。
@来自RFC2119的昆廷："3.如果这个词或形容词"推荐"的意思是在特定情况下可能存在忽视某一特定项目的正当理由，但在选择不同的课程之前，必须理解并仔细权衡其全部含义。"
@tracker1—顺序不一定，因为重要的是解析器，而不是编写文件的人。JSON规范没有描述如果有重复的键(它说您应该使它们唯一)，应该发生什么，因此一些解析器可能取第一个，而其他的可能取最后一个，而其他的则会掉下来。
这显然违反了规范(参见上面的注释)，不要这样做。ietf.org/rfc/rfc4627.txt？号码＝4627
@是的，必须理解全部含义。如果不测试每个JSON解析器，就无法理解这些(因为人们会不断地编写新的解析器…)。
对于解析器来说，放弃现有键的值而不是重写它们是完全合理的。
目前在json.org上列出了100多种不同的实现。我敢打赌他们中至少有一个处理不一样。
我曾经对具有双关键字的JSON文件有过不少麻烦，只是因为规范中没有明确禁止它。请不要建议其他人这样做。
我自己的实现(对于嵌入式系统，找不到与需求匹配的现有实现)总是取第一个键以防重复。你真的不能假设这会奏效。
否-如果解析器正在流式处理呢？如果解析器将它读到一个未定义键顺序的字典中，该怎么办？用火杀死这个。
@昆廷，我只是说，规范不清楚如何处理这个案件，这是一个聪明的黑客，这是"合法的"，但当然不鼓励。
否决了这是个坏主意，单纯而简单。您滥用了JSON规范的灰色区域，而将这种做法推广给其他人是不负责任的。这是一个黑客；别这么做。
你在乞求这个在你脸上爆炸。与其他人提到的一样，解析器可能会直接拒绝您的JSON，回送"注释"而不是值，或者以神秘的方式失败，例如为同一个键推送两个事件(很可能是流式解析器)。例如，最近的APK签名漏洞实质上利用了相同的东西，即多个非唯一密钥(文件名)的未定义行为，而不是JSON。
这在很多层面上都是错误的，我甚至不知道从哪里开始。我将把它放在这里——pragprog.com/the-constructival-programmer/extracts/coulsion——然后试着忘记我刚才看到的。
有关错误情况，请参阅此问题：stackoverflow.com/questions/4912386/&hellip；
坏主意-导致混乱，违反规范，而不是未来的证据和JSLint取消了JSON的资格。
这是一个伟大的黑客在今天的背景下。JSON解析在服务器端和浏览器端都进行了简化。IE8之后(包括IE8)的所有浏览器都支持json.parse。所以实际上每个人都应该使用内置的JSON解析。您将仅出于遗留原因使用自定义分析器。而且，内置的JSON解析器极不可能改变其行为并破坏向后兼容性。
…从以上我的评论继续。我们现在唯一需要做的就是将其标准化，这样用户就不会感到困惑。例如，我们可以通过执行类似"**这是一个注释**"的操作来表示它是一个注释。
在JSON工作组的IETF中，我们一直在研究RFC4627bis(加入我们并提供帮助！)datatracker.ietf.org/wg/json)，我们发现了实现人员在对象中对重复名称使用的四种不同方法：使用第一种方法；使用最后一种方法；报告所有方法并让调用者选择一种方法；返回错误并停止解析。如果您的数据不能经受住所有这些方法的考验，那么它在实践中就不会进行互操作。
糟糕的黑客。这是JSON解析器的问题。至少IAM策略文件(AWS)不接受重复的JSON密钥。microsofttranslator.com/bv.aspx？从=&；to=en&a=http://hellip；
这是我在StackOverflow上见过的最糟糕的答案之一。它可以在任何时候断开，而且它不那么聪明，因为它不能使它像常规注释那样特别可读。人们可能总是想知道我们是否有一个评论或者一个真实的数据。JSmin似乎是一个更干净(更可读)的解决方案。也就是说，IT行业仍然应该感谢你的笑话。
Solr使用多个键。这与主要的开源搜索服务器不兼容！！！！
把它和Eli的答案结合起来，在四周插入重复的"_comment" 键，这样你就可以得到两个世界中最好的。
如果您有一个解析器，当发现重复的键时出错以防止错误地丢失数据，那么这将中断…以这种方式创建注释不是一个好主意，因为它们不是注释，如果解析器使用某种逻辑，那么它不会自上而下地读取，那么它也会中断。请不要用这个，因为它不符合规格。
这个答案是癌症。我的开发人员在没有阅读评论的情况下也这样做了。现在，我们正在燃烧自己，同时从RPC服务器流式传输内容。
"所有的实现处理它都是一样的"-JJU可以选择抛出这些JSON
这是最具争议的帖子。
您可以很容易地声明您的"comment"属性要么有一个字符串作为其值，要么有一个字符串数组。这样，您可以在保持有效JSON的同时，根据自己的喜好包含尽可能多的注释行。
我真的很喜欢你的想法……尽管规范声明键名是唯一的，但它只是一种表达方式，否则最后一个键会覆盖其他键。
@阿克谢克汉德尔：你显然没有理解这个评论。简而言之：当一个对象中遇到非唯一的名称时，解析器会选择四种不同的策略。此外，规范没有保证任何顺序的持久性，所以"最后一个"无论如何都没有意义。别再胡思乱想了，好像它是真的一样。
您将进入实现依赖的领域。
请允许我鼓起勇气做这种事。
这是一个不错的黑客，但邪恶的黑客。
Matlab的jsondecode 解析器将创建api_host 和api_host_1 字段等。
JSON不支持注释。它也从未打算用于需要注释的配置文件。
hjson是一种针对人类的配置文件格式。语法宽松，错误少，评论多。
参见javas.Org，用于JavaScript、Java、Python、PHP、RIST、GO、露比和C *库。
如果您查看规范，就会发现它是JSON的超集。您可以从/转换为JSON。
投票赞成的很明显这是一个很好的变化，不开放的保守主义者只会喜欢憎恨。我希望您的实现得到进一步的了解——甚至可能比原来的更受欢迎；)我希望有人也能用Ruby实现它。@阿德尔弗斯语言的定义是你自己的观点或观点。如果你是一个保守的"开发人员"，这并不能证明你是一个更好的人，而且更糟糕的是，把自己关在有限的空间里。不要轻易地把人看成是糟糕的开发人员。
很抱歉，@konsolebox。也许在阅读ecma international.org/publications/files/ecma-st/ecma-404.p&zwnj；&8203；df之后，您可能会重新考虑您的"定义良好的JSON是您的观点"视图。这是一个真正的标准，开发人员实现自己的"特殊"版本会导致碎片化、混乱和大量浪费时间。看看Web开发人员在编写代码时留下的混乱，因为每个浏览器实现的标准版本略有不同。JSON语言可能并不完美，但碎片化更糟。是的，这只是一个观点，你可以自由地反对。
我很佩服你的勇气，但你有点在发明山药。如果你想要很多的灵活性和可读性，可以使用yaml(实际上不要：stackoverflow.com/questions/450399/&hellip；)或者坚持简朴，但又不含糊的json。
我发现最用户友好的配置格式仍然是ini。它很简单，语法也不是很重。这使得用户只需将他们的脚趾伸进配置池就不那么害怕了。
每当您需要json作为配置时(需要注释)，请将文件命名为".js"而不是".json"。JS当然可以处理任何有效的JSON对象，另外还可以处理注释。这就是为什么它是"webpack.config.js"而不是"webpack.config.json"(webpack.config.json中也有很多这样的原因：p)
"它也从未打算用于需要注释的配置文件。"但JSON用于JSON模式，其中注释非常有用。注释可以包含在描述元素中，但这会将注释转化为数据。它们对于文档也很有帮助，如果能够在不首先删除注释的情况下验证JSON，那将是非常好的。
考虑使用山药。它几乎是JSON的超集(实际上所有有效的JSON都是有效的yaml)，并且允许注释。
注意，相反的说法是不正确的(有效的yaml！=有效JSON)
@G33KZ0R是正确的，因此我将yaml描述为json的近超集。
@许多人已经指出答案是否定的。我建议了一个更好的方法来实现行动的目标。这是一个答案。
缺点：yaml 库没有随python一起提供。
@出血的手指所以安装它…
同意这是一个相关的替代方案。不过，如果您已经倾向于json:stackoverflow.com/questions/450399/&hellip，就不要使用yaml；
@toolbear：你链接的评论表明你不知道如何很好地使用yaml。我从来没有吃过山药。所以是的，使用yaml，即使你已经倾向于JSON了。
@ MaNeNeLeopkKoers:YUP，使用Java和Perl可用的YAML库必须是无能的，并且期望每个生成的YAML都被另一个错误地消耗掉。yaml interop是一个问题，但json interop不是，这完全是因为我缺乏知识。
@toolbear听起来像是写得不好的库的错误；不要把这归咎于格式。是的，你所说的模棱两可的话表明你缺乏知识，不过如果你有一个案例的话，我会对它感兴趣的。然而，缺乏知识可能是解析器实现者的一部分，不一定是您。
@MarnenLaibowKoser，一种用更简单的规范完成相同任务的格式更好。有完美实现的实用格式比有不完美实现的理想格式更好。并非所有错误libs的责任都在实施者的肩上；yaml规范是长的、密集的和迟钝的。它的维基百科条目引用了两个模棱两可的例子；如果必须在一个人和一种格式之间放置一个发射器来保护他们不受模棱两可的影响，那么这种格式就失去了对人友好的声明。JSON的索赔较少，而且大多是成功的，因为Yaml索赔较多，而且不足。
@Marnen Laibow Koser，我驳斥了你对我无能的暗示，详细地支持了我的主张，并稍微阐述了我的偏好/偏见，这些都是对我的山药批评的反映。我自己的进一步评论可能会减少回报。我对未来读者做出明智选择的能力充满信心。除了在接近自动寻的攻击的地方进行小规模的战斗，谢谢你的演讲。最后一句话是你的，如果你愿意的话。
@"图尔贝尔，没有人想袭击他。"一个有完美实现的实用格式比一个有不完美实现的理想格式更好-我不确定我同意。如果格式是理想的(并且是可实现的)，那么总是可以很好地实现。如果格式不理想，那么即使是完美的实现也不会非常好。：)"山药规格长、密、钝"——这实际上不是"钝"的意思，但山药规格很清楚。我没有在维基百科中看到任何含糊不清的地方；如果我遗漏了什么，请引用文章的特定部分。
YAML>>JSON。而python有一个很好的yaml库。我必须在斯卡拉自己滚-但还是值得的。
这个答案真的应该是一个评论。
此答案在完成向JSON添加注释时有效。它不再是标准JSON。但它仍然是JSON。comments+json+yaml loader=有效解决方案。一些框架/语言需要安装JSON。默认情况下，安装它是不使用yaml的不良借口。但装载时间和库大小是避免这种情况发生的有效原因。是否合适。有效答案。
@Tamusjroyce我不认为这是一个有效的解决方案，真的。如果你要使用山药装载机，那就全力以赴使用山药。如果您真的需要使用JSON(无论如何，这是一种糟糕的文件格式)，请遵循标准，不要使用注释。
有效的解决方案。即使不是最佳的。也许你正在发展，暂时需要评论。然后重构出来。
@Tamusjroyce，但这在所有情况下都不起作用，而且它很黑客，而且通常很糟糕。或者至少这是我的观点。：)
有一次，我使用yaml构建了一个配置文件解析器。它能够使用.ini、xml、yaml和json。吐出纯JSON。如果你使用的是把一些难看的东西处理成纯粹的东西，那么使用像yaml这样的重库是没有问题的。山药是任何东西，但黑客或敬畏。将其视为ETL或修复JSON工具。非常有用。甚至是一个删除注释的构建工具。我想到了Webpack。
@Tamusjroyce是的，我喜欢山药。作为黑客，我反对的是像yaml那样解析json+注释，而不是使用标准yaml或标准json。
你不能。至少这是我在json.org上的经验。
JSON在该页面上可视化了它的语法。没有关于评论的任何注释。
您应该编写一个JSON模式。JSON模式目前是一个提议的Internet规范草案。除了文档之外，模式还可以用于验证JSON数据。
例子：
1
{
您可以使用描述模式属性提供文档。
JSON模式是否有效？它存在，但是否由任何已知的库支持？
是的，JSON模式google组相当活跃，我建议您使用JSV来实现JSON模式验证器。
这只对结构化文档有帮助，而不是特殊文档
如果您使用clojure(我敢肯定您没有)，这里有一个功能合理的开源JSON模式解析器：github.com/bigmlcom/closchema
@json(.net)广泛支持json模式。
这并不适用于所有情况。我有一个手工配置的JSON，由其他具有自己模式的东西(包管理器)解析。在这一点上，我想要一个注释，例如/*最好使用x，而不是来自另一个包管理器，但是这个管理器还没有提供x。*.
如果您使用Jackson作为JSON解析器，那么您可以使用它来允许注释：
1
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
然后你可以有这样的评论：
1
{
您还可以通过设置以下内容从# 开始添加注释：
1
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
但一般来说(如前所述)，规范不允许评论。
当我尝试时，打开链接超时：The connection to the server was reset while the page was loading. 。
评论不是官方标准。尽管一些解析器支持C样式的注释。我使用的是jsoncpp。在示例中有一个：
1
// Configuration options
jsonlint不验证这一点。所以注释是特定于解析器的扩展，而不是标准的。
另一个解析器是JSON5。
替代JSON TOML。
另一种选择是JSONC。
groovy有一些用于处理JSON的内置类。JSonslurper可以处理注释。当然，官方规范中不允许使用注释，所以任何解析器中的这种行为都是非标准的和不可移植的。
以下是我在Google FireBase文档中发现的内容，它允许您在JSON中添加注释：
1
{
仅供参考，firebase realtime数据库不允许在密钥中使用"/"。所以这可能是一个很好的约定供你自己使用，但你不能在FireBase中这样做。
此方法破坏了一些库，这些库要求键必须是唯一的。我正在通过给评论编号来解决这个问题。
好的评论，我发现这个问题，所以…此部分似乎不包含在spec stackoverflow.com/questions/21832701/&hellip；
我想//1//2//3是可行的。
现在我倾向于这样使用："//foo"："foo comment"，"foo"："foo value"，"//bar"："bar comment"，"bar"："bar value"您可以对多个注释使用数组："//foo"：["foo comment 1"，"foo comment 2"]，"foo"："foo value"
抱歉，我们不能在JSON中使用注释…请参见json.org上的json语法图。
道格拉斯·克罗克福德说："为什么他删除了JSON中的评论，并提供了另一种方法来做到这一点？"
I removed comments from JSON because I saw people were using them to
Suppose you are using JSON to keep configuration files, which you
我相信您所指的只是用于文档目的的文本注释。这不是Web服务实际返回的内容。
Crockford后来继续写道："假设您使用JSON来保存配置文件，您希望对其进行注释。继续，插入所有你喜欢的评论。然后通过jsmin将其传递给JSON解析器。"有关更多信息，请参见@kyle simpson关于json.minify的答案。
这个答案与一年前发布相同报价的@arturczajka重复。
如果您的文本文件(JSON字符串)将被某个程序读取，那么在使用C或C++风格注释之前，它会有多困难？
答：这是一条单行线。如果这样做，那么JSON文件可以用作配置文件。
也许是迄今为止最好的建议，尽管作为交换格式保存文件仍然是一个问题，因为它们在使用前需要预处理。
我同意并在Java中编写了JSON解析器，可以在www. StudioMyKik.Org中使用，它确实如此。
尽管我认为，扩展JSON(不使用不同的交换格式)并不是一个好主意：请确保忽略字符串中的"注释"。"foo"："/*这不是评论。*/"
"…将是一行代码"嗯，不，事实上，JSON不是一种正则语法，正则表达式可以简单地找到匹配的/*对。您必须解析该文件，以确定/*是否出现在字符串中(并忽略它)，或者它是否被转义(并忽略它)，等等。此外，您的答案是无用的，因为您只是猜测(错误地)而不是提供任何解决方案。
凯尔·辛普森说的。另外，他也太谦虚了，无法引导读者找到他自己关于使用json.minify替代特殊regexp的答案。这样做，而不是这样。
一层JS兼容regex:myJson.replace(/("\/\/.*"|"\/\*(?:.| regexr.com/3p39p
如果将newtonsoft.json库与ASP.NET一起使用以读取/反序列化，则可以在json内容中使用注释：
//"name":"string"
//"id": int
或
/* This is a
comment example */
PS：只有6+版本的NewtonSoft JSON才支持单行注释。
对于那些不能三思而后行的人来说，还有一点需要注意：我在自己制作的ASP.NET Web应用程序中使用JSON格式进行基本设置。我读取文件，用newtonsoft库将其转换为设置对象，并在必要时使用它。
我更喜欢在JSON文件本身中写关于每个单独设置的注释，并且我真的不关心JSON格式的完整性，只要我使用的库可以使用它。
我认为这比创建单独的"settings.readme"文件并解释其中的设置更容易使用/理解。
如果你对这种用法有问题，对不起，精灵不亮了。人们会发现JSON格式的其他用法，您对此无能为力。
很难理解为什么有人在陈述事实时会有问题。
我假设有人发生了异常，因为上面的内容不再是JSON，或者是无效的JSON。也许加上一个简短的免责声明就可以了。
我完全同意你的观点，但是到目前为止，有883张赞成票没有回答，只是说明了显而易见的问题。思想的纯洁性高于有用的信息，这对你来说是如此。
我只是在配置文件中遇到这个问题。我不想使用XML(冗长，图形，丑陋，难以阅读)，或"ini"格式(没有层次结构，没有真正的标准等)或Java"属性"格式(如.ini)。
JSON可以做他们所能做的一切，但是它不那么冗长，更容易被人阅读——而且解析器在许多语言中都很容易并且无处不在。它只是一棵数据树。但带外注释通常是记录"默认"配置等内容的必要条件。配置永远不会是"完整的文档"，但是保存的数据树在需要时可以供人阅读。
我想有人可以使用"#":"comment" 作为"有效的"json。
对于配置文件，我建议使用yaml，而不是json。它(几乎)是一个更强大的JSON超集，但也支持更可读的结构，包括注释。
与JSON相比，您认为有多少种语言支持Yaml？
@Hamidam有十几种语言支持yaml:yaml.org，但是您可以问有多少语言支持内置的，而不需要依赖第三方的库。看起来像Ruby1.9.2。有人知道其他人吗？默认情况下，哪些语言提供了对JSON的支持？
yaml interop是一个谎言：stackoverflow.com/questions/450399/&hellip；。如果您的直觉是将JSON用于配置文件，请遵循它。
这很古老，但我认为使用不是一个好主意。JSON非常接近于JavaScript的语法。javascript支持两种类型的comment://和/*…*/如果我是你，我会坚持一种或两种类型的评论。
JSON背后的思想是在应用程序之间提供简单的数据交换。这些通常是基于Web的，语言是JavaScript。
但是，它实际上不允许这样的注释，将注释作为数据中的名称/值对之一传递肯定会起作用，尽管显然需要由解析代码忽略或处理该数据。
尽管如此，JSON文件并不打算包含传统意义上的注释。它应该只是数据。
查看JSON网站了解更多详细信息。
确实，JSON格式没有注释。我个人认为这是一个严重的错误——能够将注释作为元数据(而不是数据)对于XML来说是非常有用的。JSON规范的早期草稿版本确实包含了注释，但出于某种原因，它们被删除了。- -
@Statxman它们被丢弃，正是因为人们开始使用它们作为元数据。Crockford说它破坏了格式设计的兼容性，我同意：如果你想要元数据，为什么不把它作为实际数据包括进来呢？这样更容易解析。
元数据属于元数据构造(例如html
这正是它被删除的原因：用作元数据的注释会破坏互操作性。您也应该将元数据存储为JSON。
这个答案是多余的，写得更好，投票率更高，说的基本上是一样的，即使这可能是早先写的。祝你好运。
这取决于您的JSON库。json.net支持javascript风格的注释，/* commment */ 。
请参阅另一个堆栈溢出问题。
我相信这就是为什么我在这个asp.net vnext预览页面(在package.json下)的屏幕截图中看到一条评论：blogs.msdn.com/b/webdev/archive/2014/06/03/&hellip；，尽管我还没有在规范中找到任何东西。
JSON本机不支持注释，但您可以自己制作解码器，或者至少是预处理器来删除注释，这是完全正确的(只要您忽略注释，而不使用它们来指导应用程序如何处理JSON数据)。
JSON does not have comments. A JSON encoder MUST NOT output comments.
Comments should never be used to transmit anything meaningful. That is
cf:Douglas Crockford，JSON规范的作者。
Crockford后来继续写道："假设您使用JSON来保存配置文件，您希望对其进行注释。继续，插入所有你喜欢的评论。然后通过jsmin将其传递给JSON解析器。"有关更多信息，请参见@kyle simpson关于json.minify的答案。
JSON对于配置文件和其他本地用法很有意义，因为它无处不在，而且比XML简单得多。
如果人们有强烈的理由不在JSON中发表意见(无论数据是否有效)，那么JSON可能分为两部分：
json-com：在线上的json，或在传输json数据时应用的规则。
json-doc:json文档，或文件或本地的json。定义有效JSON文档的规则。
JSON-DOC将允许注释，并且可能存在其他细微的差异，例如处理空白。解析器可以很容易地从一个规范转换到另一个规范。
关于道格拉斯·克罗克福德对这个问题的评论(由@artur czajka引用)
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
我们讨论的是一个通用配置文件问题(跨语言/平台)，他用一个JS特定的实用程序来回答这个问题！
当然，特定于JSON的小型化可以用任何语言实现，但是标准化这一点，使得它在所有语言和平台的解析器中变得无处不在，所以人们不再浪费时间缺少这个特性，因为他们有很好的使用案例，在在线论坛中查找这个问题，让人们告诉他们这是个坏主意，或者建议很容易实现从文本文件中剥离注释。
另一个问题是互操作性。假设您有一个库或API或任何类型的子系统，其中有一些与之相关联的配置或数据文件。这个子系统是从不同语言访问。那么你是不是要告诉别人：顺便问一下在将注释传递给解析器之前，不要忘记从JSON文件中去掉注释！
不需要分割JSON。带有注释的JSON不再是JSON。但是，用注释注释JSON是完全可以接受的，只要确保在解析或传输之前将它们去掉。接受者不应为此负责。
Dojo工具包javascript工具包(至少是1.4版)允许您在JSON中包含注释。注释可以是/* */ 格式。Dojo工具包通过dojo.xhrGet() 调用使用JSON。
其他的javascript工具包也可以工作。
在选择最后一个选项之前，在试验备用数据结构(甚至是数据列表)时，这可能很有用。
不，不是这个。JSON没有评论。如果选择用注释注释JSON，请在解析或传输之前将其缩小。这不应该是接收者的责任。
我没有说JSON有评论。我也没有暗示在JSON中包含它们是合适的，尤其是在生产系统中。我说Dojo工具包允许您添加它们，这是(或者至少是)事实上的事实。在您的测试阶段有非常有用的用例。
接受评论是糟糕的巫毒，因此无效的JSON，dojo.xhrGet() 含蓄地鼓励接受。
我仍然支持升级JSON规范以允许评论。我完全赞成在传输JSON之前缩小和剥离注释，但是没有任何能力以任何标准方式对JSON进行注释，而不必在解析之前通过单独的实用程序传递它，这看起来很愚蠢。我还不可能在JSON配置文件上使用JSON编辑器，因为您的文件不是有效的JSON。
如果使用JSON5，则可以包含注释。
JSON5是对JSON的一个提议扩展，旨在使人类更容易手工编写和维护。它通过直接从EcmaScript 5添加一些最小的语法特性来实现这一点。
你能加一个例子吗？那么你可能真的需要这些额外的字符。
SO指南要求提供实际答案。不需要只链接的答案。您可以查看指南stackoverflow.com/help/how-to-answer
它的用户也是如此。这意味着我可以提供一个答案，如果我有同样的方式，我可以评论你，如果它不遵循指导方针。这就是为什么要成为一个伟大的资源。
JSON is not a framed protocol. It is a language free format. So a comment's format is not defined for JSON.
As many people have suggested, there are some tricks, for example, duplicate keys or a specific key _comment ，您可以使用。这取决于你。
您可以在JSONP中有注释，但不能在纯JSON中有注释。我刚刚花了一个小时试图让我的程序使用HighCharts中的这个例子：http://www.highCharts.com/samples/data/jsonp.php？文件名=aapl-c.json&；callback=？
如果你按照链接，你会看到
1
?(/* AAPL historical OHLC data from the Google Finance API */
因为我在本地文件夹中有一个类似的文件，所以相同的源策略没有问题，所以我决定使用纯JSON…当然，$.getJSON 也因为这些评论而默默无语地失败了。
最后，我向上面的地址发送了一个手工HTTP请求，意识到内容类型是text/javascript ，因为jsonp返回纯javascript。在这种情况下，允许使用注释。但是我的应用程序返回了内容类型application/json ，所以我不得不删除注释。
这是一个"你能"的问题。这里有一个"是"的答案。
不，不应该使用重复的对象成员将侧通道数据填充到JSON编码中。(参见RFC中的"对象内的名称应该是唯一的")。
是的，您可以在JSON周围插入注释，您可以解析这些注释。
但是，如果您想要一种将任意侧通道数据插入和提取到有效JSON的方法，这里有一个答案。我们利用JSON编码中数据的非唯一表示。这在RFC的第二部分的"在六个结构字符之前或之后允许空白"下是允许的。
*RFC只声明"在六个结构字符中的任何一个字符之前或之后都允许空白"，而不显式提及字符串、数字、"假"、"真"和"空"。在所有实现中都忽略了这个省略。
首先，通过缩小JSON使其规范化：
1
$jsonMin = json_encode(json_decode($json));
然后用二进制编码注释：
1
$hex = unpack('H*', $comment);
然后将您的二进制文件：
1
$steg = str_replace('0', ' ', $commentBinary);
以下是您的输出：
1
$jsonWithComment = $steg . $jsonMin;
RFC只声明"在六个结构字符中的任何一个字符之前或之后都允许空白"，而不显式提及字符串、数字、"假"、"真"、"空"。在所有实现中都忽略了这个省略。
为了获得更高的评论密度，您不能用三元编码您的评论，并使用空格、制表符和换行符来填充它吗？
JSON曾经支持这些评论，但它们被滥用并从标准中删除。
来自JSON的创建者：
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. - Douglas Crockford, 2012
官方的json网站位于json.org。JSON是ECMA国际公司的标准。总是有一个请愿程序来修改标准。由于几个原因，注释不太可能添加到JSON标准中。
JSON按设计是XML的一种易于逆向工程(人工解析)的替代方案。甚至简化到注释是不必要的。它甚至不是标记语言。目标是稳定和互操作性。
任何理解对象方向的"has-a"关系的人都可以理解任何JSON结构——这就是关键所在。它只是一个带有节点标记(键/值对)的有向非循环图(DAG)，这是一个接近通用的数据结构。
唯一需要的注释可能是"//这些是DAG标记"。密钥名称可以根据需要提供信息。
任何平台都只需几行代码就可以解析JSON。XML需要在许多平台上不可行的复杂OO库。
注释只会降低JSON的互操作性。除了真正需要的是标记语言(XML)之外，没有其他东西可以添加，也不关心持久化数据是否容易解析。
我不明白为什么这个答案会被否决。这是合理的解释。imho，json中需要注释是因为配置文件滥用了这种格式。我们需要在配置中有注释，因此使用JSON(由标准定义)进行配置是非常糟糕的做法。有些解析器允许行注释，但是文件不是严格的JSON格式，不应该称为JSON。
因为，正如克罗克福德所说，"缺乏评论让一些人感到悲伤"。Jackson似乎存在于JSON和XML之间的邪恶DMZ中。
我们正在使用strip-json-comments 进行我们的项目。它支持如下内容：
1
/*
安装和使用方法如下：
1
var strip_json_comments = require('strip-json-comments')
var json = '{/*rainbows*/"unicorn":"cake
<hr><P>要将JSON项目剪切成部分，我添加了"虚拟注释"行：</P>[cc]{
"#############################" :"Part1",
"data1" :"value1",
"data2" :"value2",
"#############################" :"Part2",
"data4" :"value3",
"data3" :"value4"
}
您已经在JSON中模拟了一个ini文件结构。请放下你的金锤子。
RFC说"对象中的名称应该是唯一的"。还可以看到这个在分析JSON时出错的人，如：stackoverflow.com/questions/4912386/&hellip；
如果您使用一个模式来验证JSON，那么它可能会由于额外的字段而失败。
如果您真的决定向JSON添加注释，那么这样做会更有意义：{ "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." } ，它保持名称的唯一性，并允许您添加您喜欢的任何字符串值。这仍然是一个拼凑，因为注释不应该是JSON的一部分。作为另一种选择，为什么不在JSON之前或之后添加注释，而不在JSON内添加？
有一个好的解决方案(hack)，它是有效的JSON。只需把同一把钥匙做两次(或更多)。例如：
1
{
因此，JSON将理解为：
1
{
如果有人循环对象，此方法可能会导致一些问题。在第一次迭代中，程序将没有任何信息表明条目是注释。
RFC说："对象中的名称应该是唯一的"。请参阅：stackoverflow.com/questions/4912386/&hellip；上报告的此错误。
这样做是一个创建JSON的邀请，它将在将来的某个随机点上向您爆炸。
不能保证对象名/值对列表中的顺序很重要。解析器可以"无序"地解析它们，然后这就被破坏了。
使用这种代码的JSON解析器的行为是未定义的。没有什么可以说，解析器的行为就像只有最后一个值存在一样。它的行为就像只有第一个值存在，或者任何值，或者像一个数组一样。
这是非常糟糕的建议。正如其他人之前指出的，这种行为是未定义的。不同的解析器将显示不同的行为。有些会返回第一个"param"，有些会返回第二个"param"，有些会因错误而停止。这句话以前说过，但这个建议太糟糕了，值得重复，以至于很糟糕。
这可能在特定的实现中有效，但它将是脆弱的，除非您能够控制接收JSON的任何内容，而其他任何东西都不会使用JSON数据。
@toolbear json不会"爆炸"。解析器可以。这是一个令人怀疑的解决办法。但并不比加上"注释"更糟糕。也许总比什么都没有好。
它不能在严格模式下工作！
JSON没有被排序，所以这将花费大约50%的时间(至少在go中，如果没有定义排序，它是随机的)
JSON的作者希望我们在JSON中包含注释，但在解析它们之前先将它们去掉(请参见MichaelBurr提供的链接)。如果JSON应该有注释，为什么不标准化它们，让JSON解析器来完成这项工作呢？我不同意那里的逻辑，但是，唉，这是标准。使用其他人建议的yaml解决方案是好的，但它需要依赖于库。
如果您想删除注释，但不想拥有库依赖关系，这里是一个两行的解决方案，它适用于C++风格的注释，但可以适用于其他类型的注释：
1
var comments = new RegExp("//.*", 'mg');
请注意，此解决方案只能在可以确保JSON数据不包含注释发起程序的情况下使用，例如('/')。
另一种实现JSON解析、剥离注释和不增加库的方法是在JavaScript解释器中评估JSON。当然，这种方法的警告是，您只想评估未受污染的数据(没有不受信任的用户输入)。在node.js中有一个这种方法的示例——另一个警告是，下面的示例只读取一次数据，然后将其缓存：
1
data = require(fs.realpathSync(doctree_fp));
这不起作用，因为它不考虑/*是否可以转义，或者可能在字符串文字中。JSON不是正则语法，因此正则表达式是不够的。您必须分析它以找出注释在哪里。
它将在有限的情况下工作，在这种情况下，您可以确保JSON不包含任何包含注释字符串的数据。感谢您指出这一限制。我已经编辑了这篇文章。
+1个链接！实际上，我认为不支持注释是一件好事，因为当在客户机和服务器之间发送数据时，注释绝对是无用的，而且会毫无意义地消耗大量带宽。就像有人要求在MP3结构或jpeg数据块中添加评论…
谢谢你的+1！您必须记住，JSON不仅仅用于服务器/客户机通信。此外，根据您的数据大小和数据包大小，发送注释可能根本不会增加带宽，而且对于您的客户机来说，访问额外的上下文可能很有用，如果您不想通过网络发送注释，您可以让服务器删除它们。
凯尔·辛普森说的。另外，他也太谦虚了，无法引导读者找到他自己关于使用json.minify替代特殊regexp的答案。这样做，而不是这样。
@Alexiswilke，"注释绝对是无用的，它可以免费提供大量带宽"——这就是为什么在规范中应该支持注释的原因。只需看看建议的解决方法的数量，这些方法涉及到许多不同但类似的将注释作为数据放入JSON的方法，确保一个小型化工具不能删除注释，确保它们通过网络传输，并强制远程解析器以不同程度的成功处理它们。你试图从思想上强迫人们，他们会在你周围找到出路。就这样…
克雷格，为什么不使用C/C++类似的注释来使用EDCOX1？0来删除它们呢？(对于来自gcc 的cpp ，您希望使用-P (大写P)来避免# ... 条目。)我认为这很容易。
@Alexiswilke没关系，只是它不是一个JSON标准，而且你不能假定我正在使用Linux，并且能够通过cpp解压和传输文件——我没有。所以我把代码添加到我的程序中，去掉C/C++注释。我的观点是，不管怎样，人们都会找到一种添加注释的方法，但是现在他们会以百万种稍有不同的格式将注释添加为JSON数据，而自动化工具无法检测到这些格式，也无法从数据流中删除这些格式，因此，尝试删除注释会反常地保证JSON中存在注释，并增加数据传输量。
@Craig，作为旁注，CPP在MS Windows下可用。尽管坦率地说，写你自己的小工具可能比和Cygwin或Mingw混在一起容易…现在我同意它不完全是JSON，但是它看起来像许多解释器理解类似的扩展(C/C++注释)。
@不过，Alexiswilke在某种程度上，难道所有这些看起来都有点像是为了能够在JSON文件中发表评论而进行的英勇之举吗？在我的例子中，我只需要一点代码(而不是一个完整的C/C++编译器，运行在一个额外的运行时库中，如果在CygWun/Min下运行，就可以了)，在我可以通过JSON解析器传递配置文件之前删除注释。我还可以检测配置文件何时更改并动态地重新加载它们，等等。我不能简单地在文件中添加注释而不担心它，这有多糟糕？真是太差劲了。那是多少钱。；-)
您的JS解释器解决方案是NancyPelosi解析JSON的方法：您必须通过它来找出其中的内容。当然，可能会有意想不到的副作用。
请注意，regexp不能与URL一起使用："url"："http://…(哎哟！)。您肯定需要一个真正的"json+comments"解析器来删除注释。
是的，不，道格拉斯·克罗克福德不希望人们在JSON中包含注释，这就是他删除注释的原因。看看我的答案。他的立场是"用一些不可互操作的预编译程序来完成它，而不是在JSON中"(如Jackson等)。
叹息。为什么不添加字段，例如
1
{
只需确保您的"notex"名称不与任何实际字段冲突。
问题出在Just make sure your"notex" names don't conflict with any real fields. 上。这不是一个任意的解决方案。
这也提出了一个问题，即在传输之前，不能通过缩小实用程序去除注释，不可避免地会导致传输的数据量更大，而在传输的另一端却没有任何用途。我真的觉得将注释支持从JSON规范中去掉是不幸的。特别是因为人们会一起破解解决方案。将支持从规范中剔除是一种行为控制的尝试，因为相互不兼容的解决方法的扩散，这种行为控制将失败并产生更大的不兼容。
在配置文件中，我使用{"/* ---- my section ----*/":0} 。这是有效的JSON，因为JSON接受密钥字符串中的任何字符。它不会与其他属性发生冲突，也没有人关心或重新排序。但是，两条评论不能相同。
如果您使用一个模式来验证JSON，那么它可能会由于额外的字段而失败。
一些对象解组器(例如Jackson，在某些配置下)在未知字段上抛出异常。
如果将JSON加载为文本文件，然后从中删除注释，则可以将其与注释一起使用。
您可以使用decomment库来实现这一点。下面是一个完整的例子。
输入json(file input.js)：
1
/*
测试应用：
1
var decomment = require('decomment');
输出：
另见：咕噜咕噜的调料
如果您以定制方式扩展语言，需要特殊的预处理器来处理，那么就不再是JSON了。
@Meagar有JSON5规范，它支持注释等。但最终它从未成为标准。
我刚刚发现了"格伦特-斯特林-杰森评论"。
"Strip comments from JSON. It lets you use comments in your JSON files!"
1
{
最好在你做的时候缩小JSON。参见@kyle simpson关于json.minify的答案。
2019年，vscode用户的实际答案是使用"jsonc"扩展。
实用，因为这是vscode识别的扩展，表示"json with comments"。请在下面的评论中告诉我其他编辑/ide的情况。
如果vscode和其他编辑器也可以添加对"json5"的本机支持，那就更好了，但现在vscode只包括对"jsonc"的支持。
(我在发布之前搜索了所有答案，没有提到"jsonc"。)
在我的例子中，在JSON结构输出之前，我需要使用注释进行调试。所以我决定在HTTP头中使用调试信息，以避免破坏客户机：
1
header("My-Json-Comment: Yes, I know it's a workaround ;-)");
如果您的上下文是node.js配置，那么您可以考虑通过module.exports 使用javascript作为JSON的替代方案：
1
module.exports = {
require 语法仍然相同。作为javascript，文件扩展名应该是.js 。
我真的认为在第二页回答这个问题毫无意义，但这正是我一直在寻找的，而且工作完美无瑕！谢谢。
正如许多答案已经指出的那样，JSON本身并没有评论。当然有时候你还是想要它们。对于python，有两种方法可以做到这一点：commentjson (仅用于python的# 和// )或json_tricks (# 或// )(用于python的python(2)和python(3))，后者还具有一些其他功能。免责声明：我做了json_tricks 。
JSON本身不允许评论。这种推理是完全愚蠢的，因为您可以使用JSON本身创建注释，这完全排除了推理，并且为了完全相同的结果和潜在的问题(例如：一个带有注释的JSON文件)，毫无理由地加载解析器数据空间。
If you try to put comments in (using // or /* */ or # for instance), then some parsers will fail because this is strictly not
举个例子，我的图像处理系统保存了图像符号和与之相关的一些基本格式(注释)信息(在底部)：
1
{
如果您使用的是PHP，那么在将JSON字符串解析为对象/数组之前，可以使用此函数搜索并删除JSON字符串中的//*类型注释：
1
function json_clean_decode($json, $assoc = true, $depth = 512, $options = 0) {
希望这有帮助！
您可以通过正则表达式使用简单的预处理。例如，以下函数将在PHP中解码注释过的JSON：
1
function json_decode_commented ($data, $objectsAsArrays = false, $maxDepth = 512, $opts = 0) {
它支持所有PHP风格的注释：/*、、/。字符串文本保持原样。
*.json文件通常用作配置文件或静态数据，因此需要注释→一些编辑器(如netbeans)接受*.json中的jcomment。
问题是将内容解析为对象。解决方案是始终应用清理功能(服务器或客户端)。
PHP
1
$rgx_arr = ["/\/\/[^
JavaScript
1
valid_json_str = json_str.replace(/\/\/[^
是的，你可以发表评论。但我不推荐上述任何理由。
我做了一些调查，发现所有JSON需要的方法都使用JSON.parse 方法。所以我找到了一个解决方案：我们可以重写json.parse，或者在json.parse周围进行monkey修补。
Note: tested on Node.js only ;-)
1
var oldParse = JSON.parse;
JSON文件：
1
{
{ what_if:"I happen to have /* slashes and asterisks */ in my data?" } 可以，在浏览器上测试
我的意思是，大多数语言都不需要担心字符串中的注释序列。即使在支持注释的JSON实现中，我也希望解析我的示例时得到一个带有键"what_if" 和值"I happen to have /* slashes and asterisks */ in my data?" 的对象，而不是"I happen to have in my data" 。
使用regex可以避免数据转换到。据我所知，情况不应该是这样的。JSON被用作数据，而不是语言。所以避免在数据中使用垃圾数据或注释。：-d在大多数语言中，您编写的代码以其他格式编译。在JS中，它是动态绑定的。没有这种类型的编译发生。V8做了一些优化，但这也是推送和失败的方法。
@我同意…这似乎适用于许多情况：json.replace(/("\/\/.*"|"\/\*(?:.| regexr.com/3p39p
您可以使用json-ld和schema.org comment类型正确地编写注释：
1
{
当然，您可以评论JSON。要从javascript中读取带注释的JSON文件，您可以在分析之前删除注释(请参见下面的代码)。我相信这段代码可以改进，但是对于那些使用regexp的人来说很容易理解。
我使用注释过的JSON文件为我的合成反射系统指定神经元形状。我还使用注释过的JSON来存储正在运行的神经元系统的中间状态。发表评论很方便。别听那些告诉你他们是坏主意的人说的。
1
fetch(filename).then(function(response) {
There are other libraries that are JSON compatible, which support comments.
One notable example is the"Hashcorp Language" (HCL)". It is written by the same people who made Vagrant, packer, consul, and vault.
我在当前的项目中遇到了这个问题，因为我有相当多的JSON，需要一些注释来保持事情易于记忆。
我使用了这个简单的python函数来替换注释，并使用json.loads 将其转换为dict ：
1
import json, re
整个线程都假设添加注释是对JSON唯一需要改进的地方。如果有人不想在JSON中使用注释，因为它将用于序列化，只需省略注释即可。空白也是如此。但是为什么停在那里？为什么JSON中需要引号？它们没有添加任何有用的内容。
我能想到JSON如此死板的唯一原因是，解析是否困难。但事实并非如此，几乎任何程序员都可以在任意方向编写JSON解析器。
我希望JSON可读、高效(简短)，并且对于数据传输、配置文件和其他许多方面都很有用。通过以下示例可以满足这两个要求：
1
{stringA: stringB, stringC: stringD, [stringE, stringF]}
比任何现有的JSON规范都要短，但可读性和效率都要高。
需要在属性或值中包含引号、撇号、逗号或括号吗？只需将它们括在问号或撇号中(使用反斜杠转义)，就像在JavaScript中一样。
但请加引号。为什么？因为JSON不能包含变量或函数名(为了避免注入攻击)，所以引号不能提供任何消歧。我们已经知道所有的数据都是字符串。所以，除非确实需要引号，否则请不要使用引号。
您可能对yaml(yaml.org)感兴趣，它是JSON的准超集，允许注释，不需要引号。
是的，您可以，但您的分析可能会失败(没有标准)。
要解析它，您应该删除这些注释，或者手动删除，或者使用正则表达式：
它取代了任何评论，比如：
1
/****
它取代了任何评论，比如：
在JavaScript中，您可以这样做：
1
jsonString = jsonString.replace(/\/\*([^*]|[
您的regexp甚至可以从字符串内部删除/*hey*/ 之类的内容。
抓得好！所以只要在regex上换点东西就行了。
众所周知，结构化语言的正则表达式很难正确表达。查看@kyle simpson关于json.minify的答案，作为临时regexps的替代。
关于"(没有标准)"，最肯定的是有一个标准可以精确定义JSON是什么，而且在这个答案被写出来之前就已经有了。
