Punycode 是 RFC 3492 編碼方式，能將國際化域名（IDN）標籤轉換成 Domain Name System 實際在線路上傳輸的純 ASCII「xn--」形式。DNS 協定在網路變得多語言化之前就已經寫定了，當時它只支援一組狹窄的字元集合——基本 ASCII 字母、數字和連字號——因此任何非 ASCII 標籤在被查詢、快取或由憑證機構簽署之前，都必須先折疊進這個有限的字母集內。Punycode 以可逆的方式完成這個折疊：給定 Unicode 拼寫「bücher.example」，合規的編碼器會回傳「xn--bcher-kva.example」；反之，給定 ASCII 形式，解碼器便能精確還原原始 Unicode，包括那些 UTF-16 會切開的 U+FFFF 以上的碼點。編碼是按每個標籤分別套用的，「xn--」前綴作為標誌，表示後面接的是 ASCII 相容編碼（ACE）形式，且該演算法是完全確定性的，這正是為什麼每個符合標準的實作都會對同一個 Unicode 輸入產出相同的正典 ASCII 形式。那種確定性正是讓 Punycode Converter 能夠產出任何其他 RFC 3492 實作都能重現的輸出結果。
Punycode 在 DNS 中實際做了什麼
Punycode 背後的核心概念是分離性。一個域名是一串以半形句點分隔的標籤序列，而只有標籤本身會被編碼；句點保留為 ASCII 句點，使得域名的整體結構得以保留。「xn--」前綴是個標誌，表示標籤的其餘部分是 ASCII 相容編碼（ACE）形式，它會附加到每一個含有非 ASCII 碼點的標籤上。純 ASCII 標籤——例如「example」、「com」或任何僅由字母、數字和連字號寫成的標籤——只會被轉成小寫並保持不變。這就是為什麼這個前綴只會出在真正需要的標籤上，也為什麼像「shop.bücher.example」這樣的名稱會變成「shop.xn--bcher-kva.example」而不是一整串 ACE 文字。
這種編碼同樣是完全可逆的。每個 Punycode 字串都帶有足夠的資訊來還原產生它的精確 Unicode 碼點，這就是為什麼「xn--bcher-kva」總是解碼成「bücher」而不是某個剛好共用幾個字元的其他拼寫。這種可逆性是 RFC 3492 所定義的 Bootstring 演算法的特性，也正是它讓註冊管理機構、瀏覽器和憑證機構在需要時都能達成同一個正典 ASCII 形式。少了那個共享的正典形式，DNS 就無法判斷「bücher」和「b\u00FCcher」究竟是同一個標籤還是兩個不同的標籤——Punycode 強制給出單一答案。
用白話說明 Bootstring 演算法
RFC 3492 規定了一個具有一組小型固定常數的 Bootstring 演算法。這些常數並非工具可以調整的旋鈕；它們是規格的一部分，任何更動它們的實作都會產生不同（且不相容）的 ASCII 形式。這些值分別為：
| 常數 | 值 | 用途 |
|---|---|---|
| base | 36 | 編碼器在每個變動長度整數位數上可區隔的基本碼點數量。 |
| tmin | 1 | 一般情況下 delta 編碼的最小偏誤門檻。 |
| tmax | 26 | 一般情況下 delta 編碼的最大偏誤門檻。 |
| skew | 38 | 當偏誤的增長速度可能超過編碼值時所套用的調整量。 |
| damp | 700 | 在每個 delta 編碼的碼點之後，套用於偏誤的阻尼因子。 |
| initial bias | 72 | 在第一個非基本碼點被編碼之前所使用的起始偏誤。 |
| initial code point | 128 | 納入 delta 編碼考量的第一個非基本 Unicode 碼點。 |
白話來說，編碼器一次走過一個 Unicode 碼點，依序處理標籤。現有的基本 ASCII 字元會先原樣複製過去，只有非 ASCII 碼點會被編碼成變動長度的 delta——這些數字描述了每個新非 ASCII 碼點相對前一個碼點的位置。隨著處理的值越多，偏誤項會跟著調整，這讓演算法能將密集的相關文字系統緊密打包，同時為稀疏的文字系統保留空間。最後的結果便是一段由基本字母、數字和連字號組成的 ASCII 字串，編碼完成後前綴加上「xn--」。解碼器則是其反向操作：消耗那些 delta、套用相同的自適應偏誤，並重建出原始的 Unicode 純量值。
由於演算法是疊代完整的碼點而不是 UTF-16 程式碼單元，輔助字元——位於 U+FFFF 以上的表情符號與罕見的歷史文字——能保持完整而不會被無聲地切成兩半。針對 delta 乘法與權重累加所做的算術溢位檢查，則能在標籤含有大量非 ASCII 碼點時維持實作的穩定性。如需完整的參數參考以及 tmin、tmax 的邊界行為說明，請參閱 Punycode Converter Cheat Sheet: RFC 3492 Rules and Limits。
如何使用 Punycode Converter
Punycode Converter 會在瀏覽器本地處理單一域名，並公開呈現原始的 RFC 3492 轉換結果。獲得乾淨結果的步驟如下：
- 在輸入框中僅貼上一個域名——不要包含通訊協定、路径、查詢字串、通訊埠或片段。CJK 文字中常用的 Unicode 句點會在標籤切割之前先正規化為 ASCII 句點。
- 選擇方向。當你需要為 DNS 欄位、憑證簽署請求或主機名稱驗證器取得一個 xn-- 名稱時，請使用 Unicode-to-ASCII。當 xn-- 標籤已出現在 URL、記錄檔或憑證中，而你想查看它實際的拼寫時，則請使用 ASCII-Punycode-to-Unicode。
- 進行轉換。工具會以句點切分輸入，並將每個標籤分別執行 Bootstring 演算法。含有非 ASCII 碼點的標籤會加上 xn-- 前綴；純 ASCII 標籤則會被轉成小寫並維持原樣。解碼模式僅針對真正帶有該前綴的標籤套用 Bootstring 解碼。
- 逐一檢查每個標籤。確認只有預期中的標籤帶有「xn--」，確認 ASCII 部分的讀法仍與名稱其餘部分一致，並確認沒有任何標籤是空的或被截斷。
- 複製結果並交由目標註冊管理機構、憑證機構或 URL 程式庫進行驗證。如果註冊商拒絕該名稱，請遵循該註冊管理機構的 IDN 政策，而不是盲目地重新編碼或替換字元。
Converter 接受與拒絕的輸入
這個工具刻意比完整的瀏覽器 URL 解析器來得嚴格。它不接受像「https://」這類通訊協定，不會解析路径、通訊埠、查詢字串或片段，也不會執行百分號解碼、DNS 解析、註冊可用性測試，或聯絡註冊管理機構。貼上一個像「https://bücher.example/page」這樣的完整 URL 時，可能會被拒絕或視為垃圾輸入；請先抽出域名再進行轉換。空標籤、格式錯誤的數字、無效的 Unicode 純量值，以及超過 1,000 個碼點的輸入都會被直接拒絕，以避免轉換過程無聲地產出看起來錯誤的 ASCII 字串。
有幾項慣例值得留意。CJK 文字中常用來取代 ASCII 句點的 Unicode 句點，會在標籤切割之前先正規化為 ASCII 句點。Bootstring 實作疊代的是完整的 Unicode 碼點而非 UTF-16 的一半，因此輔助字元能完整存活下來。標籤長度限制與註冊管理機構政策在轉換後仍然適用——一個語法上有效的 xn-- 標籤仍可能太長、被保留、被封鎖，或根本就尚未註冊，而轉換步驟並不會對這些情況提出任何警告。請將 ASCII 結果複製到權威的消費者端——註冊商的搜尋框、憑證機構的表單，或符合標準的 URL 程式庫——讓那個消費者端做出最終的接受與否決定。
為何解碼後的 Unicode 並不總是安全
Punycode 並不是語言翻譯器。將「xn--bcher-kva」解碼只會告訴你該標籤所代表的 Unicode 拼寫，但不會告訴你該怎麼發音、誰擁有它，或它是否屬於它看似代表的機構。西里爾字母、希臘字母與拉丁字母的字元高度重疊；一個拉丁字母「a」與一個西里爾字母「а」對多數讀者而言看起來一模一樣，其他許多配對也一樣。那種重疊正是同形異義（homograph）攻擊所利用的弱點：以混合文字系統拼寫的域名看起來可能像某個可信賴的品牌，實際上卻指向完全不同的位置。
因此，一次有效的轉換絕對無法證明一個域名是可信賴的。在存取解碼後的 URL 之前，請仔細比對每個標籤、文字系統與機構。請將這個轉換器視為一個可逆的編碼步驟，而非資安防護層——將反釣魚檢查、白名單與註冊管理機構驗證與原始編碼工作分開處理。Punycode Converter 完全在瀏覽器內執行，絕不會聯絡註冊管理機構，這正是它能夠安全地用於檢查可疑名稱的原因，但同時也是它無法為你所檢查的內容背書的原因。
為何瀏覽器與註冊商的結果可能不同
原始的 RFC 3492 轉換是 IDN 處理管線中最小的環節。生產環境的 URL 系統通常會在其上額外疊加三個步驟：用於將等價序列折疊為單一正典形式的 Unicode 正規化（通常是 NFC）、用於處理相容字元與大小寫折疊規則的 UTS #46 對映，以及部分註冊管理機構所套用以封鎖特定文字系統、混合文字組合或特定碼點的 IDNA2008 上下文規則。瀏覽器的網址列常常將「xn--bcher-kva」顯示為「bücher」，這是因為瀏覽器在顯示名稱之前已套用了這些層；Punycode Converter 公開呈現的是不含這些層的原始 RFC 3492 標籤，這正是為什麼它的輸出可能與瀏覽器所顯示的不一致。
這也是為什麼註冊商可能拒絕一個這套工具樂於接受的名稱：因為註冊商在原始編碼之上還強制執行了 IDNA2008 以及其專屬的逐文字系統政策，而轉換器僅呈現編碼本身。WHATWG URL 標準 文件化了瀏覽器所套用的額外步驟，當原始 Punycode 與瀏覽器接受結果之間出現落差時，該文件就是正確的參考依據。當註冊商拒絕一筆轉換結果時，請閱讀該註冊管理機構公布的 IDN 政策並調整 Unicode 輸入以符合政策——不要重新編碼或手動編輯 ASCII 輸出。請將轉換器視為文件化的可逆步驟，並將政策面的決定留給註冊管理機構自身的規則。