JSON 格式化

什么是 JSON 格式化工具？

这个工具用于把一段 严格 JSON 文本在浏览器里即时整理成更易读的结构，或者压缩成一行便于传输。当前页面提供三项核心能力：

• pretty：按缩进输出，方便阅读、排错、审查接口返回值。
• minify：移除多余空白，适合粘贴到请求参数、环境变量或日志系统。
• sortKeys：按键名递归排序对象字段，便于比较前后版本差异。

需要注意的是，这个工具不是 JSON5 编辑器，也不是 schema 校验器。它调用浏览器原生 JSON.parse() 解析输入，因此不支持注释、尾逗号、单引号、未加引号的键名，也不会帮你修复非法语法。

当你勾选“排序键名”时，工具会递归重排对象键，但不会改变数组顺序，因此它更适合“展示一致化”，而不是加密签名或跨系统严格规范化。

适合哪些场景？

• 调试 REST / GraphQL 接口返回值。
• 整理配置文件或测试夹具。
• 在复制到 URL、环境变量、日志系统前先做压缩。
• 把字段顺序对齐后，再配合 diff 工具查看变更。

参考资料

• 根据 RFC 8259，JSON 语法必须使用双引号字符串、不能包含注释。
• ECMA-404 给出了 JSON 的基础语法定义。
• MDN 对 JSON.parse() 与 JSON.stringify() 的行为有完整说明。

使用说明

1. 粘贴 JSON 输入

把需要处理的内容粘贴到左侧输入框。只有合法 JSON 才会成功解析，例如：

{"name":"devtool","enabled":true,"items":[3,2,1]}

2. 选择输出模式

• pretty：输出多行缩进格式，适合人工阅读。
• minify：输出一行紧凑格式，适合传输或嵌入。

3. 选择缩进与是否排序

当前页面提供 2 和 4 两档缩进。勾选“排序键名”后，对象键会按字母顺序递归排序，数组本身不会重排。

4. 读取结果或错误提示

• 解析成功：右侧立即显示格式化结果，并支持复制。
• 解析失败：页面下方显示解析错误，常见原因是尾逗号、注释、单引号或漏掉双引号。

推荐工作流

1. 先粘贴原始 JSON。
2. 用 pretty 检查结构是否正确。
3. 如需对比版本，开启 sortKeys。
4. 如需传输或嵌入，再切到 minify。

参考资料

• RFC 8259 规定了 JSON 的合法语法范围。
• MDN 的 JSON.parse() 文档说明了解析失败时的异常行为。
• MDN 的 JSON.stringify() 文档说明了缩进与序列化输出规则。

参数与行为参考

这个页面的底层能力来自 formatJson(input, options)，其行为可以概括为下表。

成功结果

成功时返回：

• ok: true
• parsed：解析后的 JS 值
• value：最终展示到右侧文本框的字符串

失败结果

失败时返回：

• ok: false
• error：来自 JSON.parse() 的错误消息

已知边界

• 页面没有文件导入、schema 校验、注释容忍模式。
• indent 的底层实现可接收任意数字，但 UI 只提供 2 和 4。
• sortKeys 更像“可读性整理”，不是 RFC 8785 定义的 JSON Canonicalization Scheme。

参考资料

• MDN: JSON.parse()
• MDN: JSON.stringify()
• RFC 8785 解释了“规范化 JSON”与普通排序输出的区别。

常见问题

为什么带注释的 JSON 会报错？

因为当前实现直接使用原生 JSON.parse()。根据 RFC 8259，注释并不属于 JSON 标准语法。

为什么单引号、尾逗号也不行？

这些写法常见于 JavaScript 对象字面量或 JSON5，但不属于标准 JSON。若你的目标是接口请求体、配置交换或跨语言数据传递，保持严格 JSON 反而更安全。

排序键名会不会改坏数据？

对对象语义通常没有影响，但如果你依赖“字段原始顺序”做展示、签名、快照比对，排序后结果会不同。数组顺序不会被改变。

为什么空输入不报错？

当前工具把空输入视为“没有内容可格式化”，因此返回空输出，方便你清空输入框后继续编辑。

这能替代 JSON 校验器吗？

只能覆盖基础语法合法性。它不会校验字段必填、枚举值、类型约束，也不理解 JSON Schema。

参考资料

• RFC 8259
• ECMA-404
• MDN: JSON.parse()

JSON、对象字面量与规范化

很多人会把 JSON 和 JavaScript 对象写法混在一起，但两者并不完全等价。

当前工具站在“严格 JSON”这一侧，所以行为更接近数据交换协议，而不是源码格式化器。

为什么排序不等于规范化？

很多场景只需要“看起来稳定”，例如把字段顺序统一后再做代码审查；但真正的 canonical JSON 还会约束数字、Unicode、转义、序列化过程等细节。当前工具只做对象键递归排序，并没有完整实现 RFC 8785。

这意味着它适合：

• 提高可读性。
• 减少人工比较时的视觉噪声。

但不适合：

• 数字签名。
• 哈希校验。
• 需要跨平台完全一致字节输出的场景。

参考资料

• ECMA-404 解释了 JSON 的语法范围。
• RFC 8259 是现代 JSON 标准。
• RFC 8785 说明了 JSON Canonicalization Scheme。

使用技巧

先 pretty，再 minify

如果你拿到的是一长串压缩 JSON，先展开看结构，再决定是否需要压缩回去。这样最容易发现缺少括号、字段嵌套过深或数据类型异常。

对比版本时开启排序

当接口返回字段顺序不稳定时，开启 sortKeys 后再配合文本 diff，会更容易看出真实变更点。

不要把“排序输出”当签名输入

如果下游系统依赖严格字节序列，当前输出不保证 canonical。此时应使用专门的规范化方案。

注意这些常见报错来源

• 复制自 JS 代码：含注释、尾逗号、单引号。
• 复制自日志：前后多了提示词或时间戳。
• 复制自接口平台：被包了一层转义字符串。

大文本时分段排查

如果报错位置不明显，可以先把 JSON 拆成较小片段定位问题，再贴回完整内容。

参考资料

• MDN: JSON.parse()
• MDN: JSON.stringify()
• RFC 8785