Unicode 純量值是 Unicode 標準為每個已指派字元所指派的單一抽象整數,而Unicode 編碼器 / 解碼器 透過完全在瀏覽器中執行,在你的字串中呈現每一個純量——無需字元碼查詢 API 呼叫、無需伺服器往返,也無需上傳。這個工具以 Unicode 碼點而非 JavaScript UTF-16 碼元來逐一檢視你的輸入,這正是它能將 😀 呈現為單一符記 U+1F600 而非將其拆成兩個代理對半體的關鍵差異。它接著以至少四位十六進位數字來格式化基本字元——A 會變成 U+0041——而輔助平面字元則保留其完整的數值。轉換在瀏覽器本機進行,因此只要頁面載入完成即可運作,並避免任何將貼上的文字傳送至遠端端點所衍生的隱私疑慮。這使得它成為託管式字元碼查詢 API 的實用替代方案,適合需要檢查字串、診斷複製貼上比較為何失敗,或從日誌或文件中擷取到的純量符記重建文字的開發人員。
為何在本機執行字元碼查詢,而非呼叫 API
託管式的字元碼查詢 API 會接收你的字串、透過網路送出,然後回傳一個或多個代碼識別子。這雖然可行,卻會帶來摩擦:你需要一組 API 金鑰、必須仰賴該服務持續上線、每次按鍵都得支付往返延遲的成本,還得信任該端點會妥善處理你正在檢查的任何文字——當那段文字是客戶資料、秘密權杖,或從私人文件複製的片段時,這可能成為實質的疑慮。
基於瀏覽器的轉換器則迴避了上述所有問題。Unicode 編碼器 / 解碼器中的轉換在本機執行:貼上字串、點選轉換,結果便在不離開頁面的情況下出現。沒有帳號、沒有配額、沒有 API 金鑰,也不會有洩漏你正嘗試偵錯之字元的風險。當你反轉操作,餵入 U+XXXX 或 \u{...} 符記以重建原始文字時也是如此。
這正是「API 替代方案」這個框架所要填補的落差:你仍想要字元碼查詢 API 所提供的那種具確定性、以標準為後盾的答案,卻不想承受網路依賴、註冊流程,或是上傳即將檢查之字串的麻煩。
將文字編碼為 Unicode 碼點
- 選擇「文字轉碼點」方向,貼上你想檢查的確切字串,包括你看不到的字元——換行、定位字元、零寬連接符以及 BOM 標記都算在內。
- 執行轉換並讀取結果:一連串 U+ 十六進位標籤,每個 Unicode 純量值對應一項,以大寫呈現,基本字元至少四位數。
- 複製 U+ 序列,並與某個程式庫、日誌行或正規表達式所預期的內容進行比對;若可見輸出看起來完全相同,但 U+ 序列卻有差異,這種不符通常源於標準化方式的差異、不可見的控制字元,或是遺漏的連接符。
幾個範例可以說明你可預期的輸出:
- 單一 ASCII 字母 A 會變成 U+0041。
- 附音字元 é 的預組形式會變成 U+00E9。
- 輔助平面的表情符號 😀 會變成 U+1F600,而非 JavaScript UTF-16 迭代所產生的代理對 D83D DE00。
- 換行字元會編碼為 U+000A;零寬連接符則明確顯示為 U+200D。
將 U+XXXX 或 \u{...} 符記解碼回文字
當資料流方向相反時,將一串帶有前綴的符記貼入解碼方向。可接受的格式包括 U+XXXX(四位以上十六進位數字)、\uXXXX(JavaScript 風格跳脫),以及 \u{XXXX} 或 \u{XXXXX}(用於輔助平面值的 JavaScript 大括號標記法)。符記之間可以空格、逗號或換行分隔。十六進位數字不區分大小寫,但你必須保留前綴與符記邊界的完整性——若兩個相鄰的符記之間沒有分隔符,可能會被讀成一個更長的十六進位數字。
此工具會在重建任何輸出之前驗證每一個符記。它會拒絕 U+0000 至 U+10FFFF 範圍之外的值,會拒絕 U+D800 至 U+DFFF 的代理範圍,會拒絕缺少前綴的情形,也會拒絕任何非十六進位的字元。只有在所有符記都通過純量值驗證後,才會建構輸出文字,如此你會看到明確的錯誤訊息,而不是悄悄毀損的字元。這種嚴謹性得以避免常見的自相矛盾陷阱——錯誤的代理對慣例會與自身往返轉換,卻永遠不會浮現警告。
碼點、UTF-16 碼元與 UTF-8 位元組是三件不同的事
碼點既不是位元組,也不是 JavaScript 字元。混淆這三個層次,是「字元碼查詢」對非 ASCII 文字給出錯誤答案最常見的原因。
| 表示方式 | 其所識別的內容 | é 的範例 | 😀 的範例 |
|---|---|---|---|
| Unicode 碼點 (U+) | Unicode 標準定義的抽象字元 | U+00E9 | U+1F600 |
| UTF-16 碼元 | JavaScript 字串、.NET、Windows API 使用的 16 位元值 | 00E9(一個碼元) | D83D DE00(兩個代理半體) |
| UTF-8 位元組 | 檔案、URL、JSON、HTTP、多數網路協定所使用的 8 位元值 | C3 A9 | F0 9F 98 80 |
若某個工具將 😀 的值回報為 128512,那是 U+1F600 的十進位形式,表示你正工作在碼點層次,亦即 Unicode 編碼器 / 解碼器所處的同一層次。若它回報 55357 56832,那是兩個 UTF-16 碼元。若它回報 F0 9F 98 80,那是四個 UTF-8 位元組。這三種描述在其各自的層次上都正確;一旦跨層次混用,數字看起來就會互不相容。公開的Unicode 碼點圖表列出抽象字元,而ECMAScript String.fromCodePoint則定義了 JavaScript 執行環境所使用的碼點建構式。當某個協定、檔案格式或儲存層次要求的是位元組而非純量時,請改用 UTF-8 位元組轉換器。
真實世界的字串,極少在可見字元與碼點之間呈現一對一對應
碼點未必等同於使用者所感知的字元。表情符號 👩💻(女性工程師)是一段由三個碼點組成的序列——U+1F469(女性)、U+200D(零連接符)以及 U+1F4BB(筆記型電腦)——並呈現為單一字素。許多國旗、家庭表情符號、附音字母以及文字系統形式皆採用同樣的多純量序列。下表展示一些常見輸入實際上是如何拆解的。
| 可見字元或字串 | 純量序列 |
|---|---|
| A | U+0041 |
| é(預組形式) | U+00E9 |
| é(分解形式) | U+0065 U+0301 |
| 😀 | U+1F600 |
| 👩💻 | U+1F469 U+200D U+1F4BB |
| 換行 | U+000A |
| ♪(音符符號) | U+266A |
兩列 é 在呈現時看起來一模一樣,且兩者皆為有效的 Unicode,但它們的純量序列不同。當搜尋查詢、識別子、檔案名稱或比較在毫無明顯原因下失敗時,正需要把這種差異浮上檯面。Unicode 編碼器 / 解碼器在不解構進行正規化的前提下將其呈現,因此你貼上什麼,就解碼出什麼。控制字元與預設可忽略的碼點也包含在內,這就是為什麼零寬連接符會明確顯示為 U+200D,而換行則顯示為 U+000A——揭露那些能解釋游標意外移動、或解釋從其他來源貼上的文字為何無法通過完全比對的形數值。
此工具的適用範圍,以及何時該交棒給其他工具
U+ 表示法是一種診斷格式,並非適用於每種程式語言的跳脫方式。HTML 實體使用 &...; 或 &#...;,JSON 在字串字面值中使用 \uXXXX,URL 編碼以 %XX 表示每個位元組,而 UTF-8 則使用原始位元組。每一種都有其自身的語法與規則,這些都不在檢查 Unicode 純量值的範圍之內。當你真正想問的是某個字串含有哪些抽象字元時,請使用 Unicode 編碼器 / 解碼器。當某個協定或檔案格式要求位元組層級的編碼時,請使用 UTF-8 位元組轉換器;當你需要特定的跳脫語法時,則使用 HTML 實體編碼器、URL 解碼器,或你所屬執行環境的 JSON 風格跳脫機制。將純量檢查視為字元身分的根本依據,即可在這些編碼方式之間切換,而不致迷失原始字串的實際內容。
此工具亦有一項明確且較小的限制:輸入上限為 100,000 個碼點,以維持渲染與複製操作的流暢。它不會查詢字元名稱、字集、易混淆狀態或語言意義,也不會驗證某個序列是否構成建議的表情符號 ZWJ 序列或單一正字法叢集。這些都是可逆純量轉換之外的獨立 Unicode 屬性,將其視為超出範疇,正是這個工具能保持專注並值得信賴、作為本機字元碼查詢替代方案的關鍵。
若你正在權衡各種方案,如何在本地為 1Password 產生密碼對此有詳細說明。
若你正在權衡各種方案,建置於 AES-256-GCM 的 AES 線上加密替代方案對此有詳細說明。