JSON 修复工具 - 在线修复无效 JSON 格式
JSON Repair Tool
Runs entirely in your browser. Nothing is uploaded.
功能介绍
JSON 修复是指在不改变原始数据的前提下，按照 RFC 8259 定义的语法规则，把格式错误的 JSON 机械地纠正为合法 JSON。规范本身是刻意严格的，解析器会逐条校验，而实际导致失败的规则其实很集中。第一，闭合的括号和方括号前面不能出现逗号——这个写法在很多编程语言里是合法的，也是手写 JSON 最常见的错误。第二，键和字符串值必须用双引号包裹，单引号和裸标识符都会被拒绝。第三，JSON 根本没有注释语法，但很多人因为在 JavaScript 里接触 JSON，习惯性地写下 // 和 /* */，这些会被当作非法字符。第四，对象的每个成员和数组的每个元素之间都要有逗号，漏掉一个之后报错位置会一路飘到后面，看起来完全没问题的那一行，这也是新手最常有的困惑来源。第五，字符串里不能出现裸的换行、回车和制表符，必须写成 \n、\r 和 \t，否则整段字符串会提前结束，后面的内容会被误当成新的语句。第六，整个文档必须从头到尾完整，所以被缓冲区截断的报文不管怎么转义都救不回来。修复工具和校验工具的区别在于发现错误之后做什么：校验工具只报错然后停下，修复工具则执行有针对性的、可逆的改动——删掉后面只剩空白和闭合符号的那个逗号，把单引号字符串转成双引号，在不破坏字符串边界的前提下去掉注释，再把裸控制字符转义掉，最后重新写回去。需要特别注意，这套逻辑必须在字符串边界之外工作，否则一个网址里的 // 或者字符串里恰好出现的 /* 会被误当成注释而被删掉，那属于损坏数据而不是修复。关键的设计约束是修复必须保守。一个为了能解析就悄悄删数据的工具，比没有工具更糟糕，因为它把一个响亮的失败变成了安静的损坏：你会以为数据没问题，实际上关键字段已经没了。所以这里的原则是只改动确定错误的部分，保留原文供你对比，并真正跑一次严格解析来确认成功。如果输入损坏到必须靠猜才能解析，工具会原样返回并明确说明它修不了，而不是给出一个似是而非的结果。
使用方法
- 在浏览器中打开 JSON 修复工具，全程本地运行，你粘贴的内容不会被上传或保存。
- 把出问题的 JSON 粘贴进输入框。常见来源是解析失败的接口响应、被格式化工具拒绝的配置文件，或者从日志窗口里复制出来的文本。
- 点击修复。工具会扫描文本，针对末尾逗号、单引号、未加引号的键、注释、缺失逗号和未转义控制字符执行针对性修复。
- 查看解析状态提示。显示 Valid 绿色说明严格的 RFC 8259 解析器已经接受修复结果，可以直接粘回代码里用。
- 对照修复清单，确认每一处改动，这样你能搞清楚问题出在哪，修正源头而不是反复踩同一个坑。
- 点复制按钮取走修复后的 JSON，粘贴到编辑器或终端里。如果文档是被截断的，修复无法找回丢失的字节，需要重新导出原始数据。
- 上线前在真实应用里跑一遍测试，因为修复只解决语法问题，补不回上游已经丢失的数值。
计算示例
输入: {"name":"Ada","role":"engineer",}
过程:
删除闭合括号前的多余逗号结果: {"name": "Ada", "role": "engineer"} — 可正常解析
输入: {name: 'Ada', tags: ['math','logic'],}
过程:
给裸键加引号、单引号转双引号、去掉末尾逗号结果: {"name": "Ada", "tags": ["math", "logic"]} — 可正常解析
输入: { // 用户记录 "id": 7, "note": "第一行 第二行" }
过程:
剔除 // 注释、转义字符串内的裸换行结果: {
"id": 7,
"note": "第一行\n第二行"
} — 可正常解析
相关搜索
相关搜索：json修复工具, json格式修复, 修复无效json, json在线修复, json语法错误, json解析错误。
json修复工具json格式修复修复无效jsonjson在线修复json语法错误json解析错误json末尾多余逗号json单引号修复json注释移除json缺少逗号json未转义字符损坏的jsonjson错误修复器json合法化json美化工具json转义处理离线json修复客户端json工具json校验与修复json修复api
常见问题
这个工具到底能修复哪些 JSON 错误？
工具处理的是导致绝大多数解析失败的语法缺陷：闭合括号前的末尾多余逗号、用单引号代替双引号、对象键没有加引号、JSON 里残留的 JavaScript 行注释和块注释、对象成员或数组元素之间缺失的逗号、字符串里未转义的换行制表符以及其他控制字符，以及最后一个闭合符号之后的冗余内容。每一项都是针对性改写，而不是整篇重新生成。被截断或内容本身已损坏的文档无法修复，因为丢失的字节已经不在你提供的文本里，工具会明确标为无法修复，而不是去猜测你的数据。
为什么我的 JSON 报错位置指向的那一行看起来完全没问题？
因为解析器是在它能成功理解的最后一个位置才失败，那个位置往往远在真正的错误之后。对象中间漏一个逗号，解析器会继续往下读，把下一个键当成字符串值，于是报错的行列号就飘到了后面某一处本身完全合法的代码上。这也是新手最常有的困惑来源，总以为自己看错了行。正确做法是从报错位置往回看，逐个检查成员之间的分隔符。用这个修复工具跑一遍能快速定位，因为工具会把级联错误消掉，只留下那一处真正畸形的结构。
把生产环境的数据粘贴到在线 JSON 修复工具里安全吗？
用这个工具是安全的，因为修复完全在你的浏览器里由本地 JavaScript 完成。文本由已经下载到你机器上运行的代码处理，不会经过网络、不会写进服务端日志，也就无法被站点所有者截获。这一点听起来平常，实际很关键：出问题的报文经常是包含客户资料、鉴权头、回调密钥或完整堆栈的接口响应，不少在线校验工具其实会悄悄记录你粘贴的内容。使用任何工具前都请确认它明确声明了客户端处理，并优先选择无需注册、无需上传的工具。
修复会不会改变我数据的含义？
不会，前提是工具足够保守，而这正是本实现的约束。修复只会改动那些在合法 JSON 中不可能出现的构造：闭合括号前的逗号被删除，单引号字符串重新加引号并转义其中的双引号，注释被剔除，缺失的分隔符被补上，裸控制字符被转义。没有任何键名被重命名，没有数值被重新解释，除去无意义的空白外格式保持原样。由于每一步改动都可以手工反推，你可以对照修复清单确认结果依然是你想要的数据。如果输入损坏到必须靠猜才能解析，工具会原样返回并明确说明。
为什么我用文本编辑器改完之后 JSON 就坏了？
绝大多数原因是人为和机械的，并不存在什么刁钻问题。文字处理器替换了引号，粘进来的是弯引号而不是直引号；自动缩进在对象最后一项后面补了空白加逗号；全局替换把某个值改成了带未转义引号或裸换行的内容；直接把 YAML 或 JavaScript 对象粘进 .json 文件，带进来注释和单引号；一次传输被截断，文档停在了结构中间。这些文件用眼睛看完全正确，严格解析器却会当场拒绝，而这正是这个工具存在的意义。
显示合法就代表我的接口会接受这份数据吗？
不代表。合法 JSON 只意味着文本满足语法规则，解析器能无错误地读取。至于这份文档对你的应用是否正确，是另一个问题，语法修复回答不了。字段名仍需匹配你的 schema，数值仍需在有效区间内，必填属性不能缺失，嵌套结构也要符合服务端预期。一份文档可能完美解析，却仍然被严格的接口校验拒绝。所以请把绿色的 Valid 状态理解为已经消除了解析错误，之后再用你自己的 schema 校验或测试用例验证一遍。