Unicode 跳脱序列
在浏览器里把文字转成 \u 跳脱序列并转回来，正确处理 U+FFFF 以上的字元。
在你的浏览器中运行
还没有东西可以转换。
U+FFFF 以上有两个正确答案
这正是「正确的转换器」和「坏掉的转换器」之间的差别。
U+FFFF 以内的每个字元都是一个 \uXXXX，没有什么好决定的。在那之上——大多数 emoji，以及像
𝕏（U+1D54F）这样的数学字母——JavaScript 是以代理对储存的：两个 16 比特的半边，各自单独
看毫无意义。
所以 𝕏 有两种写法：
\u{1D54F}——一个字元一个跳脱序列。现代 JavaScript、Rust、Swift。\uD835\uDD4F——UTF-16 代理对。较旧的 JavaScript、Java，以及大多数 JSON 工具。
在各自的脉络下两者都正确。这里的默认是前者，因为把一对落单的代理码位贴到不是 UTF-16 的地方， 才是真正会坏掉的那种情况。目标环境需要另一种时再切换。
\U0001D54F 是 Python 与 C 的写法，\1d54f ——十六进位后面接一个作为结束的空白——则是 CSS
的写法。
这一页要避开的那个 bug
依索引而不是依字元走访字符串的转换器，会把代理对从中间切开。输出看起来煞有介事，解码回来却完全 不能用，而且只有在遇到 emoji 时才会出错——那偏偏是大家最后才测的输入。
这里的每一步都是依码位走访的，所以代理对永远是完整的。
Emoji 常常不只一个字元
👨👩👧 不是一个字元，而是五个：三个人，中间用两个零宽连接符（\u200D）接起来。转义会把五个
都列出来，而把连接符丢掉，会不声不响地把一家人变成三个各自独立的人。
旗帜也是同样的道理——🇹🇼 是两个区域指示符号——肤色变体则会在上面再加一个修饰符。
转回去
解码端接受所有人可能贴进来的写法：\uXXXX、\u{...}、\UXXXXXXXX、\xNN、%uXXXX，
以及裸写的 U+XXXX。相邻的两个代理半边会被重新组合成它们原本要拼出的那个字元。
不是跳脱序列的文字会原样保留，所以像 C:\Users\me 这样的 Windows 路径不会被 \U 弄坏。
没有任何上传
在这个页面里转换。