JSON Swiss 标志

JSON Swiss

JSON 修复工具与无效 JSON 恢复助手

损坏的 JSON 输入

1

已修复的 JSON 输出

设置

JSON 修复如何工作

当您输入无效 JSON 时，系统会按顺序自动尝试以下方法：

1
JSONRepair 库
快速、准确地修复大多数常见问题
2
基础模式匹配
处理简单语法错误
3
AI 提供商
用于复杂情况的 AI 等

开始修复 JSON

输入损坏的 JSON，或点击“导入”从文件加载。

如何修复损坏的 JSON 并恢复可用结构

1直接导入原始损坏 JSON，不要先手工大改2先观察本地修复，再看是否升级到 AI 修复3检查修复结果是否“能解析”且“符合预期”4把修好的 JSON 继续送去校验、格式化和后续处理

repair 最适合放在 validator 之后、formatter 之前：先把损坏 JSON 粘进来，看看它能不能在本地直接修好；如果结构错误更复杂，再让 AI 帮你推断并恢复成可解析的 JSON，最后再继续校验、格式化和导出。

从破损文本到可解析 JSON

repair 的价值是先把“根本没法用”的 JSON 拉回到可继续处理的状态

很多损坏 JSON 不只是格式难看，而是根本无法被解析。repair 会优先修回一个标准 JSON 结构，让你有机会继续校验、格式化、对比和导出。

损坏输入
1
{
2
name: "Project X",
3
'id': 1024,
4
items: [
5
"A",
6
"B",
7
]
8
}
修复后
1
{
2
"name": "Project X",
3
"id": 1024,
4
"items": [
5
"A",
6
"B"
7
]
8
}

如果你不确定该先 repair 还是先 validator：当 JSON 已经连基本解析都做不到时，通常先 repair 更快。

3 个更贴近真实工作的 repair 示例

repair 的常见场景不是“教学示例里的少一个逗号”，而是各种历史系统、日志、配置和复制粘贴过程中留下的混乱 JSON。下面这 3 类最有代表性。

旧接口返回

键名没引号、单引号混用，快速恢复成标准 JSON

适合处理老系统、脚本工具或人工拼接返回值时留下的非标准 JSON 结构。

损坏的 JSON
1
{
2
orderId: 'SO-1024',
3
customer: {
4
name: 'Maeve'
5
}
6
}
已修复的 JSON
1
{
2
"orderId": "SO-1024",
3
"customer": {
4
"name": "Maeve"
5
}
6
}

这类问题通常本地修复就能解决，不必一开始就依赖 AI。

配置清洗

删掉尾随逗号和注释，让配置重新可解析

很多团队会把 JS 对象写法误当成 JSON 使用，直到某次部署或导入时报错才发现问题。

损坏的 JSON
1
{
2
"env": "prod",
3
"retry": 3, // 重试次数
4
"features": {
5
"betaCheckout": false,
6
}
7
}
已修复的 JSON
1
{
2
"env": "prod",
3
"retry": 3,
4
"features": {
5
"betaCheckout": false
6
}
7
}

repair 很适合把这种“差一点像 JSON”的配置拉回规范状态。

复杂日志

本地修不动时，再交给 AI 推断结构意图

当文本里同时存在截断、转义混乱和多处括号错误时，本地规则可能不够，这时 AI 修复更有价值。

损坏的 JSON
1
{"event":"checkout","user":{"id":42,"name":"Maeve"},"items":[{"sku":"A-1","qty":2},{"sku":"B-8","qty":1],"status":"paid"
已修复的 JSON
1
{
2
"event": "checkout",
3
"user": {
4
"id": 42,
5
"name": "Maeve"
6
},
7
"items": [
8
{
9
"sku": "A-1",
10
"qty": 2
11
},
12
{
13
"sku": "B-8",
14
"qty": 1
15
}
16
],
17
"status": "paid"
18
}

这类场景修完后一定要再过 validator，确认恢复的结构和业务预期一致。

  1. 01

    教程步骤

    步骤 1 – 直接导入原始损坏 JSON，不要先手工大改

    修复工具最需要的是原始上下文，而不是已经被你改到一半的半成品。尤其是日志截取、旧接口响应和配置片段，如果先手工乱删，往往会让自动修复更难判断结构意图。

    • 把无效 JSON 直接粘贴到输入区，适合日志片段、旧接口、缓存快照和手工编辑损坏的配置文件。
    • 如果内容在本地文件中，可以直接导入，而不用先在别的编辑器里尝试整理。
    • 碰到键名没引号、数组尾逗号、单引号、括号没闭合等问题时，先不要自己大面积替换，先交给 repair。
    • 如果你已经从 validator 确认有大量语法错误，直接切过来会比手动逐个改更快。
    • 保留最原始文本能让本地修复和 AI 修复都更容易识别真正的结构模式。
  2. 02

    教程步骤

    步骤 2 – 先观察本地修复，再看是否升级到 AI 修复

    并不是每次都会走 AI。多数常见 JSON 错误其实用本地规则就能快速修掉，所以这一步重点是理解 repair 的执行顺序，而不是默认把它当成“AI 重写工具”。

    • 系统会优先尝试 JSONRepair 和基础规则修复，先处理速度快、确定性高的问题。
    • 如果本地方法已经能恢复成有效 JSON，右侧会立即出现修复结果，不必额外等待 AI。
    • 只有在结构意图不明确、本地修复不足时，才会继续触发 AI 深度修复。
    • 进度提示可以帮助你判断当前是本地修、AI 修，还是已经进入结果校验阶段。
    • 如果输入过大，不适合 AI 修复，建议先按业务块拆分 JSON，再逐段处理。
  3. 03

    教程步骤

    步骤 3 – 检查修复结果是否“能解析”且“符合预期”

    repair 的输出不应该只看“现在能 parse 了没有”，还要看它是不是符合你真正要的业务结构。尤其在复杂对象、嵌套数组和半结构化日志场景里，这一步决定了自动修复是否真正可用。

    • 先确认右侧输出已经是有效 JSON，而不是只把错误字符删掉后留下一个不完整结构。
    • 再检查关键字段、数组层级和对象嵌套，确认自动修复没有把业务含义改偏。
    • 如果修复结果基本正确但还想再细调，可以直接“应用”回输入区继续手改。
    • 如果结果看起来仍不可信，建议回到 validator 或源数据重新对照，而不是盲目继续下游流程。
    • 对日志和配置场景，建议特别检查布尔值、数字字符串和日期字段是否保持原意。
  4. 04

    教程步骤

    步骤 4 – 把修好的 JSON 继续送去校验、格式化和后续处理

    修复完成后，真正高效的做法不是就此结束，而是立刻把这份干净 JSON 带入后续流程。repair 更像“恢复入口”，后面的 validator、formatter、table editor 和 schema generator 才负责不同阶段的精细处理。

    • 先复制或下载修复后的 JSON，保留一个可回溯的修复结果版本。
    • 如果你还不完全确定结构是否正确，下一步优先进入 validator 做复核。
    • 如果你想让结构更易读，再转到 formatter 做美化、压缩或排序键名。
    • 如果你需要按表格方式检查字段、批量改值或筛选数据，可以继续送到 table editor。
    • 如果修复后的 JSON 已经稳定，也可以直接拿去生成 Schema、类型定义或转换脚本。

一个更稳的 repair 工作流

1

先把最原始的损坏 JSON 导入 repair，不提前自己做大规模替换。

2

优先让本地修复跑一遍，能直接恢复时就先拿结果，不必强行走 AI。

3

结构复杂或修复失败时，再看是否需要拆分片段或升级到 AI 修复。

4

修完后先进入 validator 做复核，再根据场景去 formatter、table editor 或 Schema 工具。

5

如果结果要对外共享，保留下载版本会比只复制到剪贴板更容易追踪修复过程。

repair 最有价值的不是“帮你省掉一个逗号”，而是把原本无法继续处理的数据恢复成能进入正式工作流的 JSON 起点。

修复前后的实用提醒

如果 JSON 只是少量语法错误，repair 很快；如果内容本身被截断或字段缺失，自动修复只能恢复语法，不能凭空还原业务数据。
遇到特别大的 JSON，先按对象块或数组片段拆分，再送入 repair，成功率通常更高。
修完后别急着直接上线或入库，先过 validator，再决定是否需要 formatter 统一结构。
如果你需要按字段逐项确认修复结果，table editor 比直接盯着长 JSON 文本更省力。

相关 JSON 工具

  • 修复完成后，您可能还需要格式化、校验或转换数据。

校验 JSON

严格校验 JSON 是否符合规范，并定位具体错误位置。

格式化 JSON

支持美化与压缩，并提供高级缩进选项。

Schema 生成器

根据修复后的数据生成 JSON Schema，用于更稳健的校验。

JSON 转 TypeScript

将 JSON 直接转换为 TypeScript 接口或类型。

JSON 转表格

使用类似电子表格的界面可视化编辑修复后的 JSON。

常见问题

JSON 修复工具是怎么工作的？

这页会按层级依次尝试不同修复方法：先用 JSONRepair 库处理常见语法问题，再做基础规则修复；如果结构问题更复杂，才会继续调用 AI 修复能力。这样可以优先保证速度、本地处理比例和修复稳定性。

它能修哪些常见 JSON 问题？

常见可修复问题包括：键名缺少双引号、尾随逗号、数组或对象未闭合、单引号误用、逗号遗漏、转义不完整，以及部分轻度结构错乱的 JSON 片段。

什么时候会用到 AI 修复？

当本地修复无法确定结构意图，或者 JSON 已经破损到简单规则难以还原时，系统才会升级到 AI 修复。典型场景包括日志里截断的嵌套对象、混杂多层错误的旧配置，或半结构化文本中嵌着 JSON。

我的数据安全吗？

大多数常见修复都在浏览器本地完成，不会上传数据。只有在需要更复杂的 AI 修复时，相关 JSON 才会发送到 AI 提供商进行处理，而且不会被我们用于存储或训练。

AI 修复有大小限制吗？

有。为保证稳定性，AI 修复每次请求支持的输入大约为 ~18000 个字符。更大的 JSON 建议先拆分成更小片段，或者先尝试本地修复与基础清洗。

需要自己配置 API Key 吗？

不需要。默认情况下你不必准备任何 API Key，就可以直接使用本地修复能力；需要 AI 修复时，也会走我们已经接好的能力链路。

修复完成后还要不要再校验一次？

建议要。repair 的目标是把损坏 JSON 尽快恢复成可解析状态，而 validator 更适合做最终复核，确认语法、结构和风险提示都没有遗漏。

什么时候应该直接手动修，而不是继续点修复？

如果 JSON 本身是被截断、缺了大段业务字段，或者上下文语义只有你自己知道，那么自动修复只能帮你恢复语法，不一定能恢复真实业务意图。这种情况更适合结合 validator 的定位结果手动补全。