常见问题

#常见问题

可以在线格式化无效的 JSON 吗？

可以。当输入长得像 JSON、但用了单引号、尾随逗号、没加引号的键、注释或 Python 风格的值这类常见扩展写法时，用 Repair & Format。工具会先尝试把这些语法归一化，再格式化结果。用输出之前，请把所有改动都过一遍。

怎么格式化损坏的 JSON？

从仍然会失败的最小脱敏样本开始。修正它，把修复前后的文本对照一遍，再跑严格校验器。格式化只是解析成功之后结果的呈现方式；真正处理非法语法的是修复。

Unexpected token 是什么意思？

解析器在某个位置遇到了 JSON 语法不允许的字符。有用的线索是这个 token 和它的位置。单引号可能说明这是 JavaScript 风格的字符串，/ 可能是注释的开头，大写的 T 多半来自 Python 的 True。

可以把 JSON 转成 JavaScript 对象吗？

可以。文本一旦是严格 JSON，JSON.parse(jsonText) 就会返回对应的 JavaScript 值。不要用 eval 解析不可信数据。如果源头是带注释、裸键或表达式的 JavaScript 对象字面量，那你得先想清楚：是要在受控的构建步骤里执行这段源码，还是先把数据转成 JSON。

我的数据安全吗？

修复、校验、格式化和转换引擎都在你的浏览器里运行，不需要把粘贴的内容发送到 fixjson.org 的应用服务器。但页面本身仍然走常规托管，也可能启用分析统计，所以用任何网站之前，都请去掉机密信息和敏感的生产数据。这条边界的详细说明见隐私政策。

Repair 和 Validate 有什么区别？

Repair 拿一小部分常见的非 JSON 写法，尝试产出严格 JSON。Validate 不猜，它按 JSON 规则解析，并报告第一处错误的行号和列号。Repair 回答的是"这种常见写法能不能被归一化"，Validate 回答的是"现在它是严格 JSON 了吗"。

#一套靠谱的修复与校验流程

大多数格式化工具在第一次解析失败时就放弃了。JSON Fix 面向的是格式化之前的那一步 —— 载荷来自日志、手工改过的配置、Python 片段、JavaScript 对象字面量或 Markdown 回复，看着几乎是 JSON，却又差那么一点。

按这个顺序来：

1. 遮蔽凭据、个人数据和生产环境标识。
2. 条件允许的话，把输入裁到最小的、仍然会失败的文档。
3. 运行 Repair & Format。
4. 把修复后的字符串、数字、布尔值和 null 与原文逐一对照。
5. 对结果运行 Validate。
6. 拿校验通过的 JSON 对一遍应用的 schema 或 API 文档。

JSON Minify 要等文档校验通过、也复核过之后再用。单行适合放进环境变量或做紧凑示例，而调试和代码评审通常还是带缩进的 JSON 更好用。

#JSON 错误速查表

尾随逗号

紧挨在 } 或 ] 前面的逗号，在某些编程语言的字面量里合法，在 JSON 里不合法。把最后一个属性或数组元素后面的逗号删掉。

JSON 键缺少引号

每个对象键都必须是双引号字符串。把 { name: "Ada" } 改成 { "name": "Ada" }。给键加引号解决的是语法问题，但它不能证明 name 是你的 API 允许的字段。

单引号

JSON 字符串用双引号。把 'Ada' 改成 "Ada" 时，注意保留撇号，并对值内部本来就有的双引号做转义。

Unexpected token

这一类报错说明解析器在当前语法位置上遇到了不该出现的字符或单词。先看位置，再检查报出来的那个字符以及紧挨在它前面的结构 —— 更早的地方漏了引号或括号，会让后面一个本来合法的字符看起来像罪魁祸首。

Python 字面量

Python 用 True、False、None，JSON 用 true、false、null。Python 字典还允许元组和非字符串的键，这些在 JSON 里没有直接对应物。

注释

// 和 /* ... */ 注释出现在 JavaScript 和 JSONC 里，但它们不属于 JSON。如果某条注释承载着运维知识，请把它挪到文档里，而不是在修复过程中悄无声息地丢掉。

Markdown 代码围栏

文档和 AI 回复常常用 ````json` 围栏把示例包起来。那几个反引号描述的是 Markdown 代码块，不是 JSON 文档的一部分。

#各个工具的常见问题

JSON Fix —— 怎么修复无效的 JSON？

把脱敏样本粘进 JSON Fix，选 Repair & Format。修复流程会一次性处理它支持的语法模式，之后请复核并校验输出。

JSON Validate —— 校验和解析 JSON 有什么区别？

解析是从文本生成一个程序可用的值。语法校验只需要知道这次解析成功与否，所以可以把结果丢掉。这个 JSON 校验器还会把解析成功的结果格式化出来方便你检查；它不做 JSON Schema 校验。

JSON Viewer —— 为什么我的树是空的？

JSON 查看器需要一个能解析成功的值。严格解析失败后它会尝试修复流程，但含义模糊或损坏严重的文本，仍然需要手动修正。

JSON Diff —— 为什么排序过和没排序的版本被判定为相同？

JSON Diff 按键比较对象成员，并在逐行展示前对键排序。所以对象键顺序不构成变更，而数组顺序仍然算。

JSON to TypeScript —— 生成的类型会在运行时校验吗？

不会。JSON 转 TypeScript 是从一份样本推断接口的。TypeScript 的接口在运行时会被擦除，而且一份样本也不可能暴露所有可选字段和可能取值。请在信任边界上使用运行时校验器或 schema。

JSON Minify —— 压缩会改变值吗？

JSON Minify 会解析文档并在不加可选空白的情况下重新序列化。字符串内容仍然是数据，包括引号内部的空格。大整数要仔细检查，因为 JavaScript 的数字类型无法精确表示所有整数。

JSON Stringify —— 怎么解开双重编码的 JSON 字符串？

在 JSON Stringify 里用一次 Unstringify 取回内层文本。只有当取回的文本本身就是 JSON、而且你确实需要那一层嵌套值时，才做第二次解析。

JSON ⇄ CSV —— 嵌套对象是怎么表示的？

JSON 转 CSV 会把嵌套对象或数组序列化成紧凑 JSON，放进一个 CSV 单元格。这段文本之后可以再解析，但 CSV 没有标准的类型元数据，所以能否精确往返，仍然取决于接收程序怎么对待字符串、空单元格、数字、布尔和 null。

JSON ⇄ XML —— 怎么让某个值变成 XML 属性？

给键名加 @ 前缀，比如 @id。当元素同时带有属性或子节点时，转换器把元素文本存在 #text 下，并把数组映射成重复的子元素。这些是本工具的约定，不是通用的 JSON/XML 标准。详见 JSON 转 XML。

YAML —— 为什么我的 YAML 解析失败？

缩进是常见原因，但不是唯一原因。用制表符缩进、同级项没对齐、写坏的流式集合、指示字符没加引号，都会失败。YAML 工具会报出解析器给的行号和列号。

Base64 —— Base64 和 Base64url 有什么区别？

标准 Base64 使用 + 和 /，通常保留 = 补齐。Base64url 换成 - 和 _，而 JWT 这类用法通常省略补齐。两种形式都不是加密。详见 Base64。

URL Decode —— 为什么我的 + 没解码成空格？

URL 解码工具遵循 decodeURIComponent，其中 + 仍然是加号。HTML 表单编码另有一套约定，用 + 表示空格。只有在确定输入是表单编码时，才去替换 +。

JWT Decode —— 它会验证签名吗？

不会。JWT 解码只读取头部和载荷，不检查签名。请在消费 token 的系统里验证：用成熟的库、可信的密钥、预期的算法，并检查签发方、受众和与时间相关的声明。

#按报错信息找对应的文章

如果你手上有确切的报错字符串，直接跳到对应的文章：

• "Unexpected token < in JSON at position 0" → 你的 fetch 返回了 HTML
• "Unexpected token u in JSON at position 0" → 你解析了 undefined
• "Unexpected token o in JSON at position 1" → 对象被转成了 [object Object]
• "Unexpected end of JSON input" → 被截断或未闭合的结构
• "Unexpected non-whitespace character after JSON data" → 完整值后面还有多余数据（是 NDJSON 吗？）
• "Unterminated string in JSON" → 字符串开了头却没结尾
• "Bad escaped character in JSON" → 非法的反斜杠转义，比如 \x 或没转义的 Windows 路径
• "Bad control character in string literal in JSON" → 字符串里混进了原始的制表符、换行或控制字节
• "Expected double-quoted property name…" → 尾随逗号
• "[object Object] is not valid JSON" → 解析之前对象已经被字符串化了
• 不确定是哪个？ → 从总览开始：如何修复 JSON.parse 的 Unexpected Token 错误

#本地处理是怎么保护隐私的

修复、校验、格式化、压缩和复制操作都在浏览器标签页里运行，处理你的 JSON 不需要一个上传接口。对 API 样本、Webhook 请求体、配置片段和调试输出来说，这是一条不错的边界。

但它不能替代数据最小化。托管和分析统计在页面周围照常运作（详见隐私政策），浏览器扩展和远程资源也不在工具的控制范围内。调试之前，请把凭据、访问令牌、客户记录和生产环境的机密换成安全的占位符。

#JSON 是什么，以及它为什么这么严格

JSON 是 JavaScript Object Notation 的缩写，但它是一种与语言无关的数据格式。正因为语法足够小，浏览器、服务端、数据库、消息队列和命令行工具才能交换同一份文档，而不必执行任何函数、构造器、注释或表达式。

代价是：JavaScript 对象字面量、Python 字典、TypeScript 配置或 Markdown 示例看着都很眼熟，却未必是合法 JSON。修复能抹平典型的差异，但它推断不出缺失的业务含义。

#使用修复后的 JSON 之前

修复成功只意味着工具产出了可解析的 JSON。用它之前，请确认必填字段、未知的键、值类型、数组长度、日期格式、允许的取值、null 的处理方式，以及标识符是否应该保持字符串 —— 这些都对了才行。

如果这份载荷会影响权限、计费、删除或用户可见的行为，请拿一份已知正确的样本或 schema 逐项核对。先校验语法，再校验业务约定。