48 题: 可以在JSON中使用注释吗?

在...创建的问题 Fri, Jul 22, 2016 12:00 AM

我可以在JSON文件中使用注释吗?如果是这样,怎么样?

    
6655
  1. @ StingyJack:解释可能不明显的事情,或者其他任何可能与评论有关的事情。我经常在数据文件中有注释。 XML,ini文件和许多其他格式包括注释条款。
    2008-10-28 20:51:29Z
  2. 如果你像我一样想知道//comments是否适用于Sublime Text配置文件的特定用例,答案是肯定的(从版本2开始) 。 Sublime Text不会抱怨它,至少,它会在控制台中抱怨{"__comment": ...},因为它是一个意想不到的字段。
    2013-02-01 15:12:22Z
  3. 也许这就是创建TOML的原因之一..
    2013-05-01 05:22:12Z
  4. 稍微有点蠢,但我也尝试使用//来获取JSON中的注释。现在我意识到它严格用于交换/交换。叹!我不能再评论了:(。生命注定要死!。
    2013-09-25 11:29:39Z
  5. 2015-02-02 11:13:53Z
  6. 醇>
    30答案                              30 跨度>                         

    没有。

    JSON应该都是数据,如果你包含注释,那么它也将是数据。

    您可以使用名为"_comment"(或其他)的指定数据元素,这些元素将被使用JSON数据的应用程序忽略。

    你可能会更好地在生成/接收JSON的进程中发表评论,因为他们应该事先了解JSON数据,或者至少知道它的结构。

    但如果你决定:

     
    {
       "_comment": "comment text goes here...",
       "glossary": {
          "title": "example glossary",
          "GlossDiv": {
             "title": "S",
             "GlossList": {
                "GlossEntry": {
                   "ID": "SGML",
                   "SortAs": "SGML",
                   "GlossTerm": "Standard Generalized Markup Language",
                   "Acronym": "SGML",
                   "Abbrev": "ISO 8879:1986",
                   "GlossDef": {
                      "para": "A meta-markup language, used to create markup languages such as DocBook.",
                      "GlossSeeAlso": ["GML", "XML"]
                   },
                   "GlossSee": "markup"
                }
             }
          }
       }
    }
    
        
    4752
    2018-04-03 11:57:40Z
    1. 如果有一个名为comment的有效字段,可能需要在实际评论上加上某种前缀:"__comment":"comment text goes here...",
      2010-02-03 11:41:45Z
    2. 为什么JSON中没有注释(或更准确地说,为什么它们在早期被删除)的最新解释/理由: plus.google.com/118095276221607585885/posts/RK8qyGVaGSr 另见 tech.groups.yahoo.com/group/json/message/156 以及该主题中的其他讨论。
      2012-06-28 22:14:25Z
    3. BTW,Java的json库 google-gson 支持评论。
      2012-10-01 12:21:44Z
    4. 如果我想对AccronymAbbrev属性单独发表评论怎么样?我之前使用过这种模式但是停止了,因为它不允许我这样做。这是一个黑客。也许如果我在__comment__前面添加一个属性名称。这是“__comment__Abbrev”,仍然是一个黑客,但会让我评论所有prpoerties
      2014-08-11 12:58:25Z
    5. 你也可以使用“//”:这看起来更原生,并且在同一个父
      中仍然是可重复的
      2015-08-28 09:59:50Z
    6. 醇>

    ,JSON中不允许使用//…/*…*/表单的注释。这个答案基于:

    1692
    2016-06-03 07:20:04Z
    1. 如果你想用注释注释你的JSON(从而使它成为无效的JSON),那么在解析或传输之前将其缩小。 Crockford本人在2012年在配置文件的背景下承认了这一点。
      2014-08-07 19:26:35Z
    2. @ alkuzad:当谈到正式语法时,必须有明确表示允许 的东西,而不是相反。例如,选择您的编程语言:仅仅因为没有明确禁止某些期望(但缺失)的功能,并不意味着您的编译器会神奇地识别它。
      2015-09-28 07:01:23Z
    3. 是的。 JSON格式在元素之间有很多死区,并且在这些区域中对空间不敏感,因此没有理由不能在那里使用单行或多行注释。许多解析器和minifiers也支持JSON注释,因此请确保您的解析器支持它们。 JSON用于应用程序数据和配置设置,因此现在需要注释。 “官方规范”是一个不错的主意,但它不够充分,过时,太糟糕了。如果您担心有效负载大小或性能,请缩小您的JSON。
      2017-10-31 17:36:52Z
    4. 虽然你的答案绝对正确,但应该说这是BS。由于有如此多的最终用户需要json配置,因此评论非常有用。仅仅因为一些锡箔帽决定JSON 必须始终机器可读,忽略了人类需要阅读它的事实,这是一种小心眼的嘲弄
      2018-01-21 00:29:27Z
    5. @ cmroanirgo:你显然不是第一个抱怨JSON限制的人......这就是为什么我们有解析器默默地允许注释,以及其他格式如YAML和JSON5。然而,这并没有改变JSON就是这样的事实。更确切地说,我觉得有趣的是,人们开始使用JSON的目的在一开始就显然是不够的,考虑到这个限制。不要责怪JSON格式;责备自己坚持使用它并不是特别合适。
      2018-01-21 07:48:27Z
    6. 醇>

    如果您选择,请附上评论;在解析或传输之前用缩小器将它们剥离。

    我刚刚发布 JSON.minify() 来自JSON块的注释和空格,使其成为可以解析的有效JSON。所以,您可以像以下一样使用它:

     
    JSON.parse(JSON.minify(my_str));
    

    当我发布它时,我得到了一个强烈反对的人甚至不同意它的想法,所以我决定写一篇关于 comments有意义。它包括来自JSON创建者的这个值得注意的评论:

      

    假设您使用JSON来保留要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。 - Douglas Crockford,2012

    希望这对那些不同意为什么 JSON.minify()有用的人有帮助。

        
    745
    2017-01-20 13:40:10Z
    1. 我对JSON.minify()唯一的问题是它真的很慢。所以我自己做了同样的事情: gist.github.com/1170297 。在一些大型测试文件上,您的实现需要74秒,并且需要0.06秒。
      2011-08-25 09:16:57Z
    2. 如果您可以将建议的替代算法提交给JSON.minify()的github仓库,那就太棒了,这样它就可以移植到所有支持的langs : github.com/getify/json.minify
      2011-08-30 17:20:41Z
    3. @ MiniGod我已多次听过Doug关于这个话题的想法。我很久以前在我的博客文章中解决了这些问题: blog.getify.com/json-comments
      2013-02-26 23:21:25Z
    4. @ MarnenLaibow-Koser即使对于数据流(甚至数据包)的使用,仍然存在有效的注释用法:包含诊断元数据(如创建时间或源)通常用于XML,对JSON数据也非常敏感。针对评论的争论很浅,任何文本数据格式都应允许评论,无论暗示的用途如何(没有任何规范建议JSON不能在其他地方使用,fwiw)
      2014-03-28 22:09:27Z
    5. 如果JSON要得到普遍接受(它基本上是这样做的话),那么它应该具有通用应用程序。示例:JSON可以充当应用程序配置文件。这个应用程序需要评论。
      2016-01-27 19:31:22Z
    6. 醇>

    评论已从设计中删除。

      

    我从JSON中删除了注释,因为我看到有人使用它们来保存解析指令,这种做法会破坏互操作性。我知道缺乏评论会让一些人感到悲伤,但事实并非如此。

         

    假设您使用JSON来保留要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。

    来源: Douglas Crockford对G +的公开声明

        
    404
    2012-07-30 21:48:12Z
    1. 我认为JSON应该比XML更人性化?注释是为了便于阅读。
      2012-10-14 13:00:36Z
    2. 无论如何,你可能很顽皮并在JSON中添加解析指令:{“_ _ directives”:{“#n#”:“DateTime.Now”},“validdate “:”#n#“} ......看起来YAML就是前进之路......
      2012-10-14 13:04:37Z
    3. 个人意见:没有允许评论是蹩脚的。除了构建一个忽略注释的非标准JSON解析器,解码我的配置文件之外别无选择。
      2013-09-23 02:28:34Z
    4. @ ArturCzajka我仍然不喜欢JSON不支持评论这一事实,但我试试了INI,我必须承认在JSON上使用它们更有意义配置文件。感谢您的回复,希望更多人在阅读此对话时会改变主意。 (无论如何,使解析器更像是一种练习:)
      2013-10-04 02:42:27Z
    5. 这就像要求所有自行车都有训练轮,因为有些人不能骑自行车。删除一个重要的功能,因为愚蠢的人滥用它是一个糟糕的设计。数据格式应优先考虑可用性,而不是防止白痴。
      2015-05-14 17:24:29Z
    6. 醇>

    免责声明:您的保修无效

    正如已经指出的那样,这个hack利用了规范的实现。并非所有JSON解析器都能理解这种JSON。特别是流解析器会阻塞。

    这是一个有趣的好奇心,但你根本不应该用它来做任何事情。以下是原始答案。


    我发现了一个小小的hack,它允许你将注释放在一个不会影响解析的JSON文件中,或者改变以任何方式表示的数据。

    似乎在声明对象文字时,您可以使用相同的键指定两个值,最后一个值优先。信不信由你,事实证明JSON解析器的工作方式相同。因此,我们可以使用它在源JSON中创建注释,这些注释不会出现在已解析的对象表示中。

     
    ({a: 1, a: 2});
    // => Object {a: 2}
    Object.keys(JSON.parse('{"a": 1, "a": 2}')).length; 
    // => 1
    

    如果我们应用此技术,您评论的JSON文件可能如下所示:

     
    {
      "api_host" : "The hostname of your API server. You may also specify the port.",
      "api_host" : "hodorhodor.com",
    
      "retry_interval" : "The interval in seconds between retrying failed API calls",
      "retry_interval" : 10,
    
      "auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
      "auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",
    
      "favorite_numbers": "An array containing my all-time favorite numbers",
      "favorite_numbers": [19, 13, 53]
    }
    

    以上代码为有效的JSON 。如果你解析它,你会得到一个像这样的对象:

     
    {
        "api_host": "hodorhodor.com",
        "retry_interval": 10,
        "auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
        "favorite_numbers": [19,13,53]
    }
    

    这意味着没有评论的痕迹,并且它们不会产生奇怪的副作用。

    快乐的黑客攻击!

        
    199
    2016-01-15 05:58:51Z
    1. 来自规范 :对象中的名称应该是唯一的。
      2013-08-02 13:50:02Z
    2. “所有实现都处理相同” - 这是一个难以证明的事情。
      2013-08-02 14:20:40Z
    3. 无法保证JSON中元素的顺序。这意味着“最后”项目可能会改变!
      2013-08-02 14:33:10Z
    4. 这显然违反了规范(见上面的评论),不要这样做。 ietf.org/rfc/rfc4627.txt?number=4627
      2013-08-02 14:39:29Z
    5. - 如果解析器正在流式传输怎么办?如果解析器将其读入字典中未定义键排序,该怎么办? 用火来杀死它
      2013-08-02 14:55:22Z
    6. 醇>

    JSON不支持评论。它也从未打算用于需要注释的配置文件。

    Hjson是人类的配置文件格式。轻松的语法,更少的错误,更多的评论。

    有关JavaScript,Java,Python,PHP,Rust,Go,Ruby和C#库的信息,请参见 hjson.org

        
    153
    2016-08-09 21:20:28Z
    1. Upvoted。这显然是一个很好的变化,不开放的保守派人士会喜欢讨厌。我希望你的实现能够进一步了解 - 甚至可能比原版更受欢迎;)我希望有人也可以用Ruby实现它。 @adelphus明确定义的语言是您自己的观点或观点。作为一个保守的“开发者”如果你是一个并不能证明你更好,你可能会更糟,让自己被关在有限的空间。不要轻易将人们视为糟糕的开发者。
      2014-06-30 19:20:30Z
    2. 对不起,@ konsolebox。也许你可以在阅读 ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf 这是一个真正的标准,开发人员实施他们自己的“特殊”版本会导致碎片化,混乱和很多浪费时间。看看开发人员在编写代码时留下的混乱,因为每个浏览器都实现了略有不同的标准版本。 JSON语言可能并不完美,但碎片化程度更差。是的,这只是一个意见,你可以自由地反对意见。
      2014-07-09 16:02:47Z
    3. 我很欣赏你的观点,但你有点重新发明了YAML。如果您需要很多灵活性和人类可读性,请使用YAML(实际上不要: stackoverflow.com/questions/450399 /... )或坚持使用curmudgeony,但是明确的JSON。
      2014-08-07 18:25:56Z
    4. 我发现最用户友好的配置格式仍然是INI。它很简单,而且语法不重。这使得用户只需在配置池中浸泡脚趾就不那么令人生畏了。
      2015-02-10 15:15:18Z
    5. 每当你需要json作为配置(需要注释 )时 - 将文件命名为“.js”而不是“.json”.. js当然可以处理任何有效的json对象,另外可以处理注释..这就是为什么它是“webpack.config.js”而不是“webpack.config.json”的原因(那里有很多在webpack中也有更多原因:P)
      2016-04-06 14:20:46Z
    6. 醇>

    考虑使用YAML。它几乎是JSON的超集(几乎所有有效的JSON都是有效的YAML),它允许注释。

        
    103
    2011-08-31 02:24:26Z
    1. @ g33kz0r正确,因此我将YAML描述为JSON的近似超集。
      2012-09-12 14:58:43Z
    2. @ NateS很多人已经指出答案是否定的。我提出了一个更好的方法来实现OP的目标。这是一个答案。
      2014-03-28 12:57:24Z
    3. 缺点:yaml库不附带Python。
      2014-04-15 10:06:03Z
    4. @ BleedingFingers所以安装它......
      2014-04-15 16:19:00Z
    5. @ marnen-laibow-koser:是的,它必须无法使用Java和Perl的可用YAML库,并期望每个人生成的YAML被另一个没有错误。 YAML互操作是一个问题,但JSON互操作不是,完全可以解释为我缺乏知识。
      2014-08-17 23:32:00Z
    6. 醇>

    你做不到。至少这是我通过快速浏览 json.org 的经验。

    JSON的语法在该页面上可视化。没有关于评论的任何说明。

        
    100
    2017-01-19 17:20:33Z

    您应该编写 JSON架构。 JSON模式目前是提议的Internet草案规范。除了文档之外,架构还可用于验证您的JSON数据。

    示例:

     
    {
        "description":"A person",
        "type":"object",
        "properties":
            {
                "name":
                    {
                        "type":"string"
                    },
                "age":
                    {
                        "type":"integer",
                        "maximum":125
                    }
            }
    }
    

    您可以使用说明架构属性提供文档。

        
    65
    2017-01-19 17:37:30Z
    1. JSON架构是否存活?它存在但是它是否受到任何已知库的支持?
      2012-10-29 14:31:10Z
    2. 是的, json-schema google group 相当活跃,我建议 JSV 以获得良好的JavaScript实施一个JSON Schema验证器。
      2012-11-27 11:34:05Z
    3. 这只对结构化文档有帮助,而不是临时文档
      2013-04-04 17:47:42Z
    4. 如果你使用clojure(我确定你没有),这里有一个相当特色的开源JSON模式解析器: github.com/bigmlcom/closchema
      2013-04-15 13:50:44Z
    5. @ Munhitsu Manatee.Json(.Net)广泛支持JSON模式。
      2015-06-26 00:26:29Z
    6. 醇>

    如果您使用 Jackson 作为JSON解析器,那么您可以通过以下方式启用它以允许注释:

     
    ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
    

    然后你可以得到这样的评论:

     
    {
      key: "value" // Comment
    }
    

    您还可以通过设置:

    获得以#开头的评论  
    mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
    

    但总的来说(如前所述)规范不允许发表评论。

        
    59
    2018-10-14 17:03:12Z

    评论不是官方标准。虽然一些解析器支持C风格的注释。我使用的是 JsonCpp 。在这些例子中有一个:

     
    // Configuration options
    {
        // Default encoding for text
        "encoding" : "UTF-8",
    
        // Plug-ins loaded at start-up
        "plug-ins" : [
            "python",
            "c++",
            "ruby"
            ],
    
        // Tab indent size
        "indent" : { "length" : 3, "use_space": true }
    }
    

    jsonlint 未对此进行验证。因此,注释是特定于解析器的扩展,而不是标准扩展。

    另一个解析器是 JSON5

    JSON的替代 TOML

    另一种选择是 jsonc

        
    56
    2019-04-03 08:12:24Z
    1. Groovy有一些内置类用于处理JSON 。 JsonSlurper可以处理评论。当然,官方规范中不允许使用注释,因此任何解析器中的此行为都是非标准且不可移植的。
      2015-11-06 21:47:04Z
    2. 醇>

    以下是我在 Google Firebase文档中找到的内容允许您在JSON中添加注释:

     
    {
      "//": "Some browsers will use this to enable push notifications.",
      "//": "It is the same for all projects, this is not your project's sender ID",
      "gcm_sender_id": "1234567890"
    }
    
        
    46
    2017-06-22 13:05:19Z
    1. 仅供参考,Firebase实时数据库不允许在密钥中使用“/”。所以这对于你自己的使用来说是一个很好的约定,但你不能在Firebase中做到这一点
      2017-11-01 20:44:58Z
    2. 此方法会破坏某些库,这些库要求密钥必须是唯一的。我正在通过编写评论来解决这个问题。
      2018-01-19 11:45:24Z
    3. 好评,我在SO上发现了这个问题......这部分似乎没有被规范所涵盖 stackoverflow.com/questions/21832701 /...
      2018-01-20 19:36:40Z
    4. 我猜//1 //2 //3会起作用。
      2018-02-21 14:44:22Z
    5. 我现在倾向于使用它:{“//foo”:“foo comment”,“foo”:“foo value”,“//bar” :“bar comment”,“bar”:“bar value”}您可以使用数组进行多个注释:{“//foo”:[“foo comment 1”,“foo comment 2”],“foo”:' 'foo value“}
      2018-03-09 16:29:56Z
    6. 醇>

    如果你的文本文件是一个JSON字符串,某个程序会读取它,在使用它之前去除C或C ++样式注释有多难?

    答案:这将是一个班轮。如果这样做,那么JSON文件可以用作配置文件。

        
    38
    2015-08-29 17:51:26Z
    1. 可能是迄今为止最好的建议,但仍然是将文件保留为交换格式的问题,因为它们需要在使用前进行预处理。
      2011-02-25 11:04:33Z
    2. 我同意并编写了一个Java的JSON解析器,可以在www.SoftwareMonkey.org上找到,就是这样。
      2012-07-28 01:51:47Z
    3. 尽管我认为,扩展JSON并不是一个好主意(不要将其称为不同的交换格式):确保忽略字符串中的“注释”。 {“foo”:“/*这不是评论。* /”}
      2013-07-27 12:09:20Z
    4. “...将是一个单行”嗯,不,实际上,JSON不是常规语法,正则表达式可以简单地找到匹配的/*对。您必须解析文件以查找/*是否出现在字符串中(并忽略它),或者它是否被转义(并忽略它)等。此外,您的答案是无益的,因为您只是推测(错误地)而不是提供任何解决方案。
      2013-12-08 21:55:15Z
    5. @ kyle-simpson说的是什么。此外,他太谦虚,无法引导读者回答有关使用JSON.minify作为ad hoc regexp的替代方案的答案。那样做,不是这个。
      2014-08-07 19:32:52Z
    6. 醇>

    如果您使用带有ASP.NET的Newtonsoft.Json库来读取/反序列化,则可以使用JSON内容中的注释:

      

    //“name”:“string”

         

    //“id”:int

      

    /*这是

         

    评论示例* /

    PS:只有6个版本的Newtonsoft Json支持单行注释。

    对于那些无法开箱即用的人的补充说明:我在我制作的ASP.NET Web应用程序中使用JSON格式进行基本设置。我读取文件,使用Newtonsoft库将其转换为设置对象,并在必要时使用它。

    我更喜欢在JSON文件本身中编写关于每个单独设置的注释,并且我真的不关心JSON格式的完整性,只要我使用的库是正常的。

    我认为这比“创建单独的'settings.README'文件并解释其中的设置更容易使用/理解”。

    如果您对此类用法有疑问;对不起,精灵已经没了灯。人们会发现JSON格式的其他用法,你无能为力。

        
    34
    2017-01-19 18:21:52Z
    1. 很难理解为什么有人会陈述事实有问题。
      2014-07-29 14:17:30Z
    2. 我会假设有人因为上面不再是JSON,或者是无效的JSON而异常。也许添加一个简短的免责声明会安抚。
      2014-08-07 18:12:46Z
    3. 我完全同意你的观点,但到目前为止,还有883个赞成票只是表明明显的非答案。思想纯度高于有用的信息,这对你来说是非常的。
      2014-08-20 16:48:36Z
    4. 该点是一个注释不是JSON的文件,很多JSON库都无法解析。您可以随意在自己的程序中执行任何操作,但带有注释的文件不是JSON。如果您声称它是人们将尝试用他们选择的语言/库解析它,它将失败。这就像询问你是否可以在XML中使用方括号而不是尖括号。你可以做任何你想做的事情,但它不再是XML。
      2019-06-06 03:35:13Z
    5. 醇>

    JSON背后的想法是在应用程序之间提供简单的数据交换。这些通常是基于Web的,语言是JavaScript。

    它实际上并不允许这样的注释,但是,将注释作为数据中的一个名称/值对传递肯定会起作用,尽管这些数据显然需要被解析代码忽略或特别处理

    所有这一切,并不意味着JSON文件应该包含传统意义上的注释。它应该只是数据。

    查看 JSON网站了解更多细节。

        
    30
    2017-01-19 17:25:29Z
    1. JSON格式确实没有评论。就个人而言,我认为这是一个重大错误 - 能够将注释作为元数据(而不是数据)对xml非常有用。 JSON规范的早期草稿版本确实包含了注释,但由于某些原因它们被删除了。 : - /
      2009-09-01 18:20:50Z
    2. @ StaxMan它们被完全删除,因为人们开始将它们用作元数据。 Crockford说它破坏了格式设计的兼容性,我同意:如果你想要元数据,为什么不把它作为实际数据包括在内?用这种方式解析会更容易。
      2010-12-11 09:03:56Z
    3. 元数据属于元数据构造(例如HTML< meta>标记),而不是注释。滥用元数据注释只是在没有真正的元数据构造存在的情况下使用的。
      2011-09-06 04:55:58Z
    4. 这正是它被删除的原因:用作元数据的注释会破坏互操作性。您应该只将您的元数据存储为JSON。
      2013-06-25 14:50:28Z
    5. 这个答案是多余的,更好的书面,更高的赞成答案,基本上是相同的,即使这可能是早先写的。 Cest la vie。
      2014-08-07 19:35:06Z
    6. 醇>

    我刚刚遇到配置文件。我不想使用 XML (详细,图形,丑陋,难以阅读)或“ini”格式(没有层次结构,没有真正的标准等)或Java“属性”格式(像.ini)。

    JSON可以做他们能做的所有事情,但它更简洁,更易于阅读 - 解析器在许多语言中都很容易和普遍存在。它只是一个数据树。但是,带外注释通常是记录“默认”配置等的必要条件。配置永远不是“完整文档”,而是保存数据的树,在需要时可以是人类可读的。

    我想可以使用"#": "comment",用于“有效”的JSON。

        
    29
    2017-01-19 17:42:10Z
    1. 对于配置文件,我建议使用YAML,而不是JSON。它(几乎)是一个更强大的JSON超集,但也支持更多可读的结构,包括注释。
      2011-10-19 21:35:37Z
    2. 与json相比,您认为支持YAML的语言有多少?
      2012-01-13 13:26:38Z
    3. @ Hamidam十几种语言支持yaml: yaml.org - 但是您可以询问有多少内置支持,而不需要第三方库依赖。看起来像Ruby 1.9.2。有人知道别人吗?哪些语言默认支持json?
      2012-03-21 15:53:56Z
    4. YAML interop是谎言: stackoverflow.com/questions/450399 /... 。如果你的直觉是使用JSON配置文件,请遵循它。
      2014-08-07 19:10:08Z
    5. 这是旧的,但我相信你唱#不是个好主意。 Json接近于Javascript litteral的语法。 Javascript支持两种类型的注释://和/* ... * /如果我是你,我会坚持使用这些类型的注释中的一种或两种。
      2015-12-02 18:24:38Z
    6. 醇>

    JSON本身不支持注释,但您可以创建自己的解码器或至少预处理器来删除注释,这非常好(只要您忽略注释并且不使用它们来指导应用程序应该如何处理JSON数据)。

      

    JSON没有评论。 JSON编码器绝不能输出注释。   JSON解码器可以接受并忽略注释。

         

    永远不应该使用注释来传输任何有意义的内容。那是   JSON的用途是什么。

    Cf:道格拉斯克罗克福德,JSON规范的作者

        
    28
    2013-06-25 14:48:56Z
    1. Crockford后来写道:“假设你使用JSON来保存配置文件,你想要注释。继续插入你喜欢的所有注释。然后通过JSMin将其传递给你的JSON解析器。“有关详细信息,请参阅@ kyle-simpson关于JSON.minify的答案。
      2014-08-07 19:14:21Z
    2. 醇>

    这取决于您的JSON库。 Json.NET 支持JavaScript风格的评论,/* commment */

    请参阅其他Stack Overflow问题

        
    28
    2017-05-23 10:31:37Z
    1. 我相信这就是我在这个ASP.NET vNext预览页面(在package.json下)的屏幕截图中看到评论的原因: blogs.msdn.com /b /webdev /archive /2014/06/03 /... 虽然我还没有在规范中找到任何内容。
      2014-09-17 21:54:01Z
    2. 醇>

    JSON对配置文件和其他本地用法很有意义,因为它无处不在,因为它比XML简单得多。

    如果人们有充分理由反对在传递数据时使用JSON进行评论(无论是否有效),那么JSON可能会被分成两部分:

    • JSON-COM:有线的JSON,或者在传递JSON数据时适用的规则。
    • JSON-DOC:JSON文档,或文件或本地JSON。定义有效JSON文档的规则。

    JSON-DOC将允许注释,并且可能存在其他微小差异,例如处理空白。解析器可以轻松地从一个规范转换为另一个规范。

    关于Douglas Crockford就此问题制作的评论(由@Artur Czajka引用)

      

    假设您使用JSON来保留要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。

    我们正在讨论通用配置文件问题(跨语言/平台),他正在回答JS特定的实用程序!

    确定JSON特定的缩小可以用任何语言实现, 但是标准化这使它在所有语言和平台的解析器中变得无处不在,所以人们不再浪费他们的时间缺乏这个功能,因为他们有很好的用例,在网上论坛上查找问题,让人们告诉他们这是一个坏主意或暗示我很容易实现从文本文件中删除注释。

    另一个问题是互操作性。假设您有一个库或API或任何类型的子系统,其中包含一些与之关联的配置或数据文件。而这个子系统是 可以从不同的语言访问。然后你去告诉别人:顺便说一句 不要忘记在将JSON文件中的注释传递给解析器之前将其删除!

        
    25
    2013-01-25 14:45:56Z
    1. 无需分段JSON。带注释的JSON不再是JSON。但是,只要你确保在解析或传输它之前将它们删除,那么用注释注释你的JSON是完全可以接受的。这样做不应该是接收者的责任。
      2014-08-07 19:19:52Z
    2. 醇>

    Dojo Toolkit JavaScript工具包(至少从版本1.4开始)允许您在JSON中包含注释。评论可以是/* */格式。 Dojo Toolkit通过dojo.xhrGet()调用消耗JSON。

    其他JavaScript工具包的工作方式可能类似。

    在选择最终选项之前尝试使用备用数据结构(甚至数据列表)时,这会很有用。

        
    22
    2017-01-19 17:39:46Z
    1. 没有。不是这个。 JSON没有评论。如果您选择使用注释注释JSON,请在解析或传输之前将其缩小。这不应该是接收者的责任。
      2014-08-07 19:31:33Z
    2. 我没有说JSON有评论。我也不是要暗示将它们包含在您的JSON中是合适的,特别是在生产系统中。我说 Dojo工具包允许你添加它们,这是(或至少是)事实上是真的。在测试阶段有非常有用的用例。
      2014-08-07 23:37:25Z
    3. 服务于评论,这是无效的巫术,因此无效的JSON,dojo.xhrGet()通过接受隐含地鼓励。
      2014-08-08 20:21:31Z
    4. 我仍然投票支持升级JSON规范以允许评论。我在传输JSON之前全部用于缩小和删除注释,但是没有任何能力以任何标准方式注释你的JSON,而不必在解析它之前通过单独的实用程序,这看起来很愚蠢。我还无法在JSON配置文件上使用JSON编辑器,因为您的文件不是有效的JSON。
      2014-09-15 07:03:06Z
    5. 醇>

    如果您使用 JSON5 ,则可以添加评论。


    JSON5是JSON 的建议扩展,旨在让人们更容易手动编写和维护。它通过直接从ECMAScript 5添加一些最小语法功能来实现这一点。

        
    22
    2017-01-19 18:32:25Z
    1. 你能加一个例子吗?然后你可能真的需要那些额外的角色。
      2015-12-17 00:15:10Z
    2. SO指南要求提供实际答案。不需要仅链接答案。您可以查看指南 stackoverflow.com/help/how-to-回答
      2015-12-29 20:06:55Z
    3. SO由其用户主持。这意味着我可以提供一个答案,如果我这样做,我可以评论你的答案,如果它不遵循指导方针。这就是SO如何成为一个很好的资源。
      2015-12-30 11:21:54Z
    4. 醇>

    JSON不是框架协议。它是一种语言免费格式。因此,没有为JSON定义注释的格式。

    正如许多人所建议的,有一些技巧,例如,重复的密钥或您可以使用的特定密钥_comment。这取决于你。

        
    19
    2017-01-19 18:24:14Z

    可以 JSONP 中发表评论,但不是纯粹的JSON。我花了一个小时试图让我的程序在Highcharts中使用这个例子: http://www.highcharts.com/samples/data/jsonp.php?filename=aapl-c.json&callback=?

    如果您点击该链接,您会看到

     
    ?(/* AAPL historical OHLC data from the Google Finance API */
    [
    /* May 2006 */
    [1147651200000,67.79],
    [1147737600000,64.98],
    ...
    [1368057600000,456.77],
    [1368144000000,452.97]
    ]);
    

    由于我的本地文件夹中有类似的文件,因此同源文件没有问题策略,所以我决定使用纯JSON ......当然,$.getJSON由于评论而无声地失败。

    最后我只是向上面的地址发送了一个手动HTTP请求,并意识到内容类型是text/javascript,因为JSONP返回纯JavaScript。在这种情况下,允许评论 。但我的应用程序返回内容类型application/json,所以我不得不删除注释。

        
    18
    2017-01-19 18:00:16Z

    JSON用于支持评论,但它们被滥用并从标准中删除。

    来自JSON的创建者:

      

    我从JSON中删除了注释,因为我看到有人使用它们来保存解析指令,这种做法会破坏互操作性。我知道缺乏评论会让一些人感到悲伤,但事实并非如此。 - Douglas Crockford,2012

    官方JSON网站位于 JSON.org 。 JSON被ECMA International定义为标准。总是有一个请愿程序来修改标准。由于多种原因,注释不太可能添加到JSON标准中。

    JSON by design是一种易于反向设计(人工解析)的XML替代方案。甚至简化到注释是不必要的。它甚至不是标记语言。目标是稳定性和互操作性。

    任何了解面向对象“has-a”关系的人都可以理解任何JSON结构 - 这就是重点。它只是一个带有节点标签(键/值对)的有向无环图(DAG),它是一种近乎通用的数据结构。

    这个唯一的注释可能是“//这些是DAG标签”。键名可以根据需要提供信息,允许任意语义。

    任何平台都可以用几行代码解析JSON。 XML需要复杂的OO库,这些库在许多平台上都不可行。

    注释只会使JSON的互操作性降低。除非您真正需要的是标记语言(XML),否则无需添加任何其他内容,并且不关心是否可以轻松解析持久化数据。

        
    18
    2019-06-03 02:05:03Z
    1. 恕我直言,JSON中对注释的需求来自于这种格式被滥用于配置文件的事实。我们需要在配置中有注释,因此使用JSON(由标准定义)进行配置是非常糟糕的做法。一些解析器允许行注释,但文件不是严格的JSON格式,不应该被称为JSON。
      2018-09-04 07:28:31Z
    2. 正如Crockford所说:“缺乏评论会让一些人感到悲伤”。杰克逊似乎存在于JSON和XML之间的邪恶DMZ中。
      2018-09-15 22:09:56Z
    3. 我贬低了因为“它被简化甚至到注释是不必要的”这样的短语和“根本就没有其他东西可以添加”是对所有有效理由不屑一顾我和其他人受到JSON缺乏评论的阻碍。
      2019-04-23 17:22:06Z
    4. 你引用了Crockford“我从JSON中删除了注释,因为我看到人们使用它们来保存解析指令,这种做法会破坏互操作性。”你或其他任何人都明白这意味着什么?对于只是忽略注释的解析器,注释如何保存解析指令?
      2019-04-23 17:26:28Z
    5. 你明白互操作性是什么意思吗?解析器是特定于平台的,如果JSON标准允许,可以设计为解析(滥用)注释作为平台特定指令,现在它为了互操作性。这保证了JSON将在所有平台上以相同的方式(可互操作)进行解析。如果你需要注释和跨平台的噩梦,也许看看XML。
      2019-06-25 14:29:27Z
    6. 醇>

    这是“你可以”的问题。这是一个“是”答案。

    不,您不应该使用重复的对象成员将侧信道数据填充到JSON编码中。 (请参阅“对象中的名称应该是唯一的”在RFC 中)。

    是的,您可以在 JSON 周围插入评论可以解析出来。

    但是如果你想要一种插入和提取任意侧通道数据到有效JSON的方法,这里是一个答案。我们利用JSON编码中的非唯一数据表示。在RFC的第二部分中允许 * ,在“六个结构字符中的任何一个之前或之后允许空白”。

    * RFC仅声明“在六个结构字符中的任何一个之前或之后允许空格”,未明确提及字符串,数字,“false”,“true”和“空值”。在所有实现中都忽略了这个省略。


    首先,通过缩小JSON来规范化您的JSON:

     
    $jsonMin = json_encode(json_decode($json));
    

    然后用二进制编码你的评论:

     
    $hex = unpack('H*', $comment);
    $commentBinary = base_convert($hex[1], 16, 2);
    

    然后steg你的二进制文件:

     
    $steg = str_replace('0', ' ', $commentBinary);
    $steg = str_replace('1', "\t", $steg);
    

    这是你的输出:

     
    $jsonWithComment = $steg . $jsonMin;
    
        
    17
    2015-12-15 05:53:41Z
    1. RFC仅声明“在六个结构字符中的任何一个之前或之后允许空格”,未明确提及字符串,数字,“false”,“true”,“空值”。在所有实现中都忽略了这个省略。
      2014-09-24 18:15:00Z
    2. 为了获得更高的评论密度,你不能用三元编码你的评论并使用空格,制表符和换行符来抄袭吗?
      2018-09-26 19:44:28Z
    3. 醇>

    我们正在为我们的项目使用 strip-json-comments 。它支持以下内容:

     
    /*
     * Description 
    */
    {
        // rainbows
        "unicorn": /* ❤ */ "cake"
    }
    

    只需npm install --save strip-json-comments即可安装和使用它:

     
    var strip_json_comments = require('strip-json-comments')
    var json = '{/*rainbows*/"unicorn":"cake"}';
    JSON.parse(strip_json_comments(json));
    //=> {unicorn: 'cake'}
    
        
    12
    2014-11-27 11:39:27Z

    要将JSON项目剪切成部分,我添加“虚拟注释”行:

     
    {
    
    "#############################" : "Part1",
    
    "data1"             : "value1",
    "data2"             : "value2",
    
    "#############################" : "Part2",
    
    "data4"             : "value3",
    "data3"             : "value4"
    
    }
    
        
    12
    2017-01-19 18:01:59Z
    1. 您已经在JSON中模拟了一个INI文件结构。请放下你的金锤。
      2013-11-18 16:53:10Z
    2. RFC说“对象中的名称应该是唯一的”。另请参阅解析JSON错误的人,如上所述: stackoverflow.com/questions/4912386/...
      2014-06-10 15:58:29Z
    3. 如果您使用模式验证JSON,它可能会因额外的字段而失败。
      2015-06-26 00:32:11Z
    4. 如果您真的决定在JSON中添加注释,那么执行以下操作会更有意义:{ "comment-001":"This is where you do abc...", "comment-002":"This is where you do xyz..." }这使名称保持唯一并允许您添加你喜欢什么字符串值。它仍然是一个kludge,因为评论不应该是你的JSON的一部分。作为另一种选择,为什么不在JSON之前或之后添加注释,而不是在其中添加注释?
      2015-09-04 22:51:17Z
    5. 醇>

    有一个很好的解决方案(hack),它是有效的JSON。 只需两次(或更多)相同的密钥。例如:

     
    {
      "param" : "This is the comment place",
      "param" : "This is value place",
    }
    

    所以JSON会理解为:

     
    {
      "param" : "This is value place",
    }
    
        
    11
    2017-10-24 09:25:48Z
    1. 如果任何人循环遍历该对象,此方法可能会导致一些麻烦。在第一次迭代中,程序将没有该条目是注释的信息。
      2014-02-12 20:24:25Z
    2. RFC说:“对象中的名称应该是唯一的”。请参阅以下报告的错误: stackoverflow.com/questions/4912386 /...
      2014-06-10 15:59:14Z
    3. 这是一个创建JSON的邀请,可以在将来的某个随机点炸毁你。
      2014-08-07 19:00:07Z
    4. 无法保证订单在对象名称/值对列表中很重要。
      解析器可以“乱序”解析它们,然后它就会被破坏。
    2015-05-26 22:26:08Z
  7. 具有此类代码的JSON解析器的行为未定义。没有什么可说的,解析器的行为就好像只有最后一个值存在一样。它可能表现得好像只存在第一个值,或任何值,或者好像该值是一个数组。
    2017-10-06 18:24:09Z
  8. 醇>

JSON的作者希望我们在JSON中包含注释,但在解析之前将其删除(请参阅链接。如果JSON应该有注释,为什么不标准化它们,让JSON解析器完成这项工作呢?我不同意那里的逻辑,但是,唉,这是标准。使用其他人建议的YAML解决方案很好,但它需要库依赖。

如果你想删除注释,但又不想拥有库依赖,那么这是一个两行解决方案,适用于C ++风格的注释,但可以适应其他人:

 
var comments = new RegExp("//.*", 'mg');
data = JSON.parse(fs.readFileSync(sample_file, 'utf8').replace(comments, ''));

请注意,此解决方案只能用于您可以确定JSON数据不包含注释启动器的情况,例如: ('//').

实现JSON解析,删除注释以及没有额外库的另一种方法是在JavaScript解释器中评估JSON。当然,使用这种方法的警告是,您只想评估无污染的数据(没有不受信任的用户输入)。这是Node.js中这种方法的一个例子 - 另一个警告,下面的例子只会读取一次数据,然后它将被缓存:

 
data = require(fs.realpathSync(doctree_fp));
    
10
2018-10-14 17:01:11Z
  1. 这不起作用,因为它不考虑/*是否可以转义,或者可以在字符串文字内。 JSON不是常规语法,因此正则表达式是不够的。你必须解析它以找出评论的位置。
    2013-12-08 21:58:52Z
  2. 它可以在有限的情况下工作,您可以确定您的JSON不包含任何带有注释字符串的数据。谢谢你指出这个限制。我已经编辑了帖子。
    2013-12-11 23:52:24Z
  3. + 1为链接!实际上我认为不支持评论是一件好事,因为在客户端和服务器之间发送数据时,评论肯定是无用的,并且无需任何带宽。这就像有人要求在MP3结构或JPEG数据块中发表评论......
    2014-06-26 08:45:04Z
  4. 感谢+1!您必须记住,JSON不仅仅用于服务器/客户端通信。此外,根据您的数据大小和数据包大小,发送注释可能根本不会增加您的带宽,并且您的客户端可以访问额外的上下文,并且您可以始终让服务器剥离注释,如果您不想通过网络发送它们。
    2014-06-27 03:13:55Z
  5. @ AlexisWilke在某些方面,并不是所有看起来有点像英雄的长度只是为了能够在你的JSON文件中发表评论?就我而言,我只需要一些代码(不是一个完整的C /C ++编译器,运行包含在一个额外的运行时库中,如果在Cygwin /Ming下运行),在我可以通过我的配置文件之前删除注释JSON解析器。我还检测配置文件何时更改并动态重新加载它们等等。我不能简单地将注释放在文件中而不用担心它有多蹩脚?这是超级跛脚。那是多少。 ; - )
    2014-09-16 23:45:00Z
  6. 醇>

叹息。为什么不直接添加字段,例如

 
{
    "note1" : "This demonstrates the provision of annotations within a JSON file",
    "field1" : 12,
    "field2" : "some text",

    "note2" : "Add more annotations as necessary"
}

请确保您的“notex”名称与任何真实字段不冲突。

    
9
2013-11-28 13:48:59Z
  1. Just make sure your "notex" names don't conflict with any real fields.就是问题所在。这不是一个任意的解决方案。
    2014-05-14 14:42:45Z
  2. 这也提出了这样一个问题:在传输之前,缩小实用程序无法删除注释,这不可避免地导致更大的数据传输在另一个上没有用处传输结束。我真的觉得从JSON规范中获取评论支持是不幸的。特别是因为人们会一起破解解决方案。从规范中获取支持是一种行为控制的尝试,由于相互不兼容的变通办法的扩散,这种行为控制只会失败并产生更大的不兼容性。
    2014-09-15 07:07:52Z
  3. 在配置文件中,我使用的是{"/* ---- my section ----*/":0}。这是有效的JSON,因为JSON接受密钥字符串中的任何字符。它不会与其他属性发生碰撞,也没有人关心或重新排序。不过,2条评论不能相同。
    2015-04-08 03:46:52Z
  4. 如果您使用模式验证JSON,它可能会因额外的字段而失败。
    2015-06-26 00:30:20Z
  5. 某些对象unmarshallers(例如Jackson,在某些配置下)会在未知字段上抛出异常。
    2016-10-20 09:28:01Z
  6. 醇>
来源放置 这里