一個能顯示字串中每個 Unicode 純量值的 Windows 字元代碼查詢工具，就是 Unicode 編碼器 / 解碼器:一個在本機瀏覽器中執行的工具，會依 Unicode 代碼點逐一處理文字，將輔助平面字元視為單一值，並接受 U+XXXX 或 \u{...} 形式的代號來解碼。這件事在 Windows 上很重要，因為作業系統內建了幾個零碎方案——字元對應表、Win+. 表情符號面板、Word 中的 Alt+X，以及透過登錄檔調整的 Alt + 數字鍵序列——但這些工具都無法顯示你已複製或接收的字串中完整的純量序列。字元對應表是最接近的類似工具，可追溯至 Windows 95，但它一次只能列出已安裝的字形，從未提供緩衝區來顯示其中的內容。下方工具正是為了填補這個落差而打造。
Windows 提供的工具只能處理單一字元，無法處理整個字串
Windows 內建的每個字元查詢功能都是為了「插入」而設計，並非為了「檢查」。字元對應表(charmap.exe，自 Windows 95 起便存在)會列出已安裝的字形及其 U+ 標籤，並將選取的字形複製到剪貼簿;它無法顯示你已貼上的字串內容。Win + . 會開啟現代的表情符號選擇器供搜尋與插入，但底層的純量值仍是隱藏的。Alt + X 在 Microsoft Word 內會將游標左側的四個十六進位數字轉換為對應字元，這在輸入時很方便，但對於診斷緩衝區中已有的內容毫無助益。Alt + 數字鍵 技巧需要透過小幅登錄檔編輯啟用，一次只能接受一個字元的小數或十六進位輸入，而且僅限於 Windows 已載入的字碼頁。
| Windows 方式 | 它顯示的內容 | 它的限制 |
|---|---|---|
| 字元對應表 (charmap.exe) | 單一字形及其 U+ 標籤 | 無法檢視字串的其餘部分或其序列 |
| Win + . 表情符號面板 | 表情符號搜尋與插入 | 不會顯示它所插入的代碼點 |
| Alt + X (Microsoft Word) | 將四位數十六進位前置碼轉換為字元 | 需要 Word;無法檢查已貼上的內容 |
| Alt + 數字鍵 (需登錄檔啟用) | 小數或十六進位輸入，一次一字元 | 僅限已安裝的字碼頁;一次一字元 |
| Unicode 編碼器 / 解碼器 (瀏覽器) | 完整字串中的每個純量值 | 每次執行上限 100,000 個代碼點 |
每個案例的模式都相同:Windows 工具一次只能識別一個字元，讓多代碼點的表情符號、分解後的附加音符以及隱藏字元都看不見。一個能遍歷整個字串的瀏覽器工具正好能補上這個缺口。
在 Windows 上查詢字串中的每個代碼點
在任何現代瀏覽器(Edge、Chrome 或 Firefox)中開啟 Unicode 編碼器 / 解碼器，然後依照下列步驟操作，即可查看你從其他應用程式、記錄檔或指令輸出複製而來的字串中每個純量值。
- 選擇「文字轉代碼點」方向。 工具完全在瀏覽器中執行，資料不會離開本機。請選擇標示為將文字轉為代碼點的編碼方向;解碼方向則是下方另述的選項。
- 貼上完整的 Unicode 字串，包括任何隱藏字元。 控制字元、零寬接合符以及其他預設可忽略的代碼點都會隨貼上動作一併帶入。換行字元會變成 U+000A，零寬接合符會變成 U+200D，兩者在輸出中都會顯示出來。
- 轉換並檢查每個 U+ 代號。 輸出會以大寫 U+ 十六進位表示，至少四位數，因此 ASCII 的 A 會變成 U+0041。輔助平面的字元會保留其完整數值:😀 會編碼為單一代號 U+1F600，而不是兩個代理半字。
- 複製 U+ 序列。 使用複製動作將這些代號帶到記錄檔、錯誤報告或其他診斷步驟中。代號之間的分隔很重要，尤其是在相鄰的值可能被誤認為一個較長的十六進位數字時。
如果你需要反向操作——手上已經有來自文件、原始碼或記錄項目的 U+ 或 \u{} 代號——請切換到解碼模式，並依照下一節的說明進行。
將 U+ 和 \u{} 代號解碼回文字
解碼模式接受以 U+ 開頭的代號，或是使用 JavaScript 風格的反斜線 u 標記法，包括用於輔助平面數值的大括號形式。代號之間可以用空格、逗號或換行分隔;剖析器對三者的處理方式相同。十六進位數字不區分大小寫，因此 U+00e9 和 U+00E9 是等價的。
解碼步驟會在建構輸出文字之前驗證每個代號。任何落在 U+0000 至 U+10FFFF 範圍之外的代號都會被拒絕，落在 U+D800 至 U+DFFF 代理區間的代號也一樣，因為該區間保留給 UTF-16 代碼單元，並不代表獨立的字元。缺少前置碼或含有非十六進位數字的情況也會以同樣方式失敗:工具不會靜默地替換成替代字元，而是會顯示該錯誤代號，以便修正輸入。只有在每個代號都通過純量值驗證後，輸出文字才會被組裝完成，這正是讓往返轉換可靠的關鍵。
大括號形式對輔助字元是不可或缺的。寫成 \u{1F600} 會產生 😀;寫成 \uD83D\uDE00 則會透過其 UTF-16 代理對產生相同的字形，但這些代理半字在此處並非有效的純量代號，解碼器會拒絕它們。這與 ECMAScript 中 String.fromCodePoint 的規範一致:正確的單位是純量值，而非 UTF-16 代碼單元(ECMAScript String.fromCodePoint)。
為什麼一個可見符號可能隱藏多個代碼點
代碼點與使用者感知到的字元並不相同。視覺上的表情符號 👩💻 在人眼中是一個符號，但它包含三個純量值:U+1F469 (女子)、U+200D (零寬接合符) 和 U+1F4BB (筆記型電腦)。許多國旗、家庭表情符號、膚色修飾符以及附加音符形式也都是序列。這個工具並不聲稱能分割字素簇;它顯示的是原始的純量序列，讓你能確切看到字串裡有什麼。
附加音符字母提供了另一個例子。預組合的 é 是單一純量 U+00E9。視覺上相同但已分解的 é 則是 U+0065 (e) 後面接著 U+0301 (組合尖音符) 的一對。兩者渲染結果相同，都是有效的 Unicode，也可能出現在同一份資料中。它們是不同的純量序列，若將它們視為相等來搜尋或比較將會失敗。這個工具刻意不進行正規化;差異本身就是診斷訊號。
隱藏的控制與格式字元也會以同樣方式浮現。換行字元是 U+000A，歸位字元是 U+000D，零寬空格是 U+200B，零寬接合符是 U+200D。當從其他來源貼上的文字無法精確比對、在檔名中顯示異常，或讓游標移動不如預期時，純量序列通常能解釋原因。明確顯示這些數值，正是將文字通過代碼點檢查器的價值所在。
限制與這個工具不涵蓋的範圍
在依賴輸出之前，有三個界線值得了解。首先，每次執行的輸入上限為 100,000 個代碼點，以保持 Windows 筆記型電腦上的渲染與複製流暢;較長的文件應先分割或篩選再貼上。其次，工具顯示的是抽象的代碼點，而非 UTF-8 位元組。預組合的 é 是 U+00E9，但其 UTF-8 表示是兩個位元組 C3 A9，這才是通訊協定、檔案格式和網路傳輸實際傳遞的內容。當問題涉及位元組層級的編碼時，該使用 UTF-8 編碼器 / 解碼器。第三，工具不會查詢字元名稱、字體、易混淆狀態或語言意義，也不會驗證某個序列是否構成建議的表情符號或正字法簇;這些都是超出可逆純量轉換範圍的獨立 Unicode 屬性。
正規化刻意不會執行。預組合的 é 和分解後的 e + 組合尖音符都會原樣接受，以保留差異。這種精確性正是讓輸出在診斷 Windows 系統上搜尋、識別碼、檔案名稱與比較問題時有用的原因，而這些系統中的資料經常在字碼頁、應用程式與殼層之間移動。
搭配使用 Windows 原生的插入工具與本機代碼點檢查器，即可涵蓋任務的兩半:使用字元對應表或 Win + . 插入特殊字元，然後將產生的字串通過編碼器，以確認實際傳遞了哪些純量值。
如果你正在權衡選項，URL 解碼速查表:常見代碼與快速修正 有詳細說明。