JS格式化JSON后中文显示为Unicode编码怎么办

一、现象成因：为什么格式化后会出现 \uXXXX

许多开发者在调用 JSON.stringify() 后发现中文字符变成了类似 \u4e2d\u6587 的形式，往往会误以为是 JavaScript 本身缺乏中文支持或格式化参数配置错误。实际上，现代 ECMAScript 规范下的 JSON.stringify() 在处理合法的内存对象时，完全遵循 UTF-8 编码，对非 ASCII 范围的普通汉字直接按字符本身输出。

界面中出现 Unicode 编码，本质上是因为进入格式化环节的数据本身就是已经转义过的纯文本，或者发生了序列化混淆：

• 上游接口序列化时开启了 ASCII 保护：诸如 Python 的 json.dumps()（默认 ensure_ascii=True）或 PHP 的 json_encode()（默认未开启 JSON_UNESCAPED_UNICODE），在生成 JSON 响应时会将非 ASCII 字符转换为 \uXXXX 形式的纯 ASCII 字符串传给前端。
• 直接对“已经是 JSON 字符串”的数据执行 JSON.stringify：前端拿到接口返回的响应字符串后，如果未先将其解析为 JavaScript 对象，而是直接对其执行 JSON.stringify(str, null, 2)，就会导致原有的 \uXXXX 字符串被当成普通字符进行二次转义，反斜杠甚至可能变成 \\uXXXX。
• 文本展示组件未做转义解析：直接将带有 Unicode 序列的原生文本渲染在 <pre>、<textarea> 或控制台日志中，缺少了将其反解为字符的过程。

二、方案一：标准反序列化法（首选解决方案）

如果待处理的数据是一个语法完整的 JSON 字符串（例如从 API 接口获取的响应文本或读取的 .json 文件内容），最规范、最高效的做法是先使用 JSON.parse() 将其反序列化为内存中的 JavaScript 对象，然后再利用 JSON.stringify() 携带缩进参数输出。

JSON.parse() 规范原生支持识别 \uXXXX 转义序列，并会在解析为内存对象时，自动将其转换为对应的 UTF-16 字符。此后再次调用 JSON.stringify()，JavaScript 便会直接输出人类可读的汉字。

代码实现与完整示例

// 模拟上游返回的带有 Unicode 转义的原始 JSON 字符串
const rawJsonString = '{"id": 101, "name": "\\u5f20\\u4e09", "department": "\\u7814\\u53d1\\u4e2d\\u5fc3"}';

function formatJsonWithChinese(jsonStr) {
  try {
    // 步骤 1：解析字符串为对象，此过程自动将 \uXXXX 还原为中文内存字符
    const obj = JSON.parse(jsonStr);

    // 步骤 2：格式化输出，设置缩进为 2 个空格
    return JSON.stringify(obj, null, 2);
  } catch (error) {
    console.error("JSON 解析失败，请检查输入格式:", error);
    return jsonStr;
  }
}

// 执行格式化
const result = formatJsonWithChinese(rawJsonString);
console.log(result);

三、方案二：正则替换法（应对非严格 JSON 或文本片段）

在某些特殊场景中，你所面对的字符串并不是一段语法严密的完整 JSON（例如截断的日志文本、包含非法属性名的伪 JSON、或者由多种混合内容拼接而成的调试信息）。此时调用 JSON.parse() 会抛出语法解析异常，标准反序列化路线失效。

针对这种情况，可以通过正则表达式全局检索形如 \uXXXX 的四位十六进制子串，提取其十六进制码点数值，并通过 String.fromCharCode() 将其还原为对应字符。

通用正则解码函数

/**
 * 将字符串中所有 \uXXXX 形式的 Unicode 转义字符还原为对应汉字
 * @param {string} str 待转换的文本
 * @returns {string} 转换后的可读文本
 */
function decodeUnicodeString(str) {
  if (typeof str !== 'string') return str;

  // 匹配 \u 紧随 4 位 16 进制字符的序列
  return str.replace(/\\u([0-9a-fA-F]{4})/g, (match, hexGroup) => {
    // 将十六进制码点转换为十进制整数，再映射为具体字符
    return String.fromCharCode(parseInt(hexGroup, 16));
  });
}

// 测试包含 Unicode 编码的非完整片段
const logSnippet = '[WARN] 2026-11-01 用户(\\u674e\\u56db)在页面(\\u9996\\u9875)访问超时';
const readableLog = decodeUnicodeString(logSnippet);
console.log(readableLog);

四、特殊字符处理：Emoji 与大字符集（代理对问题）

常见的常规汉字码点均位于 Unicode 基本多文种平面（BMP，码点范围在 U+0000 到 U+FFFF 之间），使用 String.fromCharCode() 可以正常处理。但对于生僻字（如部分古籍汉字）或 Emoji 表情符号（如 🎉 \uD83C\uDF89），其码点超过了 0xFFFF，在 UTF-16 编码体系中由一对“高位代理”和“低位代理”（Surrogate Pairs）共同组成。

如果在正则替换时将高低位代理拆开单独调用 String.fromCharCode()，虽然在现代引擎中拼接仍可能显示，但在某些字符截断场景下极易产生孤立代理对，造成乱码。对于包含代理对的字符串，推荐使用以下两种安全方案：

1. 利用 JSON.parse('"' + str + '"') 安全反转

如果字符串是一段单纯被转义的文本内容，可以直接在两端拼接双引号，交给原生 JSON 解析引擎处理，引擎会自动合并代理对：

function safeDecodeUnicode(rawStr) {
  try {
    // 替换内部可能未转义的真实双引号，避免闭合冲突
    const escaped = rawStr.replace(/"/g, '\\"');
    return JSON.parse(`"${escaped}"`);
  } catch (e) {
    // 解析失败时平滑降级为正则替换
    return decodeUnicodeString(rawStr);
  }
}

五、根源治理：常见后端序列化配置与规范

在前端做转义解码虽然能解决显示问题，但这往往属于“事后补救”。在协同开发或微服务架构中，最彻底的做法是从数据源头（后端服务）直接输出未经转义的 UTF-8 字符。这不仅能减少网络传输的数据体积（每个汉字从 6 字节 \uXXXX 降为 UTF-8 的 3 字节），还能降低前后端解析负担。

各语言后端配置实操：

• Python 后端：在调用 json.dumps() 时，显式加入 ensure_ascii=False 参数。若使用 Flask 框架，设置 app.config['JSON_AS_ASCII'] = False。
• PHP 后端：在调用 json_encode() 时加入常量掩码：json_encode($data, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT)，即可在服务端直接生成带有缩进且保留中文的原生 JSON。

六、关键避坑要点与排查检查单

在实际排查“格式化后中文不显示或乱码”的过程中，建议按以下清单逐项验证：

1. 辨别单斜杠与双斜杠转义：在 JavaScript 字符串中，\u4e2d 在内存中会被立即识别为字符“中”。如果你通过 console.log 看到打印出来的字面量就是 \u4e2d，说明字符串变量中实际保存的是带有转义反斜杠的 \\u4e2d。正则匹配时需使用 /\\u([0-9a-fA-F]{4})/g。
2. 检查 HTTP 响应头字符集：服务端返回 JSON 时，务必在 Content-Type 中明确指定字符集为 application/json; charset=utf-8，防止中间代理服务器（如网关、Nginx）按默认的 ISO-8859-1 或 GBK 重新解析导致乱码。
3. 区分“数据编码”与“终端字体渲染”：有时数据在内存中已正确还原为中文字符，但在某些精简版 Linux 终端、Docker 容器或轻量级 IDE 的输出控制台中，由于缺少中文字体支持，汉字会显示为方框（□）或问号（?）。此时可在网页上渲染或使用 encodeURIComponent() 检查实际十六进制码点，确认是否属于环境字体问题。