如何第一时间看到新文章?
收藏本博客列表页,并在首页与工具聚合页留意指南入口。阅读文章无需注册或邮件订阅。
系统整理 JSON 解析中最常见的引号、逗号、括号、转义字符、非法值、重复键和大整数问题,提供错误示例、正确写法与可靠的排查顺序。
JSON 看起来简单,但一个引号、逗号或反斜杠放错位置,就可能让整个文件无法解析。更麻烦的是,解析器通常只报告它无法继续的位置,那里不一定是真正写错的地方。
这篇指南整理开发、接口联调、日志分析和配置维护中最常见的 JSON 问题。每一类都包含错误原因、错误示例、正确写法和修复建议。你可以先用 JSON 验证器 定位第一个错误;如果输入只是接近 JSON,可以用 JSON 修复工具 生成候选结果,再人工复核。所有处理都在浏览器本地完成。
快速原则:保留原始输入,从第一个错误开始修复;每修一处就重新验证,不要一次性猜测所有修改。
合法 JSON 只允许对象、数组、字符串、数字、布尔值和 null。对象的键和字符串必须使用双引号;JSON 不支持注释、undefined、NaN、函数或日期类型。
如果内容来自 JavaScript 源码、日志、Python 字典或配置文件,它可能只是“JSON 风格文本”,并不是真正的 JSON。先确认来源,可以避免用错误的方法修复。
| 现象 | 常见原因 | 优先检查 |
|---|---|---|
Unexpected token | 非法字符、单引号或未加引号的键 | 错误位置前后的引号与字符 |
Unexpected end of JSON input | 缺少括号、引号或数据被截断 | 文件末尾与网络响应是否完整 |
Expected ',' or '}' | 属性之间缺少逗号 | 上一行结尾 |
Bad control character | 字符串中含未转义换行或制表符 | 反斜杠和原始控制字符 |
| 解析成功但值不对 | 重复键、大整数或类型变化 | 数据语义与业务规则 |
标准 JSON 要求对象键和字符串都使用双引号。JavaScript 对象允许单引号和未加引号的键,因此从源码复制对象时经常出现这个问题。
错误示例:
{
name: 'Alice',
'role': 'admin'
}正确写法:
{
"name": "Alice",
"role": "admin"
}不要直接把全文所有单引号替换成双引号。字符串内部可能包含撇号或已转义字符,盲目替换会制造新的错误。更可靠的做法是让修复器识别字符串边界,再检查转换结果。
解析器可能把错误指向下一行的属性名,但真正的问题往往是上一项末尾缺少逗号。
错误示例:
{
"name": "Alice"
"active": true
}正确写法:
{
"name": "Alice",
"active": true
}数组也遵循同样规则:
["red", "green", "blue"]遇到 Expected ',' 时,先看报错位置的前一个完整值,而不只是盯着被标红的字符。
JavaScript 和部分配置格式允许尾逗号,但标准 JSON 不允许最后一个成员后继续保留逗号。
错误示例:
{
"name": "Alice",
"active": true,
}正确写法:
{
"name": "Alice",
"active": true
}数组末尾的逗号同样需要删除。可以用 JSON 美化器 再次解析并统一缩进,确认结果已经是标准 JSON。
Unexpected end of JSON input 通常表示解析器已经读到文本末尾,但对象、数组或字符串仍未结束。也有可能是网络响应、日志或复制内容本身被截断。
错误示例:
{
"user": {
"name": "Alice",
"tags": ["admin", "editor"]
}上面的外层对象还缺少一个右大括号。修复后的结构是:
{
"user": {
"name": "Alice",
"tags": ["admin", "editor"]
}
}如果数据来自接口,不要看到缺括号就直接补齐。先检查 Content-Length、请求状态、代理日志或原始文件,确认数据是否完整。工具可以补结构符号,却无法恢复已经丢失的字段和值。
JSON 使用反斜杠表示转义。双引号、反斜杠、换行和制表符分别需要写成 \"、\\、\n 和 \t。Windows 路径和正则表达式最容易出错。
错误示例:
{
"path": "C:\new\reports",
"message": "He said "hello""
}正确写法:
{
"path": "C:\\new\\reports",
"message": "He said \"hello\""
}还要注意:字符串不能直接跨行。如果内容中确实需要换行,应使用 \n,而不是在双引号之间插入真实换行。
标准 JSON 不支持 // 单行注释或 /* ... */ 块注释。下面的内容对 JavaScript 可能很熟悉,但不是合法 JSON:
{
// Production API endpoint
"apiUrl": "https://api.example.com"
}正确做法是移除注释,或把确实需要保留的说明变成明确字段:
{
"description": "Production API endpoint",
"apiUrl": "https://api.example.com"
}不要使用简单正则删除所有 // 后面的内容,否则可能误删 https:// URL。修复过程必须先识别字符串边界。
JSON 中的布尔值和空值只能写成小写的 true、false 和 null。以下值都不是标准 JSON:
True、False、NoneNULLundefined、NaN、Infinity错误示例:
{
"active": True,
"nickname": None,
"score": NaN
}候选修复:
{
"active": true,
"nickname": null,
"score": null
}这里不能只做机械替换。NaN 改为 null、字符串还是移除字段,取决于业务约定。语法修复工具可以提出候选结果,最终含义必须由数据所有者确认。
日志系统经常每行输出一个 JSON 对象,这种格式通常叫 NDJSON 或 JSON Lines。多行分别合法,不代表整份文本是一个合法 JSON 文档。
错误示例:
{"id": 1, "status": "ok"}
{"id": 2, "status": "failed"}如果目标系统需要标准 JSON 数组,应转换为:
[
{"id": 1, "status": "ok"},
{"id": 2, "status": "failed"}
]处理日志时还要确认每一行是否完整,不能仅在首尾添加方括号;对象之间还需要逗号,字符串中的换行也必须正确转义。
有时解析成功后得到的不是对象,而是一整段带反斜杠的字符串。这通常表示 JSON 被序列化了两次。
重复编码的结果类似:
"{\"name\":\"Alice\",\"active\":true}"第一次解析得到字符串,第二次解析才得到对象。正确方案通常是在数据生产端只序列化一次,而不是让每个使用方都额外解析。修复前应确认接口契约:字段本来就要求保存原始 JSON 文本时,字符串形式可能是有意设计。
下面的 JSON 可能被解析器接受,却包含两个同名键:
{
"role": "user",
"role": "admin"
}许多解析器会保留最后一个值,但不同语言、库和安全组件的行为可能不同。攻击者甚至可能利用这种差异绕过校验。可靠做法是在数据进入系统时检测并拒绝重复键,再回到数据生产端消除冲突。
因为普通 JSON.parse 解析后已经丢失重复信息,仅检查解析结果可能发现不了问题。高风险数据应使用能够在解析阶段报告重复键的库。
JSON 语法本身允许很大的数字,但 JavaScript 的普通 Number 不能精确表示所有整数。超过 9007199254740991 的订单号、雪花 ID 或数据库主键可能在解析后被改变。
风险示例:
{
"userId": 9007199254740993
}更安全的传输方式是把标识符写成字符串:
{
"userId": "9007199254740993"
}如果字段需要数学计算,应在生产端和消费端共同约定高精度数字方案。仅把已经丢失精度的结果重新转成字符串,无法恢复原始数字。
遇到无法解析的 JSON,可以按以下顺序处理:
JSON.parse 成功。对于支付、权限、医疗、审计或数据库迁移数据,不应在无人确认时自动修改。工具适合修复明确的语法问题,但不能猜测缺失值或业务含义。
大多数 JSON 解析错误来自双引号、逗号、括号、转义字符和非标准值。最快的办法不是反复试错,而是保留原文、从第一个错误开始、逐步修复并重新验证。
语法通过之后还要继续检查重复键、大整数、数据类型和字段含义。如果需要处理接近 JSON 的输入,可以先使用 JSON 修复工具,再用 JSON 验证器 和 JSON Diff 完成独立复核。
致力于为开发者提供最佳的 JSON 处理工具
更多文章即将发布...
返回博客关于跟进更新、选题方向与互动反馈。
收藏本博客列表页,并在首页与工具聚合页留意指南入口。阅读文章无需注册或邮件订阅。
围绕 JSON 校验、格式化、转换与调试流程,以及 JSON Work 工具更新,与在线工具的本地能力一一对应。
可以。请通过关于页的联系方式或 GitHub 反馈;我们会优先安排贴近真实开发场景的教程。