我可以在JSON文件中使用注释吗?如果是这样,怎么样?
没有。
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"
}
}
}
}
}
如果您使用Jackson作为JSON解析器,那么这就是您启用它以允许注释的方式:
ObjectMapper mapper = new ObjectMapper().configure(Feature.ALLOW_COMMENTS, true);
然后你可以有这样的评论:
{
key: "value" // Comment
}
您还可以通过以下方式获得以#
开头的评论:
mapper.configure(Feature.ALLOW_YAML_COMMENTS, true);
但总的来说(如前所述)规范不允许发表评论。
评论不是官方标准。虽然一些解析器支持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。
以下是我在Google Firebase documentation中发现的允许您在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"
}
如果您的文本文件(即JSON字符串)将被某些程序读取,那么在使用之前删除C或C ++样式注释有多难?
答:这将是一个班轮。如果您这样做,那么JSON文件可以用作配置文件。
如果您使用带有ASP.NET的Newtonsoft.Json库来读取/反序列化,则可以使用JSON内容中的注释:
//“name”:“string”
//“id”:int
要么
/* 这是一个
评论示例* /
PS:只有6个以上版本的Newtonsoft Json支持单行注释。
对于那些无法想到开箱即用的人的补充说明:我在我制作的ASP.NET Web应用程序中使用JSON格式进行基本设置。我读取文件,使用Newtonsoft库将其转换为设置对象,并在必要时使用它。
我更喜欢在JSON文件本身中编写关于每个单独设置的注释,并且我真的不关心JSON格式的完整性,只要我使用的库可以正常使用它。
我认为这是一种“更易于使用/理解”的方式,而不是创建单独的“settings.README”文件并解释其中的设置。
如果您对此类用法有疑问;对不起,精灵已经没了灯。人们会发现JSON格式的其他用法,你无能为力。
JSON背后的想法是在应用程序之间提供简单的数据交换。这些通常是基于Web的,语言是JavaScript。
它实际上并不允许这样的注释,但是,将注释作为数据中的一个名称/值对传递肯定会起作用,尽管这些数据显然需要被解析代码忽略或专门处理。
总而言之,JSON文件不应该包含传统意义上的注释。它应该只是数据。
有关更多细节,请查看JSON website。
我刚刚遇到配置文件。我不想使用XML(冗长,图形,丑陋,难以阅读)或“ini”格式(没有层次结构,没有真正的标准等)或Java“属性”格式(如.ini)。
JSON可以做他们能做的所有事情,但它更简洁,更人性化 - 解析器在许多语言中都很容易和无处不在。它只是一个数据树。但是,带外注释通常是记录“默认”配置等的必要条件。配置永远不会是“完整文档”,而是保存数据的树,在需要时可以是人类可读的。
我想可以使用"#": "comment"
,用于“有效”的JSON。
JSON本身不支持注释,但您可以创建自己的解码器或至少预处理器来删除注释,这非常好(只要您忽略注释并且不使用它们来指导应用程序应如何处理JSON数据)。
JSON没有评论。 JSON编码器绝不能输出注释。 JSON解码器可以接受和忽略注释。
绝不应该使用注释来传输任何有意义的内容。这就是JSON的用途。
这取决于您的JSON库。 Json.NET支持JavaScript风格的评论,/* commment */
。
JSON对配置文件和其他本地用法很有意义,因为它无处不在,因为它比XML简单得多。
如果人们有充分的理由反对在传递数据时使用JSON进行评论(无论是否有效),那么可能JSON可以分为两部分:
JSON-DOC将允许注释,并且可能存在其他微小差异,例如处理空白。解析器可以轻松地从一个规范转换为另一个规范。
关于Douglas Crockford在这个问题上制作的remark(由@Artur Czajka引用)
假设您使用JSON来保留您想要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。
我们正在讨论通用配置文件问题(跨语言/平台),他正在回答JS特定的实用程序!
当然,JSON特定的minify可以用任何语言实现,但是标准化,因此它在所有语言和平台的解析器中变得无处不在,所以人们不再浪费他们的时间缺乏这个功能,因为他们有很好的用例,看看问题在在线论坛,并让人们告诉他们这是一个坏主意或建议很容易实现从文本文件剥离评论。
另一个问题是互操作性。假设您有一个库或API或任何类型的子系统,其中包含一些与之关联的配置或数据文件。这个子系统可以从不同的语言访问。然后你去告诉别人:顺便说一下,在将它们传递给解析器之前不要忘记从JSON文件中删除注释!
不,JSON中不允许使用//…
或/*…*/
形式的注释。这个答案基于:
application/json
媒体类型Dojo Toolkit JavaScript工具包(至少从版本1.4开始)允许您在JSON中包含注释。评论可以是/* */
格式。 Dojo Toolkit通过dojo.xhrGet()
调用消耗JSON。
其他JavaScript工具包可能类似地工作。
在选择最终选项之前尝试使用备用数据结构(甚至数据列表)时,这会很有用。
JSON不是框架协议。它是一种无语言格式。因此,没有为JSON定义注释的格式。
正如许多人所建议的,有一些技巧,例如,重复键或您可以使用的特定键_comment
。由你决定。
您可以在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]
]);
由于我在本地文件夹中有一个类似的文件,Same-origin policy没有问题,所以我决定使用纯JSON ......当然,由于评论,$.getJSON
无声地失败了。
最后我只是向上面的地址发送了一个手动HTTP请求,并意识到内容类型是text/javascript
,因为JSONP返回纯JavaScript。在这种情况下,允许评论。但我的应用程序返回内容类型application/json
,所以我不得不删除评论。
JSON用于支持评论,但它们被滥用并从标准中删除。
来自JSON的创建者:
我从JSON中删除了注释,因为我看到有人使用它们来保存解析指令,这种做法会破坏互操作性。我知道缺乏评论会让一些人感到悲伤,但事实并非如此。 - Douglas Crockford, 2012
官方JSON网站位于JSON.org。 JSON被ECMA International定义为standard。总是有一个请愿程序来修改标准。由于多种原因,注释不太可能添加到JSON标准中。
JSON设计是一种易于反向设计(人工解析)的XML替代方案。甚至简化到注释是不必要的。它甚至不是标记语言。目标是稳定性和互操作性。
任何了解面向对象“has-a”关系的人都可以理解任何JSON结构 - 这就是重点。它只是一个带有节点标签(键/值对)的有向无环图(DAG),它是一种近乎通用的数据结构。
这个唯一的注释可能是“//这些是DAG标签”。键名可以根据需要提供信息,允许任意语义。
任何平台都可以用几行代码解析JSON。 XML需要复杂的OO库,这些库在许多平台上都不可行。
注释只会使JSON的互操作性降低。除非您真正需要的是标记语言(XML),否则无需添加任何其他内容,并且不关心是否可以轻松解析持久化数据。
这是一个“你可以”的问题。这是一个“是”的答案。
不,您不应该使用重复的对象成员将侧信道数据填充到JSON编码中。 (参见“对象中的名称应该是唯一的”in the RFC)。
是的,你可以insert comments around the JSON,你可以解析。
但是如果你想要一种插入和提取任意侧通道数据到有效JSON的方法,这里是一个答案。我们利用JSON编码中的非唯一数据表示。在RFC的第二部分中允许*允许在“六个结构字符中的任何一个之前或之后允许空格”。
* RFC仅声明“在六个结构字符中的任何一个之前或之后允许空白”,未明确提及字符串,数字,“false”,“true”和“null”。在所有实现中都忽略了这种省略。
首先,通过缩小它来规范化您的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;
我们正在使用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'}
要将JSON项目切割成部分,我添加“虚拟注释”行:
{
"#############################" : "Part1",
"data1" : "value1",
"data2" : "value2",
"#############################" : "Part2",
"data4" : "value3",
"data3" : "value4"
}
有一个很好的解决方案(hack),它是有效的JSON。只需两次(或更多)相同的密钥。例如:
{
"param" : "This is the comment place",
"param" : "This is value place",
}
所以JSON会将其理解为:
{
"param" : "This is value place",
}
JSON的作者希望我们在JSON中包含注释,但在解析它们之前将它们删除(参见Michael Burr提供的link)。如果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));
如果您愿意,请附上评论;在解析或传输之前用缩小器将它们剥离。
我刚刚发布了JSON.minify(),它从JSON块中删除了注释和空格,并使其成为可以解析的有效JSON。所以,您可以使用它:
JSON.parse(JSON.minify(my_str));
当我发布它时,我得到了一个强烈反对的人甚至不同意它的想法,所以我决定写一篇关于为什么comments make sense in JSON的综合博客文章。它包括来自JSON创建者的这个值得注意的评论:
假设您使用JSON来保留您想要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。 - Douglas Crockford, 2012
希望这对那些不同意JSON.minify()可能有用的人有帮助。
叹。为什么不直接添加字段,例如
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
只需确保您的“notex”名称与任何真实字段不冲突。
评论已从JSON中删除。
我从JSON中删除了注释,因为我看到有人使用它们来保存解析指令,这种做法会破坏互操作性。我知道缺乏评论会让一些人感到悲伤,但事实并非如此。
假设您使用JSON来保留您想要注释的配置文件。继续,插入您喜欢的所有评论。然后通过JSMin将其传递给JSON解析器。
免责声明:您的保修无效
正如已经指出的那样,这个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]
}
上面的代码是valid JSON。如果你解析它,你会得到一个像这样的对象:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": [19,13,53]
}
这意味着没有评论的痕迹,他们也不会有奇怪的副作用。
快乐的黑客!
JSON不支持评论。它也从未打算用于需要注释的配置文件。
Hjson是人类的配置文件格式。轻松的语法,更少的错误,更多的评论。
有关JavaScript,Java,Python,PHP,Rust,Go,Ruby和C#库的信息,请参阅hjson.org。
考虑使用YAML。它几乎是JSON的超集(几乎所有有效的JSON都是有效的YAML)并且它允许注释。
你不能。至少这是我从json.org快速浏览一下的经历。
JSON的语法在该页面上可视化。关于评论没有任何说明。
你应该写一个JSON schema。 JSON模式目前是提议的Internet草案规范。除了文档之外,模式还可用于验证JSON数据。
例:
{
"description":"A person",
"type":"object",
"properties":
{
"name":
{
"type":"string"
},
"age":
{
"type":"integer",
"maximum":125
}
}
}
您可以使用description schema属性提供文档。