JSON 格式化与校验

关于 JSON 格式化与校验

JSON 格式化与校验工具会重新缩进 JSON 文档，让结构一目了然；需要紧凑载荷时可以折叠回单行；当输入无法解析时，它会报告第一个语法错误的精确位置。

JSON 的语法比多数人以为的要小得多。它不支持注释、尾随逗号、单引号字符串和不加引号的键，这些都是 JavaScript 对象字面量的特性，JSON 有意没有纳入。绝大多数「JSON 无效」的情况，都是一份 JavaScript 引擎会欣然接受的文档，所以错误位置比错误信息更有价值。

如何使用这个开发者工具

把响应体、配置文件或日志行粘贴到输入区。
选择「格式化」做带缩进的美化输出，或选择「压缩」去掉所有可省略的空格与换行。
解析失败时，读取报告的偏移量，检查该位置之前的几个字符，而不是错误信息指向的那一行。
把格式化结果与原文对照，确认没有值被重新解释，尤其是长整数和带前导零的数字。
复制结果；也可以保留格式化副本用于评审，把压缩版本发到线上。

实例：定位尾随逗号

这段载荷乍看没问题，在 JavaScript 控制台里也能通过，但严格的 JSON 解析器会拒绝它。格式化工具会报告第一个不能作为值起始的字符的位置。

输入

{"id":42,"tags":["beta","internal",],"owner":{"name":"Ada","email":"ada@example.com"}}

报告的错误

Unexpected token ] in JSON at position 35

位置 35 是那个右方括号，但真正的问题是位置 34 的逗号。解析器只能报告「本应出现值」的位置，永远无法指出多余的分隔符写在哪里，所以要习惯往前看一个字符。

JSON 允许与不允许的写法

右列每一行都是合法的 JavaScript、非法的 JSON。这张表本身就能解决大部分解析失败。

语法元素	合法 JSON	常见的非法写法
对象键	{"name": "Ada"}	{name: "Ada"}
字符串	"single item"	'single item'
尾随分隔符	[1, 2, 3]	[1, 2, 3,]
注释	完全不支持	{"a": 1} // note
数字	{"n": 0.5}	{"n": .5} 或 {"n": 007}
特殊值	{"v": null}	{"v": undefined} 或 {"v": NaN}

常见问题排查

格式化之后，一个很大的数字 ID 变了值。

成因 JSON 数字按 IEEE 754 双精度解析。超过 2^53 - 1 的整数会损失精度，19 位的 Snowflake 或数据库 ID 会被静默四舍五入。

解决办法 要求上游服务把标识符序列化为字符串。如果只是查看文档，请直接看原始文本而不是解析结果。

错误信息指向的行号，远在真正的错误下方。

成因缺失的右花括号或未闭合的字符串会让解析器一直向后吞掉输入，直到遇到结构上不可能的内容才报错。

解决办法 把文档格式化到最后一行仍然正常的位置，然后检查紧随其后的那个块。引号不配对通常表现为一个异常长的高亮字符串。

日志行看起来就是 JSON，却解析不了。

成因日志采集器经常在前面加上时间戳和级别，或者把整份文档转义后作为一个 JSON 字符串传输，也就是 JSON 里套 JSON。

解决办法 先删掉第一个花括号之前的所有前缀。如果整个载荷被引号包裹且带反斜杠转义，先对这层字符串解码一次，再格式化结果。

压缩后的体积比预期大。

成因压缩只会去掉无意义的空白。多数文档的体积由长键名、重复结构和 Base64 数据块决定。

解决办法 传输体积交给 HTTP 压缩处理。压缩功能用于构造请求体或测试夹具，不要当作减小体积的手段。

适合用这个工具的场景

调试对接问题时，把 API 响应变得可读。
在部署被拒绝之前，确认配置文件语法合法。
为 curl 命令或测试夹具生成紧凑的单行请求体。
定位服务端日志只笼统描述为「请求格式错误」的那个语法错误的确切偏移量。

应该换用别的工具的场景

检查文档是否符合预期结构。格式化只能证明语法，必填字段和类型要用 JSON Schema 校验。
从大文档中查询或抽取值，那是 JSONPath 测试器的工作。
重排 JSON Lines 或 NDJSON 文件，这类文件每一行都是独立文档，而不是一个数组。

隐私与数据处理

解析和重新序列化都在当前浏览器标签页中使用平台自带的 JSON 实现完成。文档不会发送到服务器，不会跨访问保存，关闭标签页即丢弃。但样例响应中内嵌的访问令牌仍然对浏览器扩展和旁观者可见，粘贴前请先脱敏。

常见问题

格式化会改变我的数据吗？

格式化只改变词法单元之间的空白，因此键、字符串和布尔值可以精确往返。唯一的例外是数值精度：超过 2^53 - 1 的整数，以及有效数字超出双精度表示能力的数字，会被重新序列化为最接近的可表示值。

为什么带注释的 JSON 会被拒绝？

JSON 规范没有注释语法。允许注释的格式，例如编辑器配置里的 JSONC 或 JSON5，是各自独立的语言。请在解析前删除注释，或改用能理解该方言的加载器。

压缩后的 JSON 解析更快吗？

快一点点，但几乎从来快不到能测出来的程度。词法分析跳过空白的代价极低。压缩主要的收益是减少网络字节数，而这件事 HTTP 压缩做得更好。

能格式化几十 MB 的文件吗？

超大文档受浏览器内存限制，因为整个结构必须一次性驻留内存。超过大约一百 MB 的文件，请改用流式的命令行工具，而不是任何基于浏览器的格式化器。

工具会保留对象键的顺序吗？

会。输出按解析结构的插入顺序生成，因此键序与书写顺序一致。但 JSON 规范并不保证消费方尊重顺序，所以不要把正确性建立在键序上。

「合法」和「正确」的 JSON 有什么区别？

合法的 JSON 能被解析；正确的 JSON 还要带有接收方期望的字段和类型。一份文档完全可以语法合法，却因为缺少必填属性、或数字以字符串形式传来而被 API 拒绝。

JSON 格式化

JSON

结果