字元代碼查詢工具會顯示字串中每個 Unicode 純量值，精確指出文字內含哪些抽象字元(範圍從 U+0000 到 U+10FFFF)，而非這些字元如何以位元組儲存，或如何在螢幕上繪製。每個純量值都是 Unicode 標準所指定的一個數字，以 U+ 加上至少四位數的大寫十六進位表示，因此字母 A 會顯示為 U+0041，而笑臉表情符號 😀 則會顯示為 U+1F600，而不是被拆成兩個代理半項。這個查詢是雙向的:貼上字串即可查看其代碼點，或貼上一連串的 U+XXXX 或 \u{...} 詞元，即可重建原始文字。由於轉換會逐一處理 Unicode 代碼點，而不是 JavaScript 的 UTF-16 程式碼單元，因此輔助平面字元會保持單一純量值，控制字元和零寬度連接符會明確顯示，而 U+D800 到 U+DFFF 範圍內的代理程式碼單元則會被拒絕，而不是悄悄通過。這是字元身分的真實基礎檢視，所有其他文字編碼都建立在其之上。
字元代碼查詢實際顯示的內容
字元代碼查詢工具的核心功能，是回答一個診斷問題:此字串內含哪些抽象字元?答案是純量值的清單，每個值都是介於 0 到 1,114,111 之間的唯一整數，以 U+ 加上十六進位值表示。對於任何 Unicode 字串，輸出都是確定且無損的。字母 A 會變成 U+0041，小寫的 é 會變成 U+00E9，中文字元 中 會變成 U+4E2D，表情符號 😀 則會變成 U+1F600。基本字元至少會顯示四位十六進位數，而輔助平面字元則會保留其完整數值，而不是像 JavaScript 的 UTF-16 索引那樣被拆成兩個代理半項。轉換會逐一處理代碼點，而不是程式碼單元，因此即使是混合多種文字、帶有變音符號的格式，或現代表情符號的貼上內容，都能乾淨地解析成單一詞元串流。若需快速檢查混合語言文字，或除錯從其他程式複製過來的字串，Unicode 編碼/解碼工具可直接在瀏覽器中產生此檢視。
為何代碼點與字元並不相同
字元代碼查詢中最常見的混淆來源，是誤以為一個代碼點等於一個可見字元。實際上並非如此。Unicode 純量值是一種抽象編號;使用者在螢幕上感知字元的方式，則是另一個稱為字素群集(grapheme cluster)的概念，而單一字素可能需要多個純量值。表情符號 👩💻(女性科技人員)就是一個清楚的例子:它會編碼為 U+1F469(女性)、U+200D(零寬度連接符)和 U+1F4BB(筆記型電腦)這組序列。三個純量值，一個可見符號。同樣的模式也適用於許多家庭表情符號、由不可見分隔代碼點連接的區域旗幟、可寫成單一預組合字元或基礎字母加上組合記號的變音形式，以及使用組合變音符號的書寫系統。字元代碼查詢會顯示純量序列，並不會宣告能切割字素群集——兩者是同一段文字的階層式檢視，各自適用於不同的工作。
純量範圍與代理排除
Unicode 將純量值分配在十七個平面中，從基本多語言平面的 U+0000 開始，到第 16 平面頂端的 U+10FFFF 為止。在這個範圍中，U+D800 到 U+DFFF 之間的區間永久保留給 UTF-16 代理配對，絕不會代表獨立的字元。正確的字元代碼查詢會同時強制這兩個邊界:會拒絕代理半項，因為它們只有配對時才有意義;也會拒絕 U+10FFFF 以上的任何值，因為標準並未定義超出純量範圍的值。驗證並非表面工夫。Unicode 標準定義了純量值如何轉為 UTF-8、UTF-16 及其他編碼所用位元組序列的規則，而這些規則預設代理範圍是空的。若有工具悄悄讓代理值通過，就會讓格式錯誤的字串在內部往返轉換時看似正常，卻仍會被下游每個符合標準的解碼器拒絕。標準的代碼點圖表可在 unicode.org/charts 查看，完整的分配皆有記載，純量檢視則嚴守這份明文契約。
代碼點與 UTF-8 位元組的差異
由於兩者都使用「編碼」一詞，代碼點與 UTF-8 位元組經常被混用。它們其實回答不同的問題。代碼點為抽象字元命名，UTF-8 位元組序列則是該字元的一種具體線上傳輸表示方式。兩者之間的對應關係由標準固定，因此只需一張小表就能讓這項區別變得明確。
| 字元 | Unicode 純量 | UTF-8 位元組 |
|---|---|---|
| A | U+0041 | 41 |
| é (預組合) | U+00E9 | C3 A9 |
| 中 | U+4E2D | E4 B8 AD |
| 😀 | U+1F600 | F0 9F 98 80 |
| 換行 | U+000A | 0A |
對於 ASCII 字元，純量值與單一 UTF-8 位元組恰好相符。對於 ASCII 以外的字元，兩者依設計而有所不同，而對輔助字元而言，差距會急劇擴大。當問題是「此字串內含哪些抽象字元」時，純量檢視才是正確選擇。當問題是「這個檔案或通訊協定實際上承載哪些位元組」時，UTF-8 位元組檢視才是正確選擇。
在瀏覽器中執行字元代碼查詢
若要對字串進行快速的診斷檢查，具備純量感知的工具中的編碼模式就已足夠。這個流程可讓輸入與輸出保持明確，即使涉及不可見字元也一樣。
- 開啟 Unicode 編碼/解碼工具，選擇「文字轉代碼點」方向。
- 貼上您要檢查的確切字串，包括任何不可見字元，例如空格、定位字元、換行符或零寬度連接符。工具會將輸入限制為 100,000 個代碼點，因此過長的字串可能會被截斷，以維持回應速度與複製流程的順暢。請勿憑記憶重新輸入文字——請從來源複製，確保位元組序列保持完整。
- 轉換並檢查每個 U+ 詞元。確認輔助字元會以單一純量值顯示(例如 😀 顯示為 U+1F600)，而非代理配對。
- 將詞元串流視為診斷依據。在貼上的識別碼結尾出現意外的換行 (U+000A)、兩個可見字元之間夾雜 U+200D，或在預期為一般空格的位置出現不斷行空格 (U+00A0)，即使渲染後的文字看起來一模一樣，這些情況都會在此顯現出來。
- 複製 U+ 序列以用於記錄檔、錯誤報告或測試資料中。純量串流是對字串內容的穩定、可安全複製貼上的描述。
一個實際操作的例子能讓格式變得具體。大寫字母 A 是單一代碼點，十六進位值為 0x41。依標準的十六進位轉十進位計算，0x41 等於 4 × 16 + 1，即十進位 65。因此查詢結果會回報 U+0041——大寫 A，基本拉丁字母，十進位 65。一旦理解了這個轉換，同樣的邏輯便適用於字串中的其他所有純量值。
將 U+ 與 \u{} 詞元解碼回文字
記錄檔、文件和原始碼中經常包含純量值，而不是原始字元。同一個工具的反向作業，可從這些詞元重建字串。每個詞元必須以 U+ 開頭(例如 U+0041 或 U+1F600)，或以 JavaScript 風格的反斜線 u 標記法 \u0041 或 \u{1F600} 開頭，包括輔助值所需的大括號形式。詞元之間可以用空格、逗號或換行分隔，而十六進位字母不區分大小寫，因此 u+0041 和 U+0041 等價。工具會在建構輸出前驗證每個詞元:超出範圍的數字、缺少前置符號、非十六進位字元，以及代理範圍內的任何值，都會被拒絕，而不是悄悄替換。輸出只有在完整詞元清單通過純量驗證後才會建立，因此格式錯誤的詞元會以單一錯誤回報，而不是破壞結果。關於兩種詞元形式的實用參考，請參閱 U+XXXX 與 \u{} 語法速查表。
代碼點檢查不適用的情境
Unicode 代碼點是字元身分的真實基礎，但並非通用的文字格式。字元代碼查詢刻意不會正規化輸入，因此預組合的 é (U+00E9) 與分解的 é (U+0065 後接 U+0301)，即使兩者通常渲染結果相同，也會被視為不同的序列。這種精確性對於診斷而言正是重點，但對於需要特定線上格式的工作來說，反而是錯誤的工具。HTML 實體、JSON 字串跳脫、URL 百分比編碼和 UTF-8 位元組，各自有不同的語法與規則，正確的選擇取決於接收端系統，而不是抽象字元本身。當通訊協定、檔案格式或程式語言強制使用其中一種表示法時，請使用對應的轉換器，並將代碼點檢查留給它真正能回答的問題:此字串內含哪些抽象字元。
相關閱讀:ASCII 代碼轉換器解析:字元與其代碼。