Unicode 与中文互相转换
把 \u4e2d\u6587 还原成汉字，或把汉字编码成 \uXXXX，处理中英文混排的 JSON 报文与资源文件。
很多系统为了避免编码问题，会把非 ASCII 字符写成 \uXXXX 转义，于是接口返回里全是 \u4e2d\u6587 这样的片段，既读不懂也没法直接比对。这个工具把转义序列还原成汉字，也支持反方向：把中文编码成 \uXXXX，用于生成只含 ASCII 的 JSON 或配置文件，避免在不同字符集之间传输时出现乱码。
转换是纯文本替换，不要求输入是合法 JSON，因此片段、半成品、带语法错误的文本都能处理。整个过程在浏览器里执行，粘贴的多语言资源、含中文的接口数据不会被上传或缓存，离线状态下也能正常转换。
转义形式与识别范围
工具识别的是反斜杠加 u 再接四位十六进制数字的形式，四位之外的写法不处理，例如 ES6 的 \u{1F680} 这种带花括号的码点写法不会被识别。还原成中文时按 UTF-16 代码单元逐个处理，码点超出基本多文种平面的字符（码点大于 U+FFFF）在 JSON 里本来就写成一对代理项，例如 \uD83D\uDE80，还原后会正常显示为一个字符，不需要手工合并。
编码覆盖范围与规则
反方向并不是只挑汉字转换，规则是把码位大于 0x7F 的字符全部编码，也就是说全角标点、中文引号、日文假名、带重音的拉丁字母都会一起被转义，ASCII 范围内的字母、数字与半角符号保持原样。这样做的好处是输出可以安全地放进任何只接受 ASCII 的通道。同一次输入里中英文混排会各自按规则处理，不需要分段操作，两种方向都是幂等的，重复执行不会把已转换过的内容再转一次。
体积代价与使用建议
转义会让体积明显增加：一个汉字在 UTF-8 里占 3 字节，写成 \uXXXX 是 6 个 ASCII 字符也就是 6 字节，等于翻倍，如果原文使用更紧凑的编码差距会更大。所以只在对方系统确实需要 ASCII 时才转义，纯粹为了好看或「更安全」没有必要。反过来，读到满屏 \uXXXX 的内容时，先还原成汉字再搜索、比对会容易得多。需要注意转换按纯文本进行，不判断片段是否位于引号内，注释与字段名里的转义同样会被处理。
常见问题
- \u4e2d 还原后还是乱码怎么办？
- 说明原始数据在传输过程中已经损坏，不是转义本身的问题。常见原因是写入方以 UTF-8 编码、读取方按 GBK 解码，或者响应里缺少字符集声明。转义序列只包含 ASCII，本来就是最不容易出错的形态，先把数据按正确编码读出来，再还原成中文即可。
- 为什么转义后 emoji 变成了两个 \u 片段？
- emoji 的码点超出基本多文种平面，UTF-16 里用一对代理项表示，所以写成 \uD83D\uDE80 这样的两个片段是正常的。它们在 JSON 字符串里合法，还原后会正确显示为一个字符，也不影响任何解析器的结果，不需要手工合并。
- 转换会改变 JSON 的语义吗？
- 不会。在 JSON 字符串内部，\u4e2d 和「中」表示同一个字符，解析出的值完全一致，区别只在体积与可读性。但转换是纯文本操作，不会判断某段内容是否处于引号内，注释和字段名里的片段也会被一起处理，用在不合法或结构混乱的文本上时要自行确认范围。
- 能把整个文件里的中文都转掉吗？
- 可以，把文件内容全选粘贴进来转换即可，工具处理的是编辑区里的全部内容。没有行数或体积限制，唯一的实际约束是浏览器内存与编辑器渲染速度，几 MB 级别的文本通常没有问题。