开发者工具 · JSON 格式化程序和验证程序
JSON 验证器如何找到错误的确切行和列
· 工作原理
json 验证 开发人员工作流程
浏览器引擎报告 JSON.parse 失败的方式不同，有些仅提供字符偏移量。这篇文章解释了验证器如何将其转换为行和列，以及为什么位置标记解析停止的位置而不是出错的位置。
错误消息什么也没告诉你——为什么“Unexpected token in JSON atposition 1432”在 400 行文件中毫无用处
在长配置中，诸如“意外令牌”之类的错误会令人沮丧，因为它没有提供可以在编辑器中打开的位置。 JSON.parse 是浏览器的权威解析器，但其诊断文本在 JavaScript 引擎和版本之间有所不同。 ToolAcre 不会通过匹配不稳定的英文错误字符串来猜测位置。如果 JSON.parse 失败，则单独的严格扫描器会遍历原始文本以识别 JSON 语法无法接受的第一个字符。
JSON 解析器在读取时实际执行的操作 — 演练标记化和一次消耗一个值的递归下降语法
JSON 有六个结构字符（大括号、方括号、冒号和逗号）以及可以是字符串、数字、数组、对象、true、false 或 null 的值。在将逗号称为分隔符之前，扫描器需要知道它是否位于带引号的字符串内：{"note":"A,B"} 有一个值，而不是两个值。它遍历一个值或一个对象成员，并检查接下来可以合法遵循的内容。 RFC 8259 定义了此语法，与 JavaScript 对象文字不同，它不允许注释或尾随逗号。
从字符偏移量到行和列 - 计算换行符直到失败偏移量，以及为什么 CRLF 结尾和多字节字符使计数变得复杂
扫描器通常以原始 JavaScript 字符串中从零开始的偏移量开始。为了使其有用，请计算偏移量之前的换行符，并找出故障距上次换行符的距离。 CRLF 应被视为一根视线结束线，而不是两条线； JavaScript 字符串中的位置计算 UTF-16 代码单元，而不是磁盘上的 UTF-8 bytes。非 BMP 表情符号可以在编辑器中占用两个代码单元，直观地显示一个字形。 UI 报告行、列和摘录，以便您可以根据粘贴的文件检查插入符号。
解析停止的地方并不是错误所在的地方 - 在下一个键处报告缺少逗号，并且杂散的引号可以将错误推到很多行
第一个不可能的标记通常是在最初的错误之后。在对象中，忘记 true 后面的逗号会使下一个属性开头的引号非法：解析器需要逗号或右大括号。未终止的字符串可能会导致错误出现在稍后的换行符或输入末尾。从报告的点向后读取以找到丢失的分隔符；不要假设必须删除插入符号下的字符。
工作示例：缺少一个逗号的配置 - 报告的位置、周围的标记以及如何向后走到真正的原因
尝试使用文字三行文档 {"name":"demo"，后跟第二行的 "enabled":true 和第三行的 "port":8080}，true 后面没有逗号。 ToolAcre 报告第 3 行，第 1 列，偏移量 31：它期望在前面的属性后面有一个逗号或 }，并且它在“port”的第一个引号下显示一个插入符号。在第二行末尾插入逗号，然后再次验证。这是对第一个语法障碍的诊断，而不是对“端口”一词错误的判断。
浏览器引擎有何不同 - V8、SpiderMonkey 和 JavaScriptCore 对同一故障的表述方式不同，这就是为什么一致的行和列报告会有所帮助
对于相同的 JSON.parse 失败，V8、SpiderMonkey 和 JavaScriptCore 使用了不同的措辞，有时还使用了不同的上下文片段。当本机解析器拒绝该值时，ToolAcre 的扫描器提供其自己的结构原因和位置。如果扫描器不同意 JSON.parse，该工具将返回引擎错误而不是伪造位置。这种后备措施比自信地指向猜测的角色更安全。
这不包括语义问题，例如错误类型、缺失字段或架构违规，语法验证器永远不会标记这些问题
对于您的应用程序来说，语法上有效的对象仍然可能是错误的：缺少必填字段、以文本形式写入的年龄、两个重复的键或对不存在文件的引用不会自动无效 JSON。 RFC 8259 规定成员名称应该是唯一的以实现互操作性，但仅仅解析并不会强制执行您的 API 架构。在此处验证语法并验证使用文档的程序中的语义约束。
要点：将位置读取为“语法无法接受的第一个标记”——以及 JSON 格式化程序和验证程序如何在不上传文本的情况下报告该行和列
将报告的位置视为“该语法无法接受的第一个标记”。向后追溯原因，解决一个问题并重新运行。 JSON 格式化程序和验证程序在本地执行此操作，而无需上传粘贴的配置。如果离线编辑器可以诊断该文件，请勿将真实的生产凭据粘贴到任何公共网站中。