Unicode 转义转换

使用步骤

1. 把文本或带 \u 转义的字符串粘贴进输入框
2. 选择方向：把文本转成转义，还是把转义还原成文本
3. 转义时按需选写法（定长 \uXXXX 或码点 \u{XXXXX}）、范围（只转非 ASCII 或每个字符）与十六进制大小写
4. 点击结果框右上角的复制按钮取走结果

工具说明

Unicode 转义是用 ASCII 字符写出任意文字的办法：反斜杠加 u 再加十六进制码点，中 就是 \u4e2d。它出现的场合基本都在源码里 —— JSON 文件、Java 与 JS 的字符串字面量、老系统里只允许 ASCII 的配置项，以及被某一层管道丢掉非 ASCII 之后你必须绕过去的那次调试。这个工具两头都做：把文字转成转义，以及把转义串还原成文字。

★ 这里转的是**码点**，不是字节，这是这类页面最容易混的一件事。字母 A 的码点 U+0041 恰好和它的 UTF-8 字节相同，所以只处理英文时，码点写法 \u0041 和字节写法 41 看着是一回事；汉字 明 的码点是 U+660E，而它的 UTF-8 字节是 E6 98 8E，两种写法差得很远。想要字节请去十六进制文本转换工具，两者的结果不能互相替代，粘错也不会报错，只会得到一个看着合理的错答案。

写法有两种，能力不同，所以做成选项而不是让用户猜。定长形 \uXXXX 只有四位十六进制，装得下基本多文种平面（到 U+FFFF），装不下 emoji 这类辅助平面字符 —— 后者必须写成**一对**代理，比如笑脸是 \ud83d\ude00。这不是本工具的习惯，是 JSON 与 UTF-16 的规定，Python 的 json.dumps 也是这么产出 \ud83d\ude00 的（实测与本工具的输出逐字符一致）。码点形 \u{1F600} 是 ES2015 起给 JS 字符串和正则的写法，一个转义就是一个字符、读起来干净，但 JSON 不认它 —— 实测把 \u{1F600} 交给 JSON 解析器会得到 Invalid \uXXXX escape。跨语言传递时用定长形。

解码这一侧刻意窄：只认 \uXXXX、\u{XXXXX} 和表示一个反斜杠的 \\ 三种，\n \t 这些一律原样保留。理由不是偷懒，是 \n 属于 C 与 JSON 的转义家族而不是 Unicode 转义，一个声称做 Unicode 转义的工具顺手把 \t 变成制表符，就会把 C:\temp 这样的 Windows 路径解坏 —— 那种错不会报错，只会让结果少几个字符。★ 编码侧永远把反斜杠产出为两个反斜杠，所以「宽松读入」不影响往返一致性：转出去再转回来必然得到原样。孤立代理（比如只有 \ud800 这半边）会被拒绝而不是还原：实测把这种字符串交给 TextEncoder，它会静默产出 EF BF BD 也就是替换字符，等于你以为拿到了字符、其实拿到了一个会坏在下游的半成品。

常见问题

\u4e2d 和十六进制工具的 E4 B8 AD 到底差在哪？

差在「码点」和「字节」是两个东西。\u4e2d 说的是 中 这个字在 Unicode 表里的编号 4E2D，跟用什么编码存储无关；E4 B8 AD 说的是这个编号经 UTF-8 编码之后在文件里实际占的三个字节。同一份文字，前者用来写进源码和 JSON，后者用来核对文件内容和哈希。英文看不出差别纯属巧合：A 的码点是 41，UTF-8 字节也是 41。需要字节请用十六进制文本转换，需要码点就用这里。

为什么我的 emoji 变成了两个 \u，是不是转错了？

没转错，这是定长形的规定。\uXXXX 只有四位十六进制，最多表示到 U+FFFF，而 emoji 都在辅助平面（U+10000 起），UTF-16 只能用一对代理码点拼它，笑脸就是 \ud83d\ude00 两截。JSON 规范就是这么写的，Python 的 json.dumps 产出的也是这两截。如果你希望一个转义对应一个字符，选码点形 \u{1F600} —— 但要贴进 JSON 的就别用，JSON 解析器不认这种写法，实测会直接报 Invalid \uXXXX escape。

转义结果可以直接放进 JSON 或 JS 源码吗？

可以，定长形转义就是 JSON 字符串里合法的内容，本工具的默认产出（小写四位、非 ASCII 才转、反斜杠转成两个）与 Python json.dumps 开启 ensure_ascii 的结果逐字符一致，这是实测核对过的。★ 唯一要注意的是 JSON 里 \u 后面必须恰好四位十六进制：不能写成 \u{…}，也不能只写 \u4e —— 前者 JSON 不认，后者位数不够，这里的解码器会保留原样而不是猜一个字符。

为什么 \n 和 \t 没有被还原成换行和制表符？

因为它们不属于 Unicode 转义，而属于 C 语言与 JSON 的转义家族。本工具只做 Unicode 转义这一件事，所以 \n 两个字符就照两个字符留着。这样定的实际好处是粘 Windows 路径不会坏：C:\temp 里的 \t 不会被莫名其妙变成制表符。如果你要处理的是整段 JSON 字符串的转义，用 JSON 相关的工具更合适；如果你要的是「让中文在 ASCII 管道里活下来」，那正是这里管的 \u 形。

我在 Python 里用 unicode_escape 编码，为什么解回来是 中æ 这种乱码？

因为那个 codec 不是按码点工作的：它把字符串先按 latin-1 处理，所以中文经过 UTF-8 再走 unicode_escape 就会拆成两个拉丁字母一组的乱码 —— 实测 中文 走这条路得到的是 中æ 这样一串，而不是 \u4e2d\u6587。正确的做法是让编码器按码点产出：json.dumps(ensure_ascii=True) 会得到 \u4e2d\u6587，也就是本工具的默认输出。判断自己踩没踩这个坑最快的办法是看结果里有没有 \\u 后面跟着非十六进制字符。

相关工具

• 十六进制文本转换
• HTML 实体转换
• Base64 编码解码
• URL 编码解码