「反斜杠 u 加四位十六进制」是合法的 JSON 写法，指向一个 Unicode 码位。Java 老版序列化、部分网关日志、被安全策略过滤过的输出都会这么写。它不是乱码——解析结果完全正确，只是人读不了。真正麻烦的是两种方向搞混：该还原的时候原样转发，或者该转义的时候直接塞了中文进去。

什么时候必须反转义

场景全是「给人看或给人改」：读日志里的用户昵称、核对配置中的中文提示语、把接口返回的文案交给产品确认。这时用「JSON 格式化」的反转义功能把转义串换回汉字，再美化输出。

本站美化时中文字符保持原样，不会被重新写成转义形式，所以还原一次就够，不会因为反复格式化又变回去。这一步有个隐蔽收益：混合内容里可能藏着真换行和半截引号，还原成汉字后一眼能看出来，纯转义形态下它们是几串无害的字母数字。

什么时候反而要转义

把 JSON 塞进 HTML 的内联脚本、拼进 URL 参数、写进只允许 ASCII 的配置文件或邮件正文时，非 ASCII 字符可能被中间的传输层改写。这时候做转义，让整份内容只剩安全字符，接收端解析时再自动还原。同理，跨系统传递、不确定对方编码声明是否可靠时，转义是一份自带的保险。

判断依据只有一条：中间有没有会碰字节的环节。直接给自己程序的解析器读，不用转；要经过文本拼接、模板渲染、邮件、命令行传参，就转。

三个常见误判

双重转义。 反斜杠本身被再转了一次，表现为满屏两个连续反斜杠加 u。这种内容看起来像坏了，实际是某处多序列化了一次，要先解一层再反转义，否则汉字还原不出来。

转义不完整。 一部分汉字是转义形式、一部分是明文，通常是两次导出合并的结果。这类不影响解析，只影响阅读。

代理对。 生僻字与 emoji 由两个转义序列配对表示，手工删掉其中一半会让整个文件解析失败。别在文本编辑器里手改转义串。

操作顺序

  1. 粘进 JSON 格式化，先确认语法能过；过不了先修错。
  2. 需要人读就执行反转义并选 2 空格缩进美化。
  3. 需要外发就反向执行转义，再压缩成单行减少传输环节的干扰。
  4. 存盘前用统计项核对字符串数量没变，防止手改删掉了内容。

边界说清楚：这一页只处理 JSON 的转义规则，不做编码转换，也不接受 YAML 与 XML 输入。GBK 或 Big5 编码的文件请走 TXT处理，那边负责识别输入编码，但它同样只能输出 UTF-8 或带 BOM 的 UTF-8，存不出 GBK 文件。全程在浏览器本地完成，不上传服务器。