🌐 Punycode / IDN 转换器

国际化域名(如日本語.jp)与 Punycode(如 xn--wgv71a119e.jp)双向转换。支持粘贴完整 URL,按标签自动判定。

完全免费无需注册浏览器内完成 5 种语言深色模式

🔒 关于隐私

・所有处理均在您的浏览器中完成
・输入数据绝不会发送到任何服务器

输入(域名或 URL)

输出 (Punycode ⇄ Unicode)

📖 工作原理

输入包含点号时,按标签分别转换。
含 https:// 等协议和路径的 URL 仅转换主机部分。
仅包含 ASCII 的标签自动识别为「decode (xn-- → Unicode)」，包含非 ASCII 的标签识别为「encode (Unicode → xn--)」。
使用纯 JS 实现 Bootstring (RFC 3492),无需外部库。

📖 常见的坑

使用 RFC 3492 的 Bootstring 算法在国际化域名 (IDN) 与 Punycode 之间双向转换。它按标签逐个判断（以点分隔），因此可以直接粘贴整个 URL，只有主机部分会被转换。处理全部在浏览器内完成，输入不会被传输。但这个工具做的只是编码——它不判断该域名能否注册、是否安全。IDNA2008 与 UTS-46 施加的字符限制、混用文字系统的禁令、各注册局自己的规则，都是在这一转换之后的环节另行适用的。

情形	会发生什么	怎么处理
看起来一样却是另一个域名（同形字）	许多文字系统里都有与拉丁字母无法区分的字符。例如 `U+0430 CYRILLIC SMALL LETTER A` 在绝大多数字体中与拉丁字母 `a` 渲染得完全一样。用它作首字母的域名会编码成 `xn--pple-43d.com`，但地址栏里可能以与真品相同的拼写显示。浏览器会在「同一标签内混用了文字系统」「与显示语言不一致」等条件下切换为 Punycode 显示，但判定标准因浏览器而异，还取决于用户的语言设置。也就是说，你自己屏幕上看着是普通拼写，这一点什么也保证不了。	`xn--` 形式是你唯一的判断依据。把可疑链接粘贴到这里，读输出。如果一个看起来是纯 ASCII 的域名却给出了 `xn--` 结果，说明其中混入了非拉丁字符。反方向也一样：粘贴 `xn--` 形式就能读出真实字符串。若要在组织层面防御，请用机器而不是眼睛来过滤——在邮件网关或聊天接收端对含 `xn--` 的 URL 发出告警，并为业务实际使用的域名维护允许列表。人眼审查在原理上就是可以被绕过的，所以只靠培训不构成防御。
能转换与能注册、能访问是两回事	编码是机械操作，因此任何字符串的转换本身都会成功。但 DNS 那一侧另有限制。单个标签 63 字符的上限针对的是「编码之后」的长度，`xn--` 这 4 个字符也算在内。由于假名和汉字每个平均膨胀为 1.2〜1.5 个字符，中日文的实际上限大约是 15〜20 个字。此外，表情符号域名在 IDNA2003 下能通过，在 IDNA2008 下被禁止，如今只有少数 TLD 仍然接受。按规范，大写字母和全角英数应先用 UTS-46 归一化再编码，但这个工具原样编码你输入的字符——全角的 `Ａ` 不会变成 `a`，而是作为非 ASCII 字符被编码。	DNS 看到的永远只有 `xn--` 形式。要确认可达性，请把转换结果原样交给 `dig xn--wgv71a119e.jp` 或 `whois xn--...`。用 Unicode 形式查询失败时，你无法区分那是「未注册」还是「工具不支持 IDN」。长度确认同理，该数的是转换之后的字符数——输出超过 63 个字符，这个域名在任何注册商处都注册不了。真正购买之前，请查阅注册局的 IDN 政策（可用字符表），而不是注册商的搜索框，因为各 TLD 允许的字符集并不相同。
在邮件、证书与日志中两种写法会分裂	对 DNS 来说，Unicode 形式与 `xn--` 形式是同一个域名，但对任何比较字符串的机制而言，它们是两个不同的值。TLS 证书的 SAN 里装的是 `xn--` 形式，因此拿 Unicode 字符串去比对会不匹配。访问日志、分析工具、Search Console 记录哪一种形式因实现而异，于是同一个站点被拆成两行。邮件更麻烦：域名部分可以是 `xn--`，但要让本地部分（@ 左侧）使用非 ASCII 则需要 SMTPUTF8 (RFC 6531)，而不支持它的 MTA 至今并不少见。	存储和比较只用 `xn--` 形式，Unicode 形式仅在界面展示时还原——在一个地方彻底执行这一条，是唯一真正的解法。写入数据库之前、写日志之前、交给外部 API 之前，都归一化为 `xn--`。「只归一化一侧」是最糟的结果：重定向和链接会无限循环，同一个用户会显示成两个。Search Console 则以两个资源都登记再合并数字最为稳妥。若要处理邮箱地址，决定暂不支持非 ASCII 本地部分并在表单上写明，比含糊地接受、到发送时才失败要厚道得多。

Punycode 既不是加密也不是混淆。Bootstring 是可逆编码，没有密钥也没有随机数——任何人一秒钟就能还原。凡是以「xn-- 所以读不懂」为前提的设计，最终一定会崩。按标签处理还有第二个后果：攻击方同样可以利用它。在 example.com.xn--.... 这类写法中，真域名被当作子域名放在左侧，而 xn-- 只出现在最右边的标签里。决定域名归属的永远是最右侧（紧邻 TLD）的那个标签，它左边写着什么都无关紧要。判断主机名时，请务必从右往左读。

📖 使用方法

1

粘贴域名

输入国际化域名或 Punycode 形式。也可粘贴完整 URL。
2

查看转换结果

含非 ASCII 则编码为 xn--,纯 ASCII 则解码为 Unicode。
3

复制使用

点击复制按钮。可直接用于 WHOIS、DNS 和邮件服务器设置。

❓ 常见问题

什么是 Punycode？

一种用纯 ASCII 表示 Unicode 的 DNS 编码(RFC 3492)。

可以转换表情符号域名吗？

技术上可行,但多数 TLD 不再接受表情符号标签。

与浏览器 URL.host 有何不同？

浏览器实现不一致。本工具严格遵循 RFC 3492。

🔗 相关工具

🐛 此工具出现问题了吗？

免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。