如何格式化和校验 JSON
要格式化 JSON，把它粘贴进一个格式化工具里，让它加上缩进和换行，使结构一目了然；要校验它，则把它送进一个解析器，由解析器检查语法并指出它出问题的确切位置。格式化（也叫美化或漂亮打印）和校验通常是一起进行的：一个好的工具会为有效的 JSON 重新缩进，而当输入是错的时候，会准确地告诉你哪里出了问题。下面就讲讲每个操作究竟做了什么、该格式化还是该压缩，以及如何读懂并修复解析器抛出的错误。
格式化、压缩、校验：三件不同的活儿
这三个词常被混用，但它们对你的数据做的是各不相同的事情。
- 格式化（美化） 会加上缩进和换行，让嵌套的对象和数组在视觉上对齐。它并不改变数据——只改变空白字符——从而让你能用肉眼轻松扫读一个配置文件或一段 API 响应。
- 压缩 做的恰恰相反：它剥除每一个非必要的空格、制表符和换行，让数据载荷尽可能地小。数据是完全相同的，只是实际上被挤到了一行里。
- 校验 检查这段文本到底是不是合法的 JSON。校验器会解析输入，要么确认它格式良好，要么报告它遇到的第一个语法错误。
实践中，你在阅读和调试时格式化，而在把数据通过网络发送出去或存储起来之前压缩。校验则是这两者的根基——你无法可靠地格式化或压缩一段一开始就不是有效 JSON 的文本。
何时格式化 vs 压缩
每当有人需要查看数据时，就用格式化：
- 调试时查看一段 API 响应。
- 审阅或编辑
package.json、tsconfig.json或任何配置文件。 - 在版本控制里对两个 JSON 文件做差异比较，其中一致的缩进能让差异保持小而清晰。
- 粘贴一段从日志里来的密密麻麻的单行内容，并想真正看懂它的结构。
当字节数很重要、而没有人在阅读时，就用压缩：
- 在 HTTP 响应或请求体里发送 JSON，其中更小的数据载荷意味着更快的传输。
- 把配置嵌入到环境变量或 URL 里。
- 存储大量记录时，空白字符在成千上万行里累积起来会很可观。
一个有用的习惯：让你的源文件保持格式化以便阅读，并让你的构建流程或服务器在输出时进行压缩。你就能两全其美——在代码仓库里可读，在网络上紧凑。
最常见的 JSON 错误（以及如何修复）
JSON 是刻意设计得很严格的，正是这一点让它能在每一种语言之间通用。而同样的严格性也会把人绊倒，尤其是任何习惯了写 JavaScript 对象字面量的人。下面这些错误反反复复地出现：
- 尾随逗号。 对象或数组中最后一项之后的逗号——
{"a": 1,}——是无效的。把它去掉。这是头号最常见的错误，因为大多数编程语言都允许它。 - 用单引号而不是双引号。 JSON 要求键和字符串值都用双引号。
{'name': 'Ada'}必须改成{"name": "Ada"}。 - 未加引号的键。 键永远是带引号的字符串。
{name: "Ada"}是一个 JavaScript 对象，而不是 JSON；它必须写成{"name": "Ada"}。 - 缺少逗号。 除了最后一项，每一项都需要一个逗号把它和下一项隔开。两个值连在一起、中间什么都没有，就会解析失败。
- 注释。 JSON 没有注释语法。以
//开头或被/* */包裹的行都是不允许的，必须在文本通过校验之前剥除掉。
还有几点要留意：数字不能有前导零或结尾的小数点，字符串必须转义像 \n 和 \" 这样的特殊字符，而除了数字和字符串之外，唯一允许的字面量是 true、false 和 null（小写、不加引号）。
如何读懂解析错误
当校验失败时，解析器通常会报告一个位置——一个行号和列号，或者一个字符偏移量。要照字面去理解那个位置：错误是在解析器无法解读的第一个字符处报告的，而它往往是在真正的错误之后紧接着的地方。举个例子，缺少逗号常常会被标在下一个键的开头，而不是本该有逗号的那个空隙处。跳到报告的位置，然后看紧挨在它前面的那个词元。一旦你修好了第一个错误，就重新校验，因为解析器在遇到第一个问题时就会停下，后面可能还藏着更多问题。
在你的浏览器里私密完成
很多在线 JSON 工具会把你粘贴的任何东西发送到远程服务器去处理。而对 JSON 来说，这往往是最不该上传的数据，因为 API 密钥、访问令牌、内部主机名、客户记录以及其他机密，恰恰最常住在这里面。
Andev 的 JSON 格式化工具 彻底避免了这一点。它使用浏览器自带的原生 JSON.parse 和 JSON.stringify，这意味着：
- 你的数据从不上传。 一切都在你的设备上本地运行；没有任何东西被发送到任何地方。
- 它会呈现确切的解析错误。 当输入无效时，你会看到具体的报错信息和位置，于是可以直奔问题而去。
- 由你选择缩进大小。 用两个空格、四个空格或制表符来格式化，以匹配你项目的风格——或者压缩成单行。
- 它是即时的。 没有上传再等待的往返；结果出现的速度和你粘贴的速度一样快。
由于它依托的正是你的应用程序已经在使用的同一个 JSON 引擎，它报告的校验结果，与你的代码在解析同一个字符串时的实际行为是一致的。这让它在处理敏感的配置和 API 数据载荷时用起来很放心，并且作为发布前的一次快速核验也很可靠。
对于相邻的任务，同样这套本地、不上传的方式也驱动着 Andev 的 Base64 编码与解码工具 和它的 URL 编码与解码工具——当 JSON 被嵌入到一个 data URI、一个令牌或一个查询字符串里时，这两个都很顺手。
要点回顾
- 格式化 加上缩进以便阅读；压缩 剥除空白字符以减小数据载荷；校验 检查语法。它们是三件各自独立的活儿。
- 为人格式化，为网络压缩——让源文件保持可读，并让你的构建流程把输出压紧。
- 大多数错误都是严格性陷阱： 尾随逗号、单引号、未加引号的键、缺少逗号和注释，全都是无效的 JSON。
- 在报告的位置处读懂解析错误， 然后检查紧挨在它前面的那个词元；修好一个错误就重新校验，因为解析器在遇到第一个错误时就停下了。
- 保持本地。 一个浏览器原生的格式化工具从不上传你的数据，而这对于住在配置和 API JSON 里的那些机密来说最为重要。
现在就需要清理或检查一些 JSON 吗？打开 免费、私密的 JSON 格式化工具——不上传、无需注册——或者浏览整套 浏览器内开发者工具。