我能否在以下发言中发表一些意见?Json Json (Json Json) (Json Json Json) (Json Json) Json Json (Json Json) Json (Json) Json (Json) Json (Json) Json (Json) Json (Json) Json (Json) Json(Json) Json (Json) Json (Json) Json(Json) Json (Json) Json如果有,如何处理?
当前回答
你不行,至少这就是我的经验json.org.
JSON的语法在那一页上被视觉化了, 没有任何关于评论的注释。
其他回答
你应该写一个杰森计划JSON Schema是目前提议的因特网规格草案,除了文件以外,还可以使用这一规格来验证你的JSON数据。
示例:
{
"description": "A person",
"type": "object",
"properties": {
"name": {
"type": "string"
},
"age": {
"type": "integer",
"maximum": 125
}
}
}
您可以使用以下工具提供文档:描述说明说明说明说明说明说明schema 属性 。
JSON对于配置文件和其他本地使用非常有意义, 因为它无处不在, 而且因为它比XML简单得多。
如果人们有强烈理由反对在JSON上发表评论(无论是否有效),那么JSON可能会被分成两个:
- JSON在线上,或者在传送JSON数据时适用的规则。
- JSON文件,或档案或本地的JSON文件,界定有效的JSON文件的规则。
JSON-DOC 将允许评论,而其他微小差异可能也存在,比如处理白色空间。 采集器可以很容易地从一个孔转换成另一个孔。
关于下列事项:评论评论评论评论评论评论由Douglas Crockford就该问题撰写的文章(由@Artur Czajka引用)
假设您正在使用 JSON 保存配置文件, 您想要对此进行注释 。 请继续插入您想要的所有评论 。 然后通过 JSMIN 管道将其传送给您的 JSON 分析员 。
我们谈论的是通用配置文件问题(跨语言/平台), 他用联署材料特定工具回答!
可以用任何语言执行JSON的具体简洁, 但将其标准化, 使得它变得无所不在, 在所有语言和平台的旁听者之间无处不在, 所以人们不再浪费时间 缺乏功能,因为他们有良好的使用案例, 在网上论坛研究这个问题, 让人们告诉他们这是一个坏主意, 或者说很容易执行 从文本文档中删除评论。
另一个问题是互操作性。 假设你有一个图书馆或 API 或任何子系统, 与它相关联的配置或数据文件。 这个子系统将用不同语言访问 。 那么您是否要告诉人们: 顺便说一句, 请不要忘记在将 JSON 文档的评语转至解析器之前先删除 JSON 文档中的评论 !
写作时缩略语.json支持意见。
例如(样本样本样本瑞微软)
{
"Logging": {
"LogLevel": { // All providers, LogLevel applies to all the enabled providers.
"Default": "Error", // Default logging, Error and higher.
"Microsoft": "Warning" // All Microsoft* categories, Warning and higher.
},
"Debug": { // Debug provider.
"LogLevel": {
"Default": "Information", // Overrides preceding LogLevel:Default setting.
"Microsoft.Hosting": "Trace" // Debug:Microsoft.Hosting category.
}
},
"EventSource": { // EventSource provider
"LogLevel": {
"Default": "Warning" // All categories of EventSource provider.
}
}
}
}
免责声明:这太愚蠢了
事实上,有一种方法可以添加评论,并且不超出规格(不需要额外的分析师 ) 。 它不会在不作任何区分的情况下产生人类可读的评论。
您可滥用下列手段:
任何标志之前或之后都允许不显眼的白色空间。 白色空间是下列一个或多个代码点的任何序列: 字符制表( U+0009)、 线性种子( U+000A)、 运输返回( U+000D) 和空间( U+0020)。
黑客方式, 您可以滥用此选项添加注释 。 例如 : 开始并用标签结束您的评论 。 在 base 3 中编码该注释, 并使用其他空白字符来代表它们 。 例如 。
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hello base three在ASCII)中,但使用空间不是0,而是用于1条线路饲料和2条运输回程。
这将留给您许多无法读取的空白( 除非您用 IDE 插件来编码/ 解码在苍蝇上) 。
我从来没有尝试过这个, 原因很明显,你也不应该。
虽然有些分析者支持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 (jsonlint)无法验证这一点。 因此, 批注是解析器特定的扩展名, 而不是标准扩展名 。
另一个解析器是杰森5.
JSON 替代 JSON 的替代方案汤加.
另一种替代办法是:jjsonc 喷气管.
最新版本的最新版本nlohmann/json(日元)可选择支持忽略对解析的评论 。
