格式化 JSON

JSON—JavaScript Object Notation—是用于结构化数据交换的无处不在的基于文本的格式。它由IETF作为RFC 8259和Ecma International作为ECMA-404共同标准化，它们共同定义了为现代API、日志、配置和数据库提供支持的紧凑、与语言无关的语法。

语法和编码：保持系统通信的精确位

JSON值是对象、数组、字符串、数字或字面量true、false或null之一；对象将字符串映射到值，数组则包含有序的值——结构字符周围允许有无关紧要的空白（RFC 8259,ECMA-404）。尽管JSON源于JavaScript，但它与语言无关，几乎在任何地方都受支持（MDN: JSON）。在线路上，事实上的和推荐的编码是 UTF-8（RFC 8259 §8.1）。为了额外的互操作性安全，I-JSON配置文件（RFC 7493）收紧了关于编码和数值范围的规则。

在JavaScript中，全局JSON对象公开了两个主力：JSON.parse（带有一个可选的reviver）和JSON.stringify（带有用于美化打印的replacer/spacing），如MDN上所记录（parse,stringify）。

数字：看似简单，实则尖锐

JSON的数字语法是十进制的，但规范并未规定精度或整数/浮点数的区别。实现方式自行选择如何表示它们（RFC 8259 §6）。在JavaScript和Node.js中，Number是IEEE-754双精度，这意味着只有在[−(2^53−1), 2^53−1]范围内的整数才是完全安全的——参见Number.MAX_SAFE_INTEGER和BigInt类型。这就是为什么公共API通常将ID作为字符串传输并明确验证“安全整数”的原因。

超越普通JSON：指针、补丁和合并补丁

随着使用的成熟，出现了用于寻址和就地修改JSON的标准。JSON指针（RFC 6901）是一种微小的、斜杠分隔的语法，用于定位值（例如，/a/b/0），并为~和/提供了转义规则。JSON补丁（RFC 6902）将部分更新建模为有序操作（add、remove、replace、move、copy、test），并以application/json-patch+json的形式传输。对于更简单的差异，JSON合并补丁（RFC 7386）使用文档形状的合并：存在的字段被添加/替换；将字段设置为null会删除它。许多框架都原生支持这两种形式中的一种或两种。

模式与类型：验证与生成

JSON本身是无模式的，但生态系统依赖于模式进行验证、文档编制和代码生成。JSON模式2020-12系列规定了诸如type、properties、items和组合关键字等约束，并与OpenAPI 3.1保持一致。对于以代码生成为中心的工作流，JSON类型定义（RFC 8927）提供了一种故意降低表达能力的语言，可以可预测地映射到主流类型系统。

流式处理与大数据：JSON Lines和序列

传统的JSON期望每个有效负载有一个完整的文本，这使得流式处理日志和长寿命响应变得复杂。有两种模式可以提供帮助：

• JSON文本序列（RFC 7464）：一个UTF-8 JSON文本流，每个文本前缀为记录分隔符（U+001E），并以LF结尾；注册为application/json-seq。
• NDJSON / JSON Lines：每一行都是一个独立的JSON值——易于跟踪、gzip压缩和进行map-reduce（ndjson.org,jsonlines.org）。它在批量API中很受欢迎，例如Elasticsearch的批量API。

二进制近亲：当文本不够紧凑时

当带宽或速度占主导地位时，“二进制JSON”格式在保留JSON数据模型的同时，用效率换取了人类可读性：

• BSON（MongoDB的原生格式）添加了二进制、日期时间和类型化整数等类型（bsonspec.org）。
• MessagePack紧凑且无模式，在各种语言中广泛实现（msgpack.org）。
• CBOR标准化了一种可扩展的紧凑格式（带有JSON转码指南），在物联网/受限环境中很常见（RFC 8949,cbor.io）。
• Smile（来自Jackson生态系统）使用可选的后向引用对重复的名称/值进行JSON编码（jackson-dataformat-smile）。

安全说明：旧技巧与现代修复

因为JSON只是文本，所以大多数风险来自于您如何传输和处理它：

• JSONP（通过带有回调的<script>请求数据）是CORS之前的跨域请求变通方法，但很危险——它会执行任意脚本。请优先使用带有真实application/json响应的CORS（OWASP: JSONP Abuse）。
• JSON劫持：返回敏感数组的简单GET端点可能会在旧版浏览器中通过跨域脚本标签被窃取；缓解措施包括使用CSRF保护的POST或使用非JSON哨兵作为前缀（OWASP: JSON Hijacking）。
• JSON注入：将JSON视为数据，而不是代码；勤于转义并验证输入（OWASP: JSON Injection）。

媒体类型与传承

JSON在RFC 4627 (2006)下首次亮相；注册的媒体类型是application/json，其规范现在指向RFC 8259。由于UTF-8是公共互联网上的默认设置，因此JSON响应上的“charset”参数通常是不必要的。

在生产中实现健壮JSON的实用技巧

• 在任何地方都默认使用UTF-8；在输入和输出时都假定为UTF-8（RFC 8259 §8.1）。
• 对大整数要明确：如果ID可能超过2^53−1，请将其作为字符串传输并记录下来（MDN: MAX_SAFE_INTEGER）。
• 使用JSON模式2020-12（或对于代码生成密集的堆栈，使用JTD）验证有效负载。在API文档旁边发布模式（OpenAPI 3.1）。
• 明智地打补丁：对于操作级别的差异，使用JSON补丁，对于简单的文档形状更新，使用合并补丁。
• 大规模流式处理：为日志和长寿命响应选择JSON文本序列或NDJSON；明确媒体类型。
• 当文本成为瓶颈时，求助于二进制（BSON,MessagePack,CBOR,Smile）——但要确保两端都同意类型。

关于“更友好的JSON”的一点说明

开发人员通常希望在配置文件中使用注释、尾随逗号或单引号字符串。这超出了标准JSON的范围，但JSON5为人工编辑的文件提供了一个文档齐全的超集。除非您控制两端，否则避免通过公共API发送JSON5。

JSON的成功来自于其小巧的表面积、广泛的语言支持以及一系列相邻标准——指针、补丁、模式、序列——这些标准涵盖了分布式系统的混乱现实。理解基础知识（语法、编码、数字），依靠正确的相邻标准，它将继续在各种堆栈和服务中带来红利（RFC 8259,ECMA-404,RFC 6901,RFC 6902,RFC 7386,JSON Schema,JTD,RFC 7464,NDJSON）。