JSON 验证器

JSON 校验器只回答一个问题：解析器会不会接受这份文档。这听起来很窄，却正是要紧的问题，因为您下游的每一个使用者，无论用什么语言，套用的都是同一套语法。这里能解析，那里就能解析。

有用的不是是或否，而是位置。现代 JavaScript 引擎改变了报告语法错误的方式：较新的浏览器不再给出字符偏移量，而是返回问题附近一段带引号的源码窗口。这对阅读更友好，对工具把它转成光标位置却困难得多，这也是某些校验器退化到只说「意外的记号」而完全不给行号的原因。我们用二分法定位失败点，把文档不断缩小到最小的出错片段，因此错误依然能指向一个可操作的行与列。

现实中的失败大多来自一小组原因，认出它们就省去了搜索。对象或数组最后一个元素之后的尾随逗号，在 JavaScript 里合法，在 JSON 里非法。用单引号包裹字符串同样是 JavaScript 的习惯，JSON 并不接受。不加引号的对象键在 JavaScript 字面量中有效，在 JSON 中无效。两种形式的注释都不属于这个格式，无论在配置文件里看起来多么合理。而 JavaScript 乐于产出的裸 NaN 或 Infinity，在 JSON 中根本没有表示法。

编码会制造最令人困惑的失败。文件开头的字节顺序标记在多数编辑器中不可见，却让第一个字符不再是解析器期待的花括号。从文字处理软件粘贴来的文本可能带着弯引号，它们与直引号看起来几乎一样，却不是同一个字符。一份看起来完美却在位置零拒绝解析的文档，几乎总是这两者之一。

有效不等于正确。一份文档可以干净地解析，对它的用途却仍然是错的：缺少必填字段、该是字符串的地方是数字、使用者想要对象却给了数组。那属于模式校验，是另一个更重的问题，而只检查语法的校验器对此什么也不会告诉您。分清自己真正需要哪一种，能省下不少时间。

与本站所有工具一样，文档在您的浏览器中解析，从不外传。这一点尤其值得在意，因为人们拿来校验的文档正是那些在生产中出问题的文档，而它们往往塞满了属于真实用户的真实标识。