Punycode 是 RFC 3492 Bootstring 編碼,能僅使用基本 ASCII 字母、數字與連字號,來表示非 ASCII 的網域標籤;而將 punycode 轉換為 Unicode,意思就是反向執行該編碼,讓像 xn--bcher-kva 這樣的標籤顯示為 bücher。整個轉換純粹是文字層面的處理:它不會解析 DNS、不會聯繫註冊管理機構,也不會存取任何主機。若要在瀏覽器中將 punycode 轉換為 Unicode,請貼上 ASCII 網域、選擇「ASCII-Punycode 轉 Unicode」方向,接著讓 Punycode Converter 對每個帶有 xn-- 前綴的標籤套用 Bootstring 解碼,同時把一般 ASCII 標籤轉為小寫,除此之外不做任何變更。輸出結果就是該編碼形式所代表的可讀 Unicode 拼字,方便您在點擊或複製之前進行目視檢查。每個以點分隔的段落會獨立處理,因此多標籤的輸入會以原本的樣子完整往返 — 變動的只有字元集,標籤數量與點的位置皆保持不變。
當網域出現在日誌行、憑證透明度報告、電子郵件標頭或付款參考資料中,而您想確認它實際代表哪些 Unicode 代碼點時,以純文字形式讀取 xn-- 名稱就非常實用。這個轉換是無損且可逆的,因此使用相同的 Bootstring 常數重新編碼結果,將能完整重現原始的 ASCII 標籤。
Punycode 標所代表的意義
Punycode 的設計目的只有一個:讓非 ASCII 文字能在僅支援 ASCII 的網域名稱系統中順利傳輸。一個標籤會被分成兩部分 — 已為 ASCII 的基本代碼點,以及需要編碼的非基本代碼點 — 而非基本代碼點會以具自適應偏差值的 delta 編碼方式處理,該偏差值會隨著數值處理而調整。xn-- 前綴是一個標記,表示該標籤的其餘部分是 ACE 編碼,並會在解碼過程中被消耗掉。轉換器所使用的固定常數為:base 36、tmin 1、tmax 26、skew 38、damp 700、initial bias 72,以及 initial code point 128,這些數值與 RFC 3492 中所定義的內容一致。
由於前綴僅在標籤邊界處加入或消耗,多標籤網域會以一個段落為單位逐段處理,並以 ASCII 點作為分隔。對於已完全由基本 ASCII 代碼點組成的標籤,僅會進行小寫轉換,除此之外維持原樣;對於一開始就不含任何非基本代碼點的標,則絕不會為其加上前綴。正是這種逐標籤處理的慣例,使得像 example.xn--bcher-kva.org 這樣的網域會解碼為 example.bücher.org,而不是被合併成一個混亂的單一字串,也讓每個段落在往返轉換之後,都能被單獨檢視或複製。
執行 Punycode 轉 Unicode 的步驟
- 僅貼上網域名稱。Punycode Converter 不接受協定配置、路徑、連接埠、查詢字串或片段。請先去除 https:// 前綴、結尾斜線或路徑段落,再貼上,以確保輸入符合像 xn--bcher-kva.example 或 xn--fiqs8s.example 這樣的裸網域格式。
- 選擇「ASCII-Punycode 轉 Unicode」方向。此操作會反轉編碼流程:消耗每個符合資格標籤上的 xn-- 前綴,並對剩餘的 ASCII 字元執行 Bootstring 解碼。一般標籤會被轉為小寫,除此之外不做任何變更。
- 轉換並檢查每個標籤。每個以點分隔的段落會獨立處理。沒有 xn-- 前綴的標籤會被轉為小寫,除此之外不變,因此解碼後的網域會保留與輸入相同的段落數量與點位置。
- 使用專用按鈕複製結果。複製動作會將轉換後的網域放入剪貼簿,且不含協定配置、結尾斜線或包裹用的引號 — 這正是大多數 API、憑證欄位與註冊管理機構表單所預期的格式。
- 透過目標註冊管理機構或 URL 程式庫進行驗證。此轉換雖然可逆,但並不具備權威性。請將 ASCII 標籤提交給將代管該網域的註冊商,以符合標準的 URL 解析器執行檢查,或套用該註冊管理機構的 IDN 政策,再將其視為已被接受。
解讀結果時避免被相似字元欺騙
成功解碼只能證明輸入是一個格式正確的 Punycode 標籤 — 並不能證明該網域是可信的、可以解析的,或是屬於其拼字看起來所模仿的組織。不同書寫系統的字元可能看起來幾乎完全相同:一個西里爾字母 а 與一個拉丁字母 a 代碼點不同,但在小尺寸下看起來一樣;拉丁字母 o 也與希臘字母 omicron 極為相似。解碼之後,請比對每個看起來像您所熟悉品牌字母的字元之代碼點,並檢查整體書寫系統,而不是僅憑目視判斷。
解碼後的 Unicode 內容也無法說明發音、音情況,或是該名稱是否已被註冊。Punycode 是一種可逆的文字編碼,而不是語言翻譯器或目錄查詢工具。對於高風險的決策 — 例如點擊陌生連結、向電子郵件中的網域匯款,或是評估一筆憑證透明度紀錄 — 請獨立於解碼字元拼寫之外,另行確認註冊人與註冊商資訊。
原始 Bootstring 輸出與瀏覽器顯示內容的差異
瀏覽器與許多註冊管理機構並不會直接對標籤進行 Bootstring 編碼與解碼的傳遞處理。它們會先執行一系列標準化步驟,通常統稱為 UTS #46 對應。這個過程可能會改變標籤中最終出現的代碼點、合併某些字元,或封鎖特定註冊管理機構所禁止的字元。當您比較原始的 RFC 3492 結果與瀏覽器網址列最終顯示的內容時,下表列出您可以預期的主要差異。
| 步驟 | 僅使用原始 RFC 3492 | 搭配 UTS #46 / 瀏覽器對應 |
|---|---|---|
| Unicode 標準化 | 無 — 直接採用所寫入的代碼點 | 通常在編碼前先套用 NFC 或 NFKC |
| 禁用或差異字元 | 以一般 Unicode 代碼點解碼 | 依註冊管理機構政策進行對應、封鎖或替換 |
| 雙向與上下文規則 | 未強制執行 | 在顯示前檢查 IDN 上下文規則 |
| 最終顯示給使用者的形式 | 原始解碼後的 Unicode | 瀏覽器可能顯示不同的拼字或退回 Punycode 形式 |
如果註冊商拒絕了轉換器所產生的結果,請遵循該註冊管理機構的 IDN 政策,而不是手動編輯字元。此處的轉換刻意設計得範圍明確:它僅記錄在標準 Bootstring 常數下的原始標籤轉換,並不保證能與 WHATWG URL Standard 中所述的每個消費者或每個註冊管理機構的規則集,產生完全相同的接受結果。
限制與會被拒絕的輸入
此轉換器刻意設計得範圍明確,以便能給出明確的答案。超出該範圍的輸入會以明確的訊息加以拒絕,而不是被悄悄曲解:
- 空標籤 — 包含連續點或結尾點的網域。
- 格式錯誤的數字 — 以 xn-- 開頭,但其編碼段落中含有非 Bootstring 字元的標籤。
- 無效的 Unicode 純量值 — 解碼過程中產生的代理半段或超出範圍的數值。
- 超過 1,000 個代碼點的輸入 — 任何更大的輸入會在解碼開始前就被拒絕。
在分割之前,作為 CJK 標點使用的句點會先被標準化為 ASCII 點,如此可避免一個外觀相同的輸入意外產生額外的空標籤。實作上是逐一處理 Unicode 代碼點,而非 UTF-16 半段,因此 CJK 或表情符號序列中的輔助字元,在往返轉換中都能保持完整。算術溢位檢查會保護 RFC 3492 中所定義的 delta 乘法與權重累計步驟,這也是為什麼過大的輸入會被拒絕,而不是被悄悄損壞。
轉換通常會改變標的長度,因此 DNS 標籤長度限制與註冊管理機構政策,在轉換後仍然適用。一個語法上有效的 Unicode 標籤,仍可能因為過長而無法透過線路傳送、被您打算使用的註冊管理機構封鎖,或已被他人註冊。請以最終會接受該結果的權威性消費者來驗證最終的 ASCII 形式,並將此轉換器視為大型工作流程中一個可逆的步驟,而不是完整 URL 解析的替代方案。