JSON 校验器

粘贴任意 JSON 文档,看看它能否依照 RFC 8259 干净地解析。无效的输入会返回确切的问题,最后一个数组项后多了逗号、键没加引号、字符串没闭合、用了单引号而 JSON 要求双引号、转义序列错误,还会给出解析器放弃的那一行和那一列。在调试 API 响应、配置文件、队友手改过的 package.json 或代码生成器的输出时都很有用。

JSON 校验是如何工作的

  1. 1

    粘贴你的 JSON

    放进一段载荷、一个配置文件或一份 API 响应。空白没问题;制表符和注释不行(纯 JSON 没有注释)。

  2. 2

    用严格的 RFC 8259 解析器解析

    校验器会拒绝规范所禁止的一切:多余逗号、未加引号的键、单引号、`undefined`、十六进制数字。

  3. 3

    阅读错误信息

    若解析失败,你会得到解析器的提示外加一个大致位置:足以让你直接定位到那个字符。

  4. 4

    修复并重新校验

    改正问题,再次粘贴,在提交或发送前确认文档是有效的。

严格 JSON 允许什么,又不允许什么

外面流传着许多 “几乎是 JSON” 的格式(JSON5、JSONC、HJSON、类 YAML 的混合体)。JSON 规范本身小而严格;这个校验器会告诉你文档能否扛过一个严格解析器,而那正是大多数下游系统实际运行的东西。

最容易绊倒人的规则

规则 有效 无效
键必须是双引号字符串 {"a": 1} {a: 1}
字符串只用双引号 "hello" 'hello'
不能有多余逗号 [1, 2, 3] [1, 2, 3,]
不能有注释 (无) // comment/* */
数字:不能有前导 +,也不能写 .5 0.5 +1.5
只允许保留字面量 truefalsenull undefinedNaN
UTF-8 编码 Unicode 字符串 无效字节序列

常见错误及其含义

  • “Unexpected token },你在闭合花括号前多了一个逗号。
  • “Expected property name”,键没加引号,或者你忘了给起始键加引号。
  • “Unexpected end of input”,有一个开头的 {[ 没有闭合;数一数括号。
  • “Bad control character”,字符串字面量里有制表符、换行符或其他控制字节。把它们转义成 \t\n 等。
  • “Duplicate key”,严格来说这并不是 JSON 规范错误(规范说键 SHOULD 唯一),但许多校验器会发出警告。本校验器会把它标记为提示,而不是硬性失败。

如果你需要更宽松的格式

  • JSON5 允许多余逗号、注释和单引号。如果那才是你的目标格式,请使用 JSON5 解析器。
  • JSONC(带注释的 JSON)是 VS Code 设置所用的格式。严格解析前请先剥掉注释。
  • YAML 是另一种格式;不要把它当成 “只是带缩进的 JSON”。

小贴士

  • 提交前先校验。 package.json 或某个 CI 配置里的一个笔误,会把整个构建拖垮,直到有人发现为止。
  • 校验之后再美化输出,让代码评审的 diff 更易读。一行式的 JSON 文件虽然有效,评审起来却苦不堪言。
  • 对于大载荷,请用流式校验(例如命令行上的 jq)。浏览器内解析超过几 MB 就会吃力。

常见问题

这个工具只检查语法有效性,它是不是格式良好的 JSON?对于结构规则(必填字段、枚举值、字符串长度),请使用 JSON Schema 校验器。这两步是互补的:对一个本身就不是有效 JSON 的文档去跑 Schema 校验毫无意义。

因为标准 JSON 没有注释。///* */ 是顺理成章的扩展(JSONC、JSON5),但纯 JSON 会拒绝它们。在发送给严格的消费方之前剥掉注释,或者在整个技术栈中统一采用 JSON5。

在严格 JSON 中无效。规范只允许有限数值。请按消费方处理缺失数据的方式,把它们序列化成字符串("NaN""Infinity")或 null

不会,校验在你的浏览器中运行,所以你粘贴的载荷绝不会离开页面。对于敏感的配置文件以及含凭据的 API 响应都很安全。

相关工具

此工具还提供其他语言版本