开发者工具 · JSON 格式化程序和验证程序
JSON 的标准历史：RFC 4627 到 RFC 8259 和 ECMA-404
· 背景
json 标准 验证
JSON 已被两个标准机构指定至少四次。这篇文章追踪了从 Douglas Crockford 的 json.org 到 RFC 8259 和 ECMA-404 的路径，并解释了开发人员在此过程中实际发生的变化。
我的解析器遵循哪个规范？
解析器遵循哪个规范？答案通常在边缘可见，而不是在普通对象和数组中。测试顶级字符串，例如 `"ready"`、前导字节顺序标记、重复的成员名称和异常大的数字。不同的文档在不同级别讨论语法和互操作性，而实现则添加自己的数据类型和错误行为。仅当观察到的解析器契约与每个 JSON 实现的假设分开时，命名标准才有用。
ToolAcre 的存储库证据比一般标准历史更具体且更狭窄。格式化程序使用 `JSON.parse` 生成值并使用 `JSON.stringify` 发出它们；解析失败后，本地扫描仪会提供稳定的诊断位置和原因。
json.org 和 JSON 的早期描述
json.org 将 JSON 作为源自 JavaScript 对象文字语法的紧凑表示法，并用一个小语法记录了其核心结构。早期的描述帮助开发人员为对象、数组、字符串、数字、布尔值和空值提供了共享名称和引用。将页面描述为早期的公开解释比在没有引用历史证据的情况下声称页面或个人单枪匹马地发现了一种格式或确立了其采用更为安全。
当前存储库源不包括 json.org、浏览器使用或委员会讨论的存档历史记录。他们展示了该应用程序如何解析和诊断 JSON 今天。因此，本文中的历史陈述与过时的标准文件保持接近，并避免归因那些本地文件无法证明的动机或市场影响。
RFC 4627 in 2006 — 第一个 IETF 描述、应用程序 /json 媒体类型以及文本必须是对象或数组的规则
RFC 4627，在 2006 中发布，描述了用于 Internet 交换的 JSON 并注册了 `application/json` 媒体类型。它对 JSON 文本的定义需要顶层的对象或数组，即使字符串、数字和文字作为值存在于这些容器内。该限制是一个有用的历史差异，因为仅包含 `"ready"` 的文档可能是后续公式中的有效值，但不符合 RFC 4627 的 JSON 文本定义。
该文档还讨论了当时可用的实现上下文中的编码和安全问题。不应将其视为此存储库的更改日志：ToolAcre 不包含 RFC 4627 兼容模式，并且其解析器路径将值构造委托给主机 JavaScript 引擎。
ECMA-404 in 2013 — Ecma 的最小纯语法标准，以及为什么两个组织最终描述一种格式
ECMA-404 首次在 2013 中发布，以故意紧凑的形式指定 JSON 语法。它的重点是有效 JSON 文本的语法，而不是每个网络使用的完整交换配置文件。该范围有助于解释为什么 ECMA-404 和 IETF 文档可以描述相同的基本符号，但它们强调的周围互操作性指南有所不同。两个标准机构的存在并不意味着在日常使用中存在两种不兼容的格式。
关于组织为何选择特定发布路径的主张需要超出此代码库的文献资料，因此本文不会从标准日期推断委员会的动机。相关的实际问题是 RFC 8259 和 ECMA-404 旨在在语法上保持一致，而 RFC 8259 提供了对可互操作交换至关重要的建议。
RFC 7159 和 RFC 8259
RFC 7159 替换了 2014 中的 RFC 4627 并将 JSON 文本的定义扩展到任何序列化值，删除了仅对象或数组的顶级规则。 RFC 8259 取代了 2017 中的 RFC 7159，并保留通常为 JSON 引用的 IETF 参考。它需要在封闭生态系统之外的系统之间交换 JSON 的 UTF-8 ，并记录有关数字、重复名称、Unicode 和字节顺序标记的互操作性警告，而不是假装仅使用语法来保证各处的相同结果。
顶级 `true` 是一种观察 ToolAcre 中现代根值规则的紧凑方法，因为 `JSON.parse` 接受它。该结果展示了该实现的行为；当每个浏览器、服务器或 API 都采用更广泛的定义时，它不会重构。
对于工作开发人员来说发生了什么变化
对于工作开发人员来说，最明显的规范变化是现代对任何 JSON 值的根本接受以及对可互操作编码的更强有力的指导。不太明显的教训是，有效的语法仍然留下实现选择。重复的对象名称可能会被折叠，成员排序不是语义契约，非常大的数字可能会失去精度，并且不寻常的 Unicode 序列可能会以不同的方式在库中传输。因此，符合标准的文档应该受到应用程序模式的额外约束。
在此格式化程序中，重复的名称和数字标记首先通过 `JSON.parse`，因此稍后的格式化会反映生成的 JavaScript 值而不是原始词汇文档。扫描仪在出现故障后提供诊断；它不保留重复的成员或任意精度的数字。这些是存储库支持的观察结果。
这不包括什么
这不包括 JSON 之上的规范。 JSON 模式描述了对文档形状和值的约束； JSON 指针寻址文档内的位置； JSON 补丁代表更改。它们解决了与基本语法不同的问题，不应被视为 JSON 本身的更高版本。 JSONC、JSON5 和类似的创作格式也扩展或改变了可接受的语法，并需要它们自己的解析器，而不是默默地折叠到严格的验证中。
本文还避免了 JSON 采用、浏览器支持或与 XML 竞争的全面社会历史，因为列出的存储库来源无法证实该叙述。尚未发明外部引文来填补这一空白。
要点：RFC 8259 是引用的参考文献
RFC 8259 是引用当前 JSON 语法和互操作性指南的实用 IETF 参考，ECMA-404 提供对齐的 Ecma 语法标准。 RFC 4627 和 RFC 7159 对于理解已发布的定义如何更改（尤其是在顶层）仍然有用。引用支持确切声明的文档，而不是使用“JSON 规范”作为对权威的模糊诉求，并将规范规则与特定解析器中观察到的实现行为区分开来。
对于 ToolAcre，合理的说法是存储库使用 JavaScript 的 JSON 解析器和序列化器，并添加严格的本地扫描器以在失败后进行诊断。对顶级值、格式错误的标点符号和数字处理的测试描述了该路线；它们不是历史来源。