为什么我的 JSON 数据显示乱码？关于 Unicode 编码的解决方案

JSON 与 Unicode 的关系

JSON 字符串直接支持 Unicode 字符（如中文、emoji），也支持 \uXXXX 形式的转义。

两种写法等价："你好" 与 "\u4f60\u597d" 解析后相同。

跨系统传输时 RFC 8259 要求使用 UTF-8；本地文件也建议统一 UTF-8 保存。

{
  "greeting": "你好",
  "escaped": "\u4f60\u597d",
  "emoji": "🎉"
}

常见乱码现象与原因

中文变成 ??? 或 �：读取时用 Latin-1/GBK 解码了 UTF-8 字节。

接口正常但本地文件乱码：编辑器保存编码不是 UTF-8。

数据库里正常、导出后乱码：导出工具未指定 charset=UTF-8。

仅 emoji 异常：部分旧终端字体不支持，与 JSON 本身无关。

\u 转义：何时出现、如何阅读

部分库为 ASCII 安全会输出 \u 转义；解析后仍是正确 Unicode。

若希望在编辑器里直接看到中文，可在合法 JSON 上执行格式化，工具会保留或还原可读字符（取决于源文本）。

手动将乱码转回中文：确认字节序列是否正确，再统一为 UTF-8 解码。

HTTP 与 Content-Type

application/json 媒体类型在 IANA 注册中未定义 charset 参数；实际字节仍应是 UTF-8。

浏览器 response.json() 与 Node fetch 均按 UTF-8 解码 JSON 文本。

若响应头写了错误 charset，部分客户端可能被误导——优先修正服务端。

BOM 与隐藏字符

RFC 8259 禁止在网络传输的 JSON 开头加 BOM；解析器可以忽略 BOM，但不应依赖它。

本地 .json 文件建议保存为 UTF-8 无 BOM；从 Windows 记事本复制时要留意隐藏字符。

排查清单

1. 确认文件或响应实际字节为 UTF-8（hex 编辑器或 file 命令）。

2. 确认编辑器右下角编码为 UTF-8。

3. 用在线工具解析：若工具显示正常，问题在下游消费方。

4. 统一链路：生成 → 传输 → 存储 → 展示 全程 UTF-8。