August 16, 202620 min read

在线修复 JSON：修复规则、JavaScript 流程、大模型输出与隐私

安全地修复非法 JSON，搞清楚在线修复工具到底改了什么，在 JavaScript 里加一条显式的修复路径，清理大模型输出，并把敏感载荷留在浏览器或你自己的机器上。

JSON.parse() 的严格是有意为之的。它只认 JSON —— 不认 JavaScript 对象字面量，不认 Python 字典，不认被代码块包起来的 ChatGPT 回答，也不认那份复制了一半、末尾还挂着个逗号的 API 响应。

对生产代码来说，这种严格是好事：坏输入会响亮地失败。但当你只是盯着一段粘贴过来的载荷、想看清对象结构时，它就很烦人了。在线 JSON 修复工具解决的就是这一段：把常见的"近似 JSON"变成合法 JSON，让你能查看、复制，或者送进更严格的校验器。

关键在于边界。好的修复工具修的是语法。它不该假装自己懂你的业务规则、你的 API schema，或者 "price": "19.99" 本来是不是应该写成数字。

简短版

当输入已经很接近合法 JSON、而且错误是机械性的，就用在线修复工具：

坏掉的写法	修复流程通常会怎么做
`{ name: 'Ada', }`	给键加引号，把单引号转成双引号，删掉尾随逗号
`{ "active": True, "deleted": False }`	把 Python 布尔值转成 JSON 的 `true` 和 `false`
`{ "value": undefined }`	把 `undefined` 转成 `null`，因为 JSON 没有 undefined
`// 注释` 或 `/* 注释 */`	删掉字符串之外的注释
载荷外面裹着 Markdown 代码围栏	从完整的围栏块里把 JSON 提取出来
`{ "items": [1, 2, 3`	补上数组和对象的闭合，让你能查看这份不完整的值

修完之后、用之前，务必把输出读一遍。修复工具可能给出一个语法上合法、语义上却不对的结果。

在线 JSON 修复工具是什么

在线 JSON 修复工具是一个浏览器工具：接收非法的、类 JSON 的文本，跑一个修复解析器，输出严格的 JSON 文本。它和格式化、校验不是一回事：

工具	最适合	输出
JSON 校验器	确认载荷符合 JSON 语法	通过/失败，外加错误位置
JSON 格式化器	美化已经合法的 JSON	同样的数据，更好读
JSON 修复器	抢救常见的 JSON 语法错误	修复后的值，重新序列化成严格 JSON

实际工作中，这三样往往在同一个流程里都会用到：

把坏掉的输入粘进 JSON Fix。
执行修复和格式化。
复核清理后的输出。
在保存、提交或交给代码之前，严格校验结果。

最后这步校验很重要。修复只是一层便利，不是数据质量的保证。

为什么基于正则的 JSON 修复会翻车

最朴素的修法是堆一坨正则：

text
  .replace(/,\s*}/g, '}')
  .replace(/,\s*]/g, ']')
  .replace(/'/g, '"');

小 demo 上能跑，一碰真实数据就咬人。

举个例子，一个大而化之的注释剥离正则会毁掉 URL：

{
  "callback": "https://api.example.com/v1/events"
}

https:// 里的 // 不是 JSON 注释，它是字符串值的一部分。真正的修复工具必须知道自己此刻在字符串里、在对象键里、在数组里，还是在两个值之间。

所以好工具用的是修复解析器，而不是无脑的文本替换。

JSON Fix 是怎么修一份坏载荷的

JSON Fix 的修复流程"无聊"得恰到好处。工具在浏览器里运行，把输入解析成一个 JavaScript 值，再用 JSON.stringify() 把这个值序列化回来。

实际步骤是：

剥掉完整的 Markdown 围栏。 如果粘贴的整段输入就是一个无标签围栏块，或者标签是 json、javascript、js 的围栏块，解析前会先把围栏去掉。
宽松地做词法分析。 词法器认识严格 JSON 的 token，也认识常见的非 JSON token：单引号字符串、标识符、注释、True、False、None、undefined、+12、0xFF。
带恢复地解析。 解析器仍然遵循 JSON 语法，但在修复模式下，它可以跳过多余的逗号、接受不加引号的键、容忍缺失的逗号，并在输入结束时闭合未完成的对象或数组。
归一化这个值。 修复后的值用 JSON.stringify(value, null, 2) 打印出来；你也可以选择 4 空格缩进。
返回严格 JSON。 输出里是双引号字符串、小写布尔值、null，没有注释、没有尾随逗号、没有 Markdown 外壳。

关键细节是：修复解析器处理的是结构，而不只是字符。它能删掉属性之间的注释，同时不碰字符串内部那个同样是 // 的序列。

真实世界里的修复案例

1. 把 JavaScript 对象字面量当 JSON 粘贴

这大概是最常见的修复场景：有人从测试文件、配置片段或浏览器控制台里拷了一个 JavaScript 对象，然后粘进 JSON 解析器。

{
  name: 'Ada Lovelace',
  active: True,
  skills: ['math', 'notes',],
}

修复后的 JSON 是：

{
  "name": "Ada Lovelace",
  "active": true,
  "skills": [
    "math",
    "notes"
  ]
}

一次性做了好几处修复：

name、active、skills 变成了带引号的属性名。
单引号字符串变成了 JSON 字符串。
True 变成了 true。
"notes" 后面的尾随逗号被删掉了。

这类修复是安全的，因为意图一目了然 —— 输入描述的本来就是同一个对象，只是用错了语法。

2. 配置文件里的注释

JSON 不允许注释。而很多"长得像 JSON 但不是 JSON"的配置格式都允许：JSONC、JavaScript 配置、VS Code 设置、文档里手写的示例。

{
  "env": "staging",
  // QA 测试登录流程期间临时开启。
  "debug": true,
  "retries": 3,
}

修复输出：

{
  "env": "staging",
  "debug": true,
  "retries": 3
}

调试或转换时这通常没问题。但对一份要提交进仓库的配置文件来说，更好的做法是选对文件格式：不允许注释就用严格的 .json，注释是工作流一部分就用 .jsonc 或 .js。

3. 被代码围栏包住的大模型输出

AI 工具通常把 JSON 放在 Markdown 里返回，这在聊天场景里很方便 —— 但围栏本身并不属于 JSON 文档。

```json
{
  "title": "Incident summary",
  "severity": "medium",
}
```

修复输出：

{
  "title": "Incident summary",
  "severity": "medium"
}

有个注意点：请只复制 JSON 块本身。如果回复在围栏前面还有一段说明文字（比如"这是你要的 JSON："），先把那段文字删掉，或者只粘围栏里的内容。修复解析器可以忽略完整值后面的多余文本，但前面的散文是有歧义的，不该被当作数据来解析。

针对大模型的生产流程在本文后面还会详细讲。

4. 复制了一半的截断 JSON

有时候载荷本身没错，只是你没复制全。

{
  "users": [
    { "id": 1, "name": "Ada" },
    { "id": 2, "name": "Grace"

修复解析器能把打开的对象和数组闭合掉：

{
  "users": [
    {
      "id": 1,
      "name": "Ada"
    },
    {
      "id": 2,
      "name": "Grace"
    }
  ]
}

这方便查看，但它证明不了原始数据是完整的。如果载荷来自 API，请回到源头重新取一份。

5. 来自 JavaScript 的非 JSON 数字

JSON 的数字比 JavaScript 的数字字面量更严格：不能有前导正号，也不能用十六进制。

{
  "offset": +12,
  "mask": 0xFF
}

修复输出：

{
  "offset": 12,
  "mask": 255
}

这个转换在语法上很合理，但请复核一下。如果原文本意是保留 "0xFF" 这个写法、而不是数值 255，修复工具是无从得知的。

在线 JSON 修复工具不该替你掩盖什么

有些输入应该让你慢下来。

重复的键

对象里同一个键出现两次时，JSON 解析器通常保留最后那个值：

{
  "role": "reader",
  "role": "admin"
}

这在语法上是合法 JSON，但数据本身很可疑。修复工具能把解析后的对象序列化出来，但更早的那个值就丢了。如果重复键对你的流程很重要，请换用更严格的校验器，或者一个会把重复键标出来的、支持 schema 的解析器。

缺失的业务字段

这段在语法上可以修：

{ "id": 42, "email":

但修出来的可能是：

{
  "id": 42,
  "email": null
}

这不意味着 null 是一个正确的邮箱值。它只意味着解析器读到了输入末尾，需要一个占位符才能把对象闭合。

字符串里的非法转义

这是修复变得微妙的地方：

{ "path": "C:\new\reports\q1.json" }

具体字符不同，解析器可能把 \n 当成换行转义，把未知转义当成可恢复的文本 —— 输出未必能保住你想要的那个路径。对路径和正则表达式来说，更稳妥的做法是自己把反斜杠转义好：

{
  "path": "C:\\new\\reports\\q1.json"
}

如果报错提到非法转义序列，请先检查反斜杠和源语言，再决定要不要接受自动修复。JSON 解析错误指南详细讲了转义和字符串相关的失败。

NDJSON 或多份 JSON 文档

这不是一份 JSON 文档：

{ "id": 1 }
{ "id": 2 }

它是换行分隔的 JSON，或者说是两个分开的 JSON 值。修复工具可能只返回第一个完整值，忽略其余的。这不是 bug，而是一个信号：你需要 NDJSON 解析器，或者把这些记录包进一个数组。

什么时候该用在线 JSON 修复工具

场景	合适吗？	原因
调试一次性的 API 载荷	合适	你需要快速拿到一个能读的对象
清理大模型生成的 JSON	合适	围栏、尾随逗号、注释、Python 字面量都很常见
把 JS 对象字面量转成 JSON	合适	引号风格和键加引号都是机械性的
修复生产环境的数据摄取	不合适	应该在流水线里放一个经过测试的修复库，并记录每一次修复
处理受监管数据	小心	用纯本地/浏览器工具，或者跑离线脚本
强制执行 API 约定	不合适	该用严格解析加 JSON Schema 校验

我用的判断标准是：人造的混乱可以修，机器之间的约定违规就该拒绝 —— 除非你是有意支持修复的。

隐私：JSON 会离开你的浏览器吗

在把 token、Webhook 载荷、客户导出数据或内部配置粘进任何在线工具之前，这是第一个该问自己的问题。

有些格式化工具会把你的输入 POST 到服务器。机密就可能顺着应用日志、分析程序、崩溃报告、CDN 缓存或请求抓包泄漏出去。它看起来像个本地编辑器，实际上仍然把你的数据发走了。

JSON Fix 的修复在你的浏览器里运行。编辑器调用本地的修复函数、格式化这个值、更新输出面板。这一点你可以自己验证：

打开 DevTools。
切到 Network 标签页。
粘贴一小段测试载荷。
点 Repair & Format。
确认没有任何包含你 JSON 的请求发出去。

浏览器本地处理降低了风险，但它并不免除你谨慎对待机密的责任。数据高度敏感的话，请用公司批准的本地工具，或者在可信机器上跑离线脚本。

本文后面还有一份隐私核查清单，可以在分享载荷之前用来确认本地处理和脱敏是否到位。

更安全的修复流程

当输出很重要时，按这份清单来：

保留原始输入。 在你搞清楚改动之前，别覆盖掉那份坏掉的载荷。
只修一次。 别对已经修过的输出反复修复，那会让"到底改了什么"更难说清。
复核可疑的转换。 重点关注 undefined -> null、0xFF -> 255、缺失的值，以及未闭合的字符串。
严格校验。 修复流程跑完后，把结果送进严格校验器。
校验语义。 如果这份载荷要喂给 API，请拿 JSON Schema 或你的应用层约定核对一遍。
有条件就修源头。 修复工具很适合应急分诊，但持久的解决方案通常在那个产出坏 JSON 的生产方。

这就是"我让解析器不再报错"和"这份数据可以放心用"之间的区别。

在 JavaScript 里修复损坏的 JSON

在应用代码里，请把修复做成一条显式策略，而不是藏在每次 JSON.parse() 背后的兜底。先严格解析；只有调用方允许时才修复；修完再对修复后的文本严格解析一次。

import { jsonrepair } from 'jsonrepair';

function parseJson(text, { allowRepair = false } = {}) {
  if (typeof text !== 'string') {
    return { ok: false, kind: 'not_string' };
  }

  try {
    return { ok: true, repaired: false, value: JSON.parse(text) };
  } catch (parseError) {
    if (!allowRepair) {
      return { ok: false, kind: 'invalid_json', error: parseError.message };
    }

    try {
      const repairedText = jsonrepair(text);
      return {
        ok: true,
        repaired: true,
        repairedText,
        value: JSON.parse(repairedText),
      };
    } catch (repairError) {
      return {
        ok: false,
        kind: 'repair_failed',
        parseError: parseError.message,
        repairError: repairError.message,
      };
    }
  }
}

决定权归调用方：

const pastedExample = parseJson(editorText, { allowRepair: true });
const paymentCommand = parseJson(requestBody, { allowRepair: false });

把 repaired 标志返回出去，这样界面可以展示改动过的文本，日志也能区分"本来就合法的 JSON"和"被抢救回来的输入"。绝对不要拿 eval() 或 new Function() 当修复捷径 —— 它们执行的是代码，不是在解析数据。

对 fetch() 来说，返回 HTML、空的 204 或被截断的响应体，属于传输或约定层面的问题。请按 JSON 解析错误里说的那样检查状态码、内容类型和原始文本；别把一个 API 错误页丢进修复解析器。

修复大模型的 JSON 输出，但不要信任它

模型输出常常带 Markdown 围栏、开场白、注释、Python 字面量或尾随逗号。请把清理和校验当成两个独立的步骤：

优先使用服务商提供的 schema 约束或结构化输出功能。
尽可能把完整响应缓冲齐 —— 一个还在流式传输中的响应，按定义就是不完整的 JSON。
提取你想要的那个围栏块或那个值。不要在多个候选对象之间瞎猜。
先严格解析；策略允许的话，再修语法。
对修复后的文本再严格解析一次。
用 JSON Schema 或应用校验器校验必填字段、类型、枚举和上限。
涉及财务、权限、删除、迁移或其他会改变状态的操作时，要么拒绝，要么要求人工复核。

代码里的边界长这样：

import { jsonrepair } from 'jsonrepair';
import { z } from 'zod';

const Result = z.object({
  title: z.string(),
  severity: z.enum(['low', 'medium', 'high']),
});

const repairedText = jsonrepair(rawModelOutput);
const parsed = JSON.parse(repairedText);
const result = Result.parse(parsed);

修复能纠正语法，但它变不出缺失的事实，也证明不了编造的内容是真的。至于流式界面预览，增量解析器可以把完整的前缀先展示出来，但流结束之后，最终的值仍然需要一次严格解析和 schema 校验。

把敏感 JSON 留在本地

生产载荷里常常带着 bearer token、Cookie、JWT、Webhook 签名、客户记录、数据库连接串、内网域名或链路追踪数据。当处理发生在浏览器本地时，操作是在页面内存里完成的，不会有任何携带你输入的请求发往格式化或修复服务器。

用一个无害的探针来验证这个说法：

打开 DevTools，切到 Network。
清空已有条目，勾上 Preserve log。
粘贴一个独一无二的假值，比如 {"probe":"local-test-4937"}。
执行修复、格式化、校验或 diff。
在请求 URL 和请求体里搜索 local-test-4937。
也可以在页面加载完成后断网，确认工具依然能用。

浏览器本地更安全，但页面脚本、扩展、截图、工单和复制出去的输出，仍然都在暴露路径上。受监管或高度敏感的数据，请用内部批准的工具或本地命令行。

python3 -m json.tool response.json
jq . response.json
jq 'del(.headers.authorization, .cookie, .password)' response.json

如果你已经把一个有效的机密粘进了未经批准的服务端工具，就当它已经泄漏：轮换或吊销它，尽可能删掉分享链接和工单里复制的内容，并按你们的事件响应流程处理。载荷被格式化成什么样，丝毫不会降低这个机密的可用性。

常见问题

怎么在线修复 JSON？

把坏掉的 JSON 粘进 JSON Fix 这类浏览器端修复工具，执行 Repair & Format，然后复核输出。它能处理常见语法错误：尾随逗号、单引号、没加引号的键、注释、Python 字面量、undefined、Markdown 代码围栏，以及未闭合的对象或数组。

在线 JSON 修复会改动我的数据吗？

可能会。像"单引号转双引号"这种看着安全的修复通常能保住原意，但 undefined 转 null、0xFF 转 255、给截断的对象补闭合，都属于尽力而为的猜测。请把输出当作"修好了语法"，而不是"业务数据已核实"。

把敏感 JSON 粘进在线修复工具安全吗？

只有当这个工具在你的浏览器本地运行时才谈得上安全，而且即便如此，你也仍然要遵守自己的数据处理规范。JSON Fix 的修复和格式化都在浏览器里完成，你可以在 DevTools 里验证：点 Repair & Format 不会把你粘贴的 JSON 发到服务器。

JSON 修复器和校验器有什么区别？

校验器告诉你这段文本是不是严格 JSON，以及解析在哪里失败。修复器则尝试从常见错误中恢复，返回一个合法的 JSON 值。用修复器清理"近似 JSON"，然后用校验确认结果确实是严格 JSON。

在线修复工具能修 AI 生成的 JSON 吗？

如果问题出在语法上就可以：Markdown 围栏、尾随逗号、注释、单引号、没加引号的键，或者 Python 风格的 True / False / None。但如果模型漏了必填字段或者编了值，修复工具是不知道正确答案的。

在 JavaScript 里怎么修复损坏的 JSON？

先试 JSON.parse()。对于明确允许修复的数据源，把文本交给 jsonrepair 这类结构化修复库，对返回的文本做严格解析，校验得到的值，并把"发生过修复"这件事报告出来。

fixjson.org 会上传我粘贴的 JSON 吗？

修复是设计成在浏览器里运行的。你可以用一个独特的假载荷在 DevTools 里验证，确认没有任何 Fetch/XHR 请求包含这个值。受监管或特别敏感的数据，请使用批准过的本地工具。

如果我已经把 API key 或 token 粘进在线工具了怎么办？

轮换或吊销它，而不是去相信"我们没存"这种承诺。同时尽可能从工单或聊天里删掉分享链接和复制过去的载荷，并遵循你所在组织的事件响应流程。

现在就在线修复 JSON

需要一次快速的、浏览器本地的修复时，把载荷粘进 JSON Fix。它最适合：

从日志、文档、聊天或测试文件里拷来的坏 JSON。
长得像 JSON 但被 Markdown 包起来的大模型输出。
需要输出严格 JSON 的 JavaScript 风格对象字面量。
你想在写真正的修复代码之前先看一眼的 API 响应。

参考资料

RFC 8259：JavaScript 对象表示法数据交换格式
MDN: JSON.parse()
MDN: JSON.stringify()
jsonrepair —— JavaScript 的开源 JSON 修复解析器
json-repair —— Python 的 JSON 修复库
Zod —— JavaScript 与 TypeScript 值的 schema 校验。

最后校订于 2026 年 8 月。

#简短版

#在线 JSON 修复工具是什么

#为什么基于正则的 JSON 修复会翻车

#JSON Fix 是怎么修一份坏载荷的

#真实世界里的修复案例

#1. 把 JavaScript 对象字面量当 JSON 粘贴

#2. 配置文件里的注释

#3. 被代码围栏包住的大模型输出

#4. 复制了一半的截断 JSON

#5. 来自 JavaScript 的非 JSON 数字

#在线 JSON 修复工具不该替你掩盖什么

#重复的键

#缺失的业务字段

#字符串里的非法转义

#NDJSON 或多份 JSON 文档

#什么时候该用在线 JSON 修复工具

#隐私：JSON 会离开你的浏览器吗

#更安全的修复流程

#在 JavaScript 里修复损坏的 JSON

#修复大模型的 JSON 输出，但不要信任它

#把敏感 JSON 留在本地

#常见问题

#怎么在线修复 JSON？

#在线 JSON 修复会改动我的数据吗？

#把敏感 JSON 粘进在线修复工具安全吗？

#JSON 修复器和校验器有什么区别？

#在线修复工具能修 AI 生成的 JSON 吗？

#在 JavaScript 里怎么修复损坏的 JSON？

#fixjson.org 会上传我粘贴的 JSON 吗？

#如果我已经把 API key 或 token 粘进在线工具了怎么办？

#现在就在线修复 JSON

#参考资料

简短版

在线 JSON 修复工具是什么

为什么基于正则的 JSON 修复会翻车

JSON Fix 是怎么修一份坏载荷的

真实世界里的修复案例

1. 把 JavaScript 对象字面量当 JSON 粘贴

2. 配置文件里的注释

3. 被代码围栏包住的大模型输出

4. 复制了一半的截断 JSON

5. 来自 JavaScript 的非 JSON 数字

在线 JSON 修复工具不该替你掩盖什么

重复的键

缺失的业务字段

字符串里的非法转义

NDJSON 或多份 JSON 文档

什么时候该用在线 JSON 修复工具

隐私：JSON 会离开你的浏览器吗

更安全的修复流程

在 JavaScript 里修复损坏的 JSON

修复大模型的 JSON 输出，但不要信任它

把敏感 JSON 留在本地

常见问题

怎么在线修复 JSON？

在线 JSON 修复会改动我的数据吗？

把敏感 JSON 粘进在线修复工具安全吗？

JSON 修复器和校验器有什么区别？

在线修复工具能修 AI 生成的 JSON 吗？

在 JavaScript 里怎么修复损坏的 JSON？

fixjson.org 会上传我粘贴的 JSON 吗？

如果我已经把 API key 或 token 粘进在线工具了怎么办？

现在就在线修复 JSON

参考资料