Unicode 跳脫序列

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 弄壞。

沒有任何上傳

在這個頁面裡轉換。