编码解码哈希加密格式化时间转换开发生成文本处理网络工具其他工具
首页 / 编码解码 / Unicode编解码

Unicode编解码

中文和 Unicode 互转。

输入
结果

这个工具能做什么

这个工具做两件事:把中文或任意文字转成 \uXXXX 形式的 Unicode 转义序列,也就是中文转 unicode;或者把 \uXXXX 还原回原本的文字,即 unicode 转中文。日常写代码时,JSON 接口返回、JS 源码、Java 配置文件里经常出现 中文 这样一串看不懂的转义,肉眼很难判断到底是什么内容。把它粘进来做一次 unicode 转换,就能立刻看清背后的文字,反过来也能把中文快速编成转义形式贴回代码里。整个过程在浏览器本地完成,输入的文本不会上传。

\uXXXX 并不是一种独立的字符编码,而是 UTF-16 码元的十六进制转义写法。每个字符在 Unicode 里都有一个码点(code point),例如“中”是 U+4E2D,转义后就是 中——四位十六进制正好对应基本多文种平面(BMP,U+0000 到 U+FFFF)内的一个 UTF-16 码元。这也是为什么绝大多数汉字、日文假名都是一个 \u 就能搞定。而超出 BMP 的字符,比如大部分 emoji(😀 是 U+1F600),UTF-16 会用一对代理项(surrogate pair)表示,于是变成 😀 两段。编码时逐个码元补零成四位十六进制,解码时再把这些码元拼回字符串,和 JSON 规范里 \u 转义的定义完全一致。

最常见的场景是调试接口。很多后端为了规避编码问题,会把响应里的中文全部转义,你在浏览器 Network 面板看到的是 {"msg":"登录成功"},粘进来解码就知道是“登录成功”。另一种是往源码里写中文,有些老项目或压缩后的 JS 要求非 ASCII 字符必须转义,把“提交订单”转成 提交订单 再贴进字符串,就不会因文件编码不同而出问题。此外排查日志时,如果输出被打成了一串 \u 转义,用它做 \u转中文 也能马上还原出真实内容。

有几点容易混淆。\uXXXX 和 UTF-8字节序列(如 %E4%B8%AD 那种 URL 百分号编码)、以及 HTML 实体(中 或 中)是完全不同的转义体系,别混用,这个工具只处理 \uXXXX 这一种。十六进制字母大小写不影响还原,中 和 中 的解码结果相同,一般约定输出小写。另外 ES6 新增了 \u{1F600} 这种带花括号、可直接写码点的形式,它和经典四位 \u 写法不通用,粘贴时要留意来源格式。遇到落单的代理项或残缺的转义串,解码可能得到乱码或问号,这是输入本身不完整所致,并非转换出错。

Unicode编解码是一个免费的在线工具,打开网页就能用,不用下载也不用注册。平时大家搜的“unicode编码”、“unicode转中文”、“中文转unicode”,说的都是这个。

常见使用场景

使用方法

  1. 把内容粘贴到输入框(生成类工具直接设置选项)。
  2. 按需要选择选项,点操作按钮。
  3. 结果出现在下方,点「复制结果」即可带走。

常见问题

Unicode 编码、UTF-8、UTF-16 之间是什么关系?
Unicode 只规定每个字符对应哪个码点(如 U+4E2D),UTF-8 和 UTF-16 是把码点落到字节的两种编码方案。\uXXXX 转义用的是 UTF-16 码元,和 UTF-8 的 %E4%B8%AD 这类字节序列不是一回事。
为什么一个 emoji 会被转成两个 \uXXXX?
因为它的码点超出了基本多文种平面(大于 U+FFFF),UTF-16 无法用一个码元表示,要拆成高、低两个代理项(surrogate pair)。所以 😀 会写成 😀,这是正常现象,两段合起来才是一个字符。
\u 后面十六进制的大小写有讲究吗?
解码时不区分大小写,中 和 中 还原出的都是“中”。习惯上编码输出用小写四位十六进制,不足四位会在前面补零。
它和 URL 编码 %XX、HTML 实体 &#x...; 有什么区别?
三者是各自场景的转义规则:\uXXXX 用于 JSON/JS/Java 字符串,%XX 是 URL 里的 UTF-8 字节百分号编码,中 是 HTML 实体。写法互不通用,本工具只负责 \uXXXX 与文字的互转。
解码出现乱码或失败通常是什么原因?
多半是输入的转义串本身不完整,比如只有半个代理项、\u 后不足四位十六进制,或混入了 %XX、&#x 等其他体系的转义。检查来源格式、补齐缺失的码元后再解码即可。

相关工具

查看全部「编码解码」工具 →

相关名词解释