Punycode / IDN 域名转换

什么是 Punycode？#

域名系统（DNS）当初是建在 ASCII 之上的——只有 A-Z、数字和连字符。那么浏览器是怎么解析 中文.com、münchen.de 这种字符根本不在这个字母表里的域名的？答案就是 Punycode（以及围绕它的 IDN 国际化域名框架）：一种可逆编码，把每个非 ASCII 的标签变成一个以 xn-- 开头的 ASCII 安全形式。DNS 实际看到的永远是 xn--fiq228c.com，浏览器再显示成人能读的 中文.com。

本工具双向转换：

• To ASCII 接收一个 Unicode 域名或邮箱，产出 DNS 和证书真正承载的 xn-- 形式。每个标签独立转换——münchen.中文.com 变成 xn--mnchen-3ya.xn--fiq228c.com，结尾的 .com 因为已经是 ASCII 而原样保留。
• To Unicode 是逆操作：把 xn-- 标签读回人类可读的文字。

邮箱也支持。工具识别 @，只转换域名部分，原样保留本地部分（邮箱名）——所以 Büchner@中文.com 变成 Bü[email protected]，而不会把整串一起搅烂。

怎么使用#

1. 用左上角的 To ASCII / To Unicode 开关选方向。当它注意到你输入里有 xn-- 标签时，还会建议一个方向。
2. 把域名或邮箱粘进 输入 框。头部会显示它被识别成 domain（域名）还是 email（邮箱）。
3. 转换结果填进 输出 框，点 复制（Copy）取走。
4. 两框下方的 逐标签明细表 展示每个标签变成了什么——当域名很长、非 ASCII 标签有好几个、但只有部分发生变化时特别有用。
5. 点 交换（Swap）把输出挪回输入并翻转方向（快速做个往返校验），示例（Sample）载入 münchen.中文.com，清空（Clear）重置。

主要特性#

• 双向、逐标签独立。 每个标签单独转换，明细表清楚地标出哪些变了、哪些仍是 ASCII。
• 识别邮箱。 检测到单个 @ 时保留邮箱名，只编码域名侧；遇到多个 @ 的输入会直接报错，而不是悄悄把结果弄坏。
• 分隔符归一化。 全角点 ．、中文句号 。、半角 ｡ 在 IDN 里其实都等于 ASCII 的 .，本工具统一按 . 处理，粘贴来的文本不会因此崩掉。
• 对畸形输入严格。 非法的 xn-- 标签（比如 xn--!!）会报清晰错误并指向出问题的标签，而不是产出一个错的域名。
• 如实说明适用范围。 工具下方的合规说明写得很直白：这里实现的是 Punycode 编码和映射步骤——它不是一个完整的 IDNA2008 合规校验器，所以技术上非法的 ACE 标签在这里仍可能被解码。

实例演示#

选 To ASCII，把占位符 münchen.中文.com 转换，得到：

xn--mnchen-3ya.xn--fiq228c.com

明细表显示三个标签，其中两个被转换：münchen → xn--mnchen-3ya、中文 → xn--fiq228c、.com 因为本来就是 ASCII 而不动。翻到 To Unicode，把结果粘回来，就能精确还原 münchen.中文.com。

还有几个值得一看的真实转换：

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   （邮箱：邮箱名保留）

最后一个是常让人栽跟头的场景：图省事的工具会把整串编码、把地址弄坏。这里只有 @ 后面的域名部分会变。

常见问题#

为什么我的 emoji 域名转出来的 xn-- 这么短？#

像 😂.com 这种单字符 emoji 域名会变成 xn--g28h.com，因为 Punycode 对”一个非 ASCII 字符后面跟 ASCII”这种标签编码极其紧凑——它编码的是非 ASCII 字符相对于 ASCII 字符的位置和码点，所以单字符标签需要的字节很少。更长或更杂的非 ASCII 标签才会产出更长的 ACE 串。

输出和输入看起来一样，是没生效吗？#

如果你的输入里每个标签都已经是纯 ASCII（比如 example.com），那就没什么可编码的，输出等于输入。明细表是最可靠的判据：一个标签的”输出”和”输入”相同，说明它没被转换——因为它不需要。

我粘了个邮箱，本地部分没被转换，这正常吗？#

正常，而且是故意的。国际化邮箱（SMTPUTF8）允许邮箱名里出现 UTF-8，但把它也转成 xn-- 在常见场景下是错的——本地部分不是 DNS 名字、也不靠 Punycode 解析。本工具只转域名侧，那才是必须 DNS 安全的部分。这也是为什么输入里有多个 @ 会被拒：“域名侧”在那情况下就不明确了。

我能直接拿这个 ASCII 形式去注册或解析任意域名吗？#

解析方面，任何现代浏览器或解析器都认。注册方面规则更严：IDNA2008 禁用某些字符和归一化，而这些在老的映射（IDNA2003）里是允许的。本工具忠实地完成编码，但不跑完整的 IDNA2008 合规校验，所以一个在这里能干净编码的字符串，注册商那边仍可能拒收。拿不准时，用注册商自己的查询工具再确认一下。