JSON 格式化与验证工具

使用方法

JSON（JavaScript 对象表示法）是在 API、配置文件和应用程序之间交换结构化数据的标准文本格式——它由对象（花括号中的键值对）、数组（方括号中的有序列表）以及少数几种值类型（字符串、数字、布尔值、null，以及嵌套的对象或数组）构成。由于它只是文本，一个缺失的逗号或多余的字符就会让整份文档在解析器看来变得无法读取。格式化与验证解决的是两个不同的问题：格式化（美化打印）重新调整文本缩进，让其结构对人眼一目了然；而验证则在任何代码尝试解析之前，检查该文本是否确实是语法正确的 JSON。 设想有一个从 API 返回的小对象，全部挤在一行——一个 “user” 键对应字符串 “ada”，一个 “active” 键对应布尔值 true，以及一个 “roles” 键对应数组 [“admin”, “editor”]，所有内容紧凑排列，没有任何空格。用 2 个空格缩进将其美化后，每个键都会独占一行并逐级缩进，因此 “user”、“active” 和 “roles” 这几项，以及嵌套的 roles 数组，都能一眼看清。压缩则相反：它会去掉格式中所有非必需的空格、制表符和换行符，把美化后的版本直接折叠回原始的紧凑字符串。压缩并不会改变数据的含义——它只是移除了为方便人类阅读而存在的空白，这也是为什么在通过网络发送 JSON 之前压缩它是安全的，但在自己阅读之前压缩它毫无意义。 验证能捕捉到那些手写时容易犯、用肉眼又容易漏看的错误：对象或数组最后一项之后多余的逗号（在 JavaScript 对象字面量中合法，在 JSON 中非法）、未加引号书写的对象键、用单引号而非双引号包裹的字符串，以及开启了却从未闭合的括号或花括号。JSON 的语法对这些错误毫无容忍度——不同于接受更宽松语法的 JavaScript，JSON 解析器会在发现的第一个错误处直接拒绝整份文档。修复无效的 JSON 通常需要从头开始逐一排查错误：给键和字符串值加上双引号、去掉花括号或方括号前的最后一个逗号，并数一数括号，确保每个左括号都有对应的右括号。 缩进大小是一种约定而非对错问题——2 个空格在 JavaScript/TypeScript 及网页配置文件中很常见，因为它能让深层嵌套的对象保持更紧凑；4 个空格在 Python 相关工具及强调层级间视觉区分的风格指南中更常见；而制表符则让每位读者的编辑器都能按自己偏好的宽度渲染。这些都不会影响 JSON 的解析方式，选择与您正在编辑的文件或团队既有约定相匹配的那种即可。 格式化与验证 JSON 是家常便饭：调试网络面板中以压缩形式返回的 API 响应、在手动编辑的配置文件（如 package.json 或 tsconfig.json）破坏构建之前进行检查、清理从日志行或错误消息中复制出的 JSON 使其可读，以及在存储或传输 JSON 之前将其压缩以减少数据体积——即使只是小幅减少，累积到数百万次请求也会相当可观。

常见问题

我的 JSON 会被发送到服务器吗？

不会。格式化、压缩和验证均在您的浏览器中完成——您的数据永远不会离开您的设备。

验证工具会检查什么？

它会将您的文本按严格的 JSON 规则进行解析，并报告第一个语法错误；当浏览器提供相关信息时，还会显示该错误所在的行号和列号。

美化和压缩有什么区别？

美化会添加缩进和换行，让 JSON 更易读；压缩则会去除所有不必要的空白，使其体积尽可能小。

如何修复无效的 JSON？

先阅读错误消息——它通常会指出解析失败的行号和列号。最常见的原因包括：闭合花括号或方括号前多余的逗号、用单引号而非双引号包裹的对象键或字符串值，以及缺失的闭合括号。修复第一个错误后重新验证，重复此过程，直到文档能够顺利解析。