將表情符號轉換為 Punycode，會把網域標籤內部的 Unicode 碼位轉成一串以 xn-- 開頭、ASCII 相容的字串，因此像 ☕.example 這類名稱就會變成 DNS 相容的 xn--53h.example。Punycode Converter 會在你的瀏覽器中直接以 RFC 3492 Bootstring 演算法逐標籤進行轉換，將表情符號、帶變音符號的拉丁字母、希臘字母或 CJK 字元的非 ASCII 區段保留為單一、具確定性的 ASCII 編碼。每一個以點分隔的標籤會被獨立處理，這表示表情符號可以與像 mail 或 blog 這類純 ASCII 標籤並存而不會互相干擾。由於表情符號可能出現在基本多文種平面（像是 ☕ 範例位於 U+2615，遠低於 U+FFFF），也可能出現在 U+FFFF 以上的輔助平面，編碼器會逐碼位而非逐 UTF-16 半碼元進行迭代，因此對 Bootstring 演算法來說，單一表情符號碼位算作一個輸入字元，輔助平面中的碼位也能保持完整。對於相同的輸入，結果是可重現的，因為 RFC 常數——基底 36、tmin 1、tmax 26、skew 38、damp 700、初始偏差 72，以及初始碼位 128——都是預先固定而非由使用者控制的。Punycode Converter 在本機執行每一個步驟，因此你貼上的 URL 或主機字串絕不會離開這個頁面。

convert emoji to punycode
convert emoji to punycode

把表情符號轉成 Punycode 時會發生什麼事

Punycode 是讓非 ASCII 字元——表情符號、帶變音符號的拉丁字母、希臘字母、西里爾字母或 CJK 表意文字——能夠存在於主機名稱中而不破壞 DNS 的編碼層；過去的 DNS 僅接受 ASCII 字母、數字與連字號。RFC 3492 定義的 Bootstring 演算法是可逆的：它會把每一個非基本碼位打包成一串附加在標籤基本字元後面的 delta 尾段，並在你執行解碼器時將其還原。對於像 U+1F4A9 這類輔助平面中的表情符號來說，以碼位迭代代表每一個表情符號都算作單一輸入字元，而不是 JavaScript 引擎內部以 UTF-16 代理對呈現的那兩個碼元。

這個轉換器是以個別標籤為基礎來實作此邏輯。當你在選擇 Unicode-to-ASCII 後貼上 ☕.example，工具會在每一個 ASCII 點上切割字串，將任何 CJK 樣式的句點統一為相同的 ASCII 點，然後先處理 ☕。在那個標籤內部，由於含有至少一個非基本碼位，因此會加上 xn-- 前綴；第二個標籤 example 是純 ASCII，因此只會被轉為小寫後原樣輸出。最終結果是 xn--53h.example，可以直接交給 DNS 解析器、憑證授權中心，或任何需要 ASCII 相容格式的 URL 函式庫。

表情符號如何成為網域標籤

DNS 協定在遠早於表情符號出現之前，就已標準化於字母、數字與連字號組成的 ASCII 字元集。國際化網域名稱（IDN）藉由在離開用戶端應用程式之前，先以 Punycode 編碼每一個 Unicode 標籤來擴充這個系統。當註冊商儲存 ☕.example 時，註冊資料庫會保留 ASCII 格式的 xn--53h.example，並將 Unicode 形式公開用於顯示。為同一個主機簽發的憑證會以 ASCII 標籤進行比對，瀏覽器中的比對演算法則套用 IDNA 規則，決定哪些 Unicode 形式對應到該儲存的 ACE 標籤。

Punycode 既不是翻譯、也不是音譯，更不是安全檢查。把 xn--53h.example 轉回 ☕.example 雖然能還原拼字，但無法告訴你任何關於發音、擁有權或可信度的資訊。兩個看起來幾乎相同的字元——拉丁字母與全形變體，或是 Unicode Security Mechanisms 資料中收錄的易混淆字對——可能會編碼成不同的 Punycode 字串，或在對抗情境中編碼成視覺上的近似字。請把每一個解碼後的標籤當作需要目視檢查的素材，而不是具權威性的聲明。

如何把表情符號轉換為 Punycode

請依照下列步驟，使用 Punycode Converter 從含有表情符號的 Unicode 網域中，取得可安全用於 DNS 的 ACE 字串。

  1. 只將網域名稱貼到輸入框中。請去除任何通訊協定（https://）、路徑（/path）、查詢字串（?q=）、連接埠（:443）或片段（#section）；這個工具預期的是以 ASCII 點分隔的純主機字串。CJK 樣式的句點會在切割輸入之前先被統一為一般的 ASCII 點。
  2. 選擇轉換方向。若你的輸入是可讀的 Unicode 網域（例如 ☕.example 或 🐱.cafe），請選擇 Unicode-to-ASCII。若你的輸入已經以 xn-- 開頭，而你想還原顯示時的拼字，請選擇 ASCII-Punycode-to-Unicode。
  3. 提交轉換。工具會在每一個點上切割輸入、識別每一個標籤，並使用固定常數 base 36、tmin 1、tmax 26、skew 38、damp 700、初始偏差 72，以及初始碼位 128，對每個標籤執行 RFC 3492 Bootstring。
  4. 不只讀取結果中的第一個標籤，而是讀取每一個標籤。任何含非基本碼位的標籤都會加上 xn-- 前綴；已經是純 ASCII 的標籤則會被轉為小寫後原樣輸出。如果表情符號出現在多個標籤中，每個標籤都會被獨立轉換。
  5. 使用複製控制項來複製轉換後的網域。輸出內容僅涵蓋已轉換的主機；複製的文字中不會附加通訊協定、結尾斜線或查詢參數。
  6. 以最終會使用這段字串的系統來驗證結果。將 ASCII 形式交給 URL 函式庫，或貼到目標註冊商的控制面板，以確認它能被接受、長度符合資格，並在前往解碼後的 Unicode 形式前檢查是否有近似字元。

如果轉換器回報錯誤而非結果，最常見的原因包括內嵌了通訊協定、兩個連續點所產生的空標籤、夾帶空白字元、非 Unicode 純量值，或是某個標籤合併後的碼位總數超過一千個。

解讀輸出：xn-- 前綴與標籤邊界

Bootstring 演算法會把標籤開頭所有基本 ASCII 字元原封不動地保留，再為每一個非基本碼位附加一段長度可變的 delta 尾段。因此 xn-- 前綴只是一個標記，而不是酬載；它向消費者表示這個標籤的其餘部分必須經過解碼。像 blog 或 mail 這類純 ASCII 標籤不會帶有 xn--，會原樣保留；只有含有至少一個非基本碼位的標籤才會獲得這個前綴。

由於標籤是以點切割並獨立處理的，因此混用表情符號與純 ASCII 並不困難。以 🐶.my.blog 為例，轉換器會產生三個輸出標籤：一個對應表情符號的 xn-- 標籤，接著是維持小寫不變的 my，最後是維持小寫不變的 blog。xn-- 之後的字元數會有所不同，因為每個非基本碼位會在編碼尾段中佔去一個 delta；輔助平面的表情符號與基本平面的帶變音符號字母，各自都只佔用一個 delta，即使它們的 UTF-16 寬度並不相同。

RFC 3492 常數作用轉換器使用的值
Base基本碼位數與數字字母表大小36
tmin可變長度整數的最小偏差門檻1
tmax可變長度整數的最大偏差門檻26
Skew在每個插入步驟之間套用的調整值38
Damp用於偏差成長的阻尼因子700
Initial bias編碼或解碼開始時的偏差72
Initial code point第一個非基本碼位的索引128

這些常數無法透過轉換器介面調整。如果你更改它們，即使輸入相同也會產生不同的 ACE 字串，因此為了可攜性，必須沿用 RFC 的預設值。算術溢位檢查會保護 delta 的乘法與權重累積，即使編碼器在輸入極大時可能陷入迴圈，也能讓輸出保持有限。

拿到轉換後的字串後該怎麼做

請將轉換器的輸出視為原始的 RFC 3492 標籤轉換結果。然而，瀏覽器引擎與大多數具備 IDNA 意識的函式庫會在委派給 RFC 3492 之前，先執行 Unicode 技術標準 #46 的映射、標準化與情境規則，這代表它們最終的 ACE 標籤可能會與這個工具的輸出相差幾個字元。當這種情況發生時，函式庫才是主機實際儲存在線上內容的真相來源，而註冊商公布的 IDN 政策才是該標籤是否可註冊的真相來源。如果註冊商拒絕某個標籤，請遵循該註冊商的政策，而不是隨意調整字元以圖取得接受。

在註冊商與 URL 函式庫對 ASCII 形式達成共識之後，請在前往解碼後的 Unicode 網域之前，先檢查它是否有同形異義字（homograph）風險。來自不同書寫系統的兩個字元可能看起來幾乎一模一樣，而單純的轉換並不會標示出這種衝突。請將目視檢查搭配對營運該網域之組織的獨立查證，以及對連線時實際交涉出的憑證內容進行仔細審視。Bootstring 本身的技術定義收錄於 RFC 3492，其中固定了上述常數與可變長度整數編碼方式。

限制與轉換器不做的事

這個轉換器專注於每個標籤一次的可逆轉換，並拒絕執行相關的其他操作。只能貼上網域名稱——通訊協定、路徑、連接埠、查詢字串與片段都不在處理範圍內。空標籤、兩個連續點、xn-- 序列中格式錯誤的數字、無效的 Unicode 純量值，以及碼位數超過一千的輸入，都會以明確的錯誤被拒絕，而非部分處理。此工具不會連線 DNS、執行 WHOIS 查詢、測試註冊可用性、在 CJK 句點合併之外進行 Unicode 標準化、套用 UTS #46 映射，也不會解析百分比編碼。即使是在解碼模式下，它也只處理帶有 xn-- 前綴的標籤；從未被編碼器修改過的標籤會被原封不動地保留。

這些限制是有意為之。這個可逆編碼層的設計目標是小到足以讓你能驗證它的行為，卻又大到足以讓你能把輸出直接交給負責 URL 解析、IDN 政策與安全政策且符合標準的下游系統。若需要更完整的 IDN 教學——涵蓋標準化、近似字清單與憑證處理——請參閱專屬指南：將網域轉換為 Punycode 以相容 DNS。語法上編碼完成的標籤仍可能太長、被保留、遭到封鎖或已被註冊，因此請在把最終的 ASCII 名稱視為可部署之前，先以具權威性的接收端進行驗證。

延伸閱讀：將 IDN 網域逐標籤轉換為 Punycode 的步驟。