Unicode 转义指南：让中文穿过只认 ASCII 的管道
转义的目的是穿过一段不保证 UTF-8 的管道，而不是让内容更安全。管道本身可靠时，转义只会让内容更难读。
什么时候需要 \uXXXX
Java 的 .properties 在旧版本里按 ISO-8859-1 读取，中文必须写成 \u4e2d；一些构建脚本、模板引擎和日志管道也只保证 ASCII 安全。把中文转成转义序列，能避免在这些环节被替换成问号。
排查编码问题时也常用：同一句话在两边显示不同，转义后就能确认到底是字符本身不同，还是渲染层出了问题。因为 ASCII 部分保持原样，对比起来很直观，也不需要联网或安装任何工具。
- Java properties、旧构建脚本
- 只保证 ASCII 的日志与传输管道
- 排查「看起来一样」的字符差异
规则与两个坑
工具只转非 ASCII 字符，ASCII 原样保留，所以代码结构仍然可读。每个字符写成 \u 加四位十六进制，中变成 \u4e2d。注意这是字符层面的转换，不是字节层面，和十六进制编码不是一回事。
坑一：超出 U+FFFF 的字符（多数 emoji）需要一对代理项，而本工具会输出 \u1f600 这样的五位形式，解码端只认四位，往返会得到另一个字符并多出一个 0。这类内容请改用 Base64 或 URL 编码。
- \u 后固定四位十六进制，只覆盖基本平面
- emoji 等增补字符往返会出错
- 不要对已经转义过的文本重复转义
边界：解决的是传输，不是安全
转义没有密钥，任何人看到 \u4e2d 都能还原，所以它不是加密，也不能用来隐藏敏感信息。它的体积还会膨胀，中文从 1 个字符变成 6 个字符，长文本会明显变大。
现代系统大多端到端 UTF-8，从数据库到 HTTP 头再到页面都声明 charset 之后，通常不需要手工转义。只有在确认某一环不支持 UTF-8 时，才值得引入这层转换，否则只是增加阅读成本。
- 无密钥，不是加密
- 中文 1 字符变 6 字符，长文本明显变大
- 现代 UTF-8 链路通常不需要它
常见问题
emoji 为什么会转错？
本工具按码位输出，\u 后不限制四位，emoji 会得到五位的 \u1f600；而解码端只取四位，还原结果就错了。需要传 emoji 时，用 Base64 或 URL 编码更可靠。
和 URL 编码有什么区别？
URL 编码按字节转成 %XX，主要给网址用；Unicode 转义按字符写成 \uXXXX，主要给源码和配置文件用。同一个汉字在两种方案里的结果完全不同。
转义后程序能直接读吗？
能，前提是读取方支持这种转义。Java、JavaScript、JSON 都认 \uXXXX，但纯文本编辑器不会自动还原，看到的仍是反斜杠加字母。
相关工具：Unicode 转义编码