JSON文件创建时，中文字符乱码如何解决？

Question

在创建 JSON 文件时，中文字符乱码是高频问题，根源在于编码不一致：JSON 规范强制要求 UTF-8 编码，但若生成工具（如 Python `json.dump()` 未设 `ensure_ascii=False`）、编辑器（如 Notepad 默认 ANSI）、或文件保存时未显式指定 UTF-8（含 BOM 或无 BOM），均会导致中文被转义为 `\uXXXX` 或显示为“”。常见错误包括：用 `json.dumps(data)` 默认输出 ASCII 转义；用 Windows 记事本另存为“UTF-8”实为 UTF-8 with BOM，部分解析器兼容性差；HTTP 响应头缺失 `Content-Type: application/json; charset=utf-8`。解决方案三步到位：① 生成时强制 UTF-8 输出（Python 加 `ensure_ascii=False` + `encoding='utf-8'`）；② 保存文件选用 UTF-8 without BOM；③ 传输/读取端统一声明 UTF-8 字符集。验证方式：用 `file -i filename.json`（Linux/macOS）或 VS Code 底部编码栏确认。

Answer 1

```html

一、现象层：中文在 JSON 中“消失”或“变形”的典型表现

• JSON 文件中中文显示为 \u4f60\u597d 等 Unicode 转义序列（非可读）
• 用记事本打开显示为乱码（如 “涓枃”、“???？”），但 VS Code 显示正常
• 前端 fetch() 解析后字段值为空字符串或 undefined
• Postman 查看响应体时中文正常，但程序 JSON.parse() 报错 Unexpected token
• Python json.load(f) 抛出 UnicodeDecodeError: 'gbk' codec can't decode byte 0x80

二、机制层：JSON 编码规范与现实工具链的三重断裂

根据 RFC 8259 第 8.1 节，JSON 文本必须以 UTF-8 编码；但实际流程涉及三个独立编码决策点：

环节	默认行为	风险点
生成（Python json.dump）	ensure_ascii=True（强制转义所有非 ASCII）	中文被固化为 \uXXXX，丧失可读性与调试友好性
保存（Windows 记事本）	“UTF-8”选项 = UTF-8 with BOM（EF BB BF）	BOM 被 Node.js / Go / Rust 解析器视为非法首字节，触发解析失败
传输（HTTP 响应）	无显式 Content-Type 头	浏览器/客户端按 ISO-8859-1 或系统 locale 解码，导致双解码乱码

三、实践层：三步精准治理方案（附跨语言验证代码）

1. 生成端统一 UTF-8 输出：
   

   # ✅ 正确：显式声明 encoding + ensure_ascii=False
   import json
   data = {"姓名": "张三", "城市": "深圳"}
   with open("user.json", "w", encoding="utf-8") as f:
       json.dump(data, f, ensure_ascii=False, indent=2)

2. 保存端禁用 BOM：VS Code 设置 "files.encoding": "utf8" + "files.autoGuessEncoding": false；Sublime Text 保存时选 UTF-8（非 UTF-8 with BOM）
3. 传输/消费端显式声明：
   

   HTTP/1.1 200 OK
   Content-Type: application/json; charset=utf-8
   Content-Length: 42

四、验证层：多维度交叉确认编码真实性

单点验证易误判，需组合验证：

graph LR
  A[文件] --> B{file -i user.json}
  A --> C[VS Code 底部状态栏]
  A --> D[hexdump -C user.json | head -n1]
  B -->|UTF-8 text| E[通过]
  C -->|显示 “UTF-8” 且无 BOM 提示| E
  D -->|首字节非 EF BB BF| E
  D -->|首字节为 7B 7B...| F[确认无 BOM]

五、进阶层：长期工程化防控策略

• CI/CD 流水线加入编码检查脚本：grep -l $'\xEF\xBB\xBF' *.json || echo "BOM-free ✅"
• Python 项目配置 pyproject.toml 强制 [tool.black] skip-string-normalization = true 避免格式化破坏中文
• 前端构建时注入响应头：Webpack DevServer 的 headers: { 'Content-Type': 'application/json; charset=utf-8' }
• 建立团队《JSON 编码守则》：明确定义“生成→保存→传输→消费”全链路 UTF-8 without BOM 强约束
• 对遗留 ANSI/GBK JSON 批量转换：iconv -f gbk -t utf-8 legacy.json > fixed.json

六、延伸思考：为什么 UTF-8 without BOM 是黄金标准？

BOM（Byte Order Mark）本质是 Unicode 的历史妥协产物——它对 UTF-8 无意义（UTF-8 无字节序问题），却破坏了 POSIX 兼容性：
• Shell 脚本 #!/usr/bin/env python3 若被 BOM 前置，则解释器路径识别失败；
• Docker COPY 指令读取含 BOM 的 JSON 时，可能被误判为二进制文件而跳过处理；
• Kubernetes ConfigMap 挂载后，某些 Go 客户端库会将 BOM 视为非法 token。
因此，RFC 7159 明确指出：“JSON text exchanged between systems that are not part of a closed ecosystem SHOULD be encoded in UTF-8.” —— “SHOULD” 即隐含排除 BOM。

```