Punycode 是 RFC 3492 Bootstring 編碼，會將非 ASCII 的 Unicode 碼點對應到網域名稱系統接受的基本 ASCII 字母、數字與連字號。它以標籤為單位逐個處理，先複製所有 ASCII 字元，再把其餘每個碼點編碼成變動長度的 delta，同時由一個自適應偏差參數調整新字元的成本。這些常數由規格固定，很少變動，這也是為什麼單一速查表就能涵蓋你幾乎所有會遇到的轉換場合。請把 Punycode 轉換器 當作標籤層級轉換的速查表:貼上網域、選擇方向，工具就會在本地以文件記載的 Bootstring 常數處理每個標籤，僅在含有非 ASCII 碼點的標籤上加上 xn-- 前綴，並在格式錯誤的輸入可能悄悄產生錯誤結果之前先加以拒絕。對所宣告的原始 RFC 3492 慣例而言，輸出是確定性的，這讓你可以輕鬆地與參考實作或你信任的程式庫進行比對。
RFC 3492 Bootstring 常數一覽
RFC 3492 規格 將 Bootstring 演算法綁定在七個數值常數上。Punycode 轉換器使用相同的數值，因此下表同時也是工具內部運算的速查表。
| 常數 | 數值 | 在演算法中的角色 |
|---|---|---|
| base | 36 | 用於 delta 值變動長度整數編碼的基數 |
| tmin | 1 | 偏差自適應開始生效的下限門檻 |
| tmax | 26 | 偏差停止再向上自適應的上限門檻 |
| skew | 38 | 套用於偏差公式的阻尼項 |
| damp | 700 | 每輸出一個字元後套用的偏差乘數 |
| initial bias | 72 | 在任何 delta 輸出前的起始偏差值 |
| initial code point | 128 | 考慮的第一個非基本碼點(第一個非 ASCII) |
在這些常數之上還有兩項實作細節值得放在同一頁中。首先，轉換器是以 Unicode 碼點而非 UTF-16 碼元進行迭代，因此 U+FFFF 以上的輔助字元能在往返轉換後完整保留。其次，算術溢位檢查會保護 delta 乘法與權重累積，避免當中間值接近執行環境整數範圍上限時，過長的標籤悄悄產生錯誤的編碼字串。
標籤前綴與邊界規則
Punycode 一次只處理單一標籤。句點用來分隔標籤，本身不屬於編碼內容，因此邊界的速查表很簡短:依句點切分、各段分別編碼或解碼、再以 ASCII 句點重新接合。在 CJK 文字中出現的 Unicode 句點會在處理標籤之前先正規化為 ASCII 句點，使邊界規則在任何類型句點下都保持一致。
只有包含至少一個非 ASCII 碼點的標籤，在編碼後才會加上 xn-- 前綴。普通的 ASCII 標籤只會被轉為小寫，其餘維持不變 — 不加前綴、不補位、也不做任何轉換。在解碼模式下，只有已經帶有 xn-- 前綴的標籤才會送進 Bootstring 解碼，其餘則原封不動通過。這就是完整的邊界契約，也正是為什麼像 bücher.example 這種多標籤網域，編碼後會變成 xn--bcher-kva.example，而不是每個標籤都加上前綴。
可接受的輸入與被拒絕的邊界情況
工具可接受內容的速查表刻意訂得很窄:
- 單純的網域名稱，個別標籤上可有可無 xn-- 前綴。
- 位於有效純量值範圍內的 Unicode 碼點，包括 U+FFFF 以上的輔助字元。
- 以 ASCII 句點分隔，或以正規化為 ASCII 句點的 Unicode 句點分隔的標籤。
- 所有標籤合計的輸入總量不超過 1,000 個碼點。
對下列輸入，轉換器會直接拒絕執行並回報明確錯誤，而不是猜測:
- 空標籤，包括前導句點、尾端句點或連續兩個句點。
- ASCII 標籤中應為 Bootstring 可解碼的數字部分格式錯誤。
- 無效的 Unicode 純量值，包括當作文字傳入的孤立代理對。
- 輸入超過 1,000 個碼點上限，這是用來防止計算失控的保護。
若註冊商或 DNS 端在語法上正確的轉換之後仍拒絕結果，請依該註冊局的 IDN 政策處理，而不是盲目更動字元。標籤長度上限與保留區段規則不在本轉換器的範圍內。
如何把 Punycode 轉換器當作快速參考
- 把單一網域名稱貼到輸入欄位。請不要包含通訊協定、路徑、連接埠、查詢字串或片段 — 本工具只處理網域本身。
- 選擇方向:當網域含有非 ASCII 碼點，而 DNS 或憑證欄位需要 ASCII 形式時，用 Unicode 轉 ASCII;當你想在前往某個 xn-- 網站前先檢視其內容時，用 ASCII-Punycode 轉 Unicode。
- 執行轉換並逐一檢查每個標籤。確認 xn-- 前綴只出現在原本含有非 ASCII 碼點的標籤上，且一般 ASCII 標籤只是被轉為小寫。
- 用複製按鈕複製轉換後的網域。回傳的內容就是轉換後的網域字串本身，不會附上通訊協定或尾端斜線。
- 以權威端點驗證結果 — 例如目標註冊局、符合標準的 URL 程式庫，或兩者皆用 — 並在把這個名稱視為可信之前，逐一比對每個標籤、文字系統與所屬機構。
編碼與解碼模式快速參考
兩種模式回答的是不同的問題。下表摘要整理何時該使用哪一種，讓你不必重讀整份規格。
| 使用編碼模式的時機 | 使用解碼模式的時機 |
|---|---|
| DNS 區域檔、憑證簽署請求或 API 欄位只接受 ASCII。 | 你從記錄檔、工單或電子郵件收到一個 xn-- 名稱，想讀出它的內容。 |
| 你需要確認經原始 RFC 3492 編碼後，註冊局實際收到的精確 ASCII 標籤。 | 你在前往網站前，要稽核不同文字系統中形似的字元。 |
| 你正在除錯某個標籤，其 Bootstring 輸出應與測試套件中的固定樣本一致。 | 你想驗證 U+FFFF 以上的輔助字元在往返轉換後是否完整保留。 |
解碼模式只對已經帶有 xn-- 前綴的標籤套用 Bootstring 解碼，因此同一筆輸入中的普通 ASCII 標籤會原封不動通過。如需更深入地了解如何閱讀 xn-- 標籤，請參考 將 Punycode 轉為 Unicode:讀懂 xn-- 標籤。
當瀏覽器與原始 RFC 3492 不一致時
實際運作的 URL 系統 — 包括所有現代瀏覽器 — 在把標籤交給 Bootstring 編碼器之前，會先套用 UTS #46 對應、Unicode 正規化，以及與情境相關的 IDN 規則。Punycode 轉換器刻意不執行這些步驟。它呈現的是原始 RFC 3492 的標籤轉換，這代表瀏覽器最後顯示的結果仍可能與本工具印出的不同。
發生這種情況時，請把轉換器的輸出視為正式的原始編碼，而把瀏覽器的顯示視為對應後的版本。若註冊商拒絕該標籤，請依該註冊局的 IDN 政策處理。不要為了強迫過關而自行捏造字元:一次合法的轉換並不代表這個名稱就可註冊、只保留給你，或受到擁有該尾碼的註冊局信任。
若要處理完整的應用程式 URL，請交由符合標準的 URL 程式庫處理通訊協定、百分比編碼、路徑、查詢字串與片段。本轉換器適用於標籤本身;標籤以外的部分屬於 URL 解析器的職責。
解碼後的形似字元
解碼一個 xn-- 名稱會顯示它所代表的 Unicode 拼寫。它並不會告訴你這個字該怎麼唸、誰擁有這個網域，或這些字元是否屬於它們看似代表的機構。拉丁、希臘、斯拉夫以及 CJK 碼點在視覺上都可能極為相近而造成誤判，這正是同形異義攻擊所依賴的表面。
請用解碼後的形式，把該文字系統與你預期的機構相互比對 — 德國的銀行一般不會註冊以斯拉夫字母拼寫的名稱;日本的零售商一般也不會發布完全由看起來像日文的拉丁字元構成的網域。請把這次轉換視為眾多訊號之一:合法的 xn-- 輸出是必要條件，而不是充分條件，不足以單獨保證某個網域可以安全瀏覽或值得信任。
若你在權衡各種選項，XOR 加密線上速查表:格式與金鑰 對此有詳細說明。