Punycode / IDN 変換

Punycode とは？#

ドメインネームシステム（DNS）は ASCII の上に構築されました——字母 A-Z、数字、ハイフンです。では、ブラウザは 中文.com や münchen.de のように、そのアルファベットに含まれない文字を持つドメインをどう解決するのでしょう？ 答えがPunycode（とその周囲の IDN フレームワーク）です——各非 ASCII ラベルを xn-- というプレフィックスで始まる ASCII セーフな形に変える可逆エンコードです。DNS が見るのは xn--fiq228c.com だけですが、ブラウザはあなたに 中文.com を表示します。

このツールは両方向に変換します:

• Unicode → Punycode は Unicode のドメインやメールを受け取り、DNS と証明書が実際に運ぶ xn-- 形式を生成します。各ラベルは独立して変換されます——münchen.中文.com は xn--mnchen-3ya.xn--fiq228c.com になり、末尾の .com はすでに ASCII なのでそのまま残ります。
• Punycode → Unicode はその逆で、xn-- ラベルを人間が読めるスクリプトに戻します。

メールも扱えます。ツールは @ を検出し、ドメイン部分だけを変換し、ローカル部分（メールボックス名）はそのまま残します——だから Büchner@中文.com は Bü[email protected] になり、文字列全体の変換で壊されることはありません。

使い方#

1. 左上の切り替えでUnicode → PunycodeまたはPunycode → Unicodeを選びます。入力に xn-- ラベルがあることに気づくと、ツールは方向を提案することもあります。
2. 入力ペインにドメインまたはメールを貼り付けます。ヘッダーは、それがドメインかメールかとして認識されたかを示します。
3. 変換結果が出力ペインを埋めます。コピーで取り出します。
4. ペインの下のラベル別の内訳表は各ラベルとそれが何になったかを示します——長いドメインが複数の非 ASCII ラベルを持ち、一部だけが変わったときに便利です。
5. 出力 → 入力を使うと出力を入力に戻して方向を反転させ（手軽な往復チェック）、サンプルは münchen.中文.com を読み込み、クリアはリセットします。

主な特徴#

• 両方向、各ラベルは独立。 すべてのラベルが独立して変換され、内訳表はどれが変わり、どれが ASCII のまま残ったかを正確に示します。
• メール対応。 単一の @ が検出されるとメールボックス名は保護され、ドメイン側だけがエンコードされます。複数の @ を持つ入力は、結果を黙って壊すのではなく、明確なメッセージで拒否されます。
• 区切り子の正規化。 全角ドット ．、句点 。、半角 ｡ はいずれも IDN における本来の ASCII . として扱われるため、貼り付けたテキストが壊れません。
• 不正入力に厳密。 悪い xn-- ラベル（例えば xn--!!）は、間違ったドメインを生成するのではなく、問題のラベルを指すきれいなエラーを起こします。
• 範囲に正直。 ツールの下の準拠メモは、これが Punycode エンコードとマッピングステップを実装していると率直に述べます——完全な IDNA2008 妥当性チェッカーではないため、技術的に無効な ACE ラベルでもここではデコードされることがあります。

実例#

Unicode → Punycode で変換すると、プレースホルダ münchen.中文.com は次のようになります:

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

内訳は 3 つのラベル、そのうち 2 つが変換されたことを示します: münchen → xn--mnchen-3ya、中文 → xn--fiq228c、.com はすでに ASCII なのでそのままです。Punycode → 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]   (メール: メールボックス名は保持)

最後の 1 つが人が陥りやすいケースです——素朴なツールは文字列全体をエンコードしてアドレスを壊します。ここでは @ の後のドメイン部分だけが変わります。

よくある質問#

絵文字ドメインがこれほど短い xn-- ラベルに変換されるのはなぜですか？#

😂.com のような 1 文字絵文字ドメインが xn--g28h.com になるのは、Punycode が、非 ASCII 文字 1 つの後に ASCII が続くラベルに対して極めてコンパクトだからです——非 ASCII 文字の位置とコードポイントを ASCII に対する相対でエンコードするため、1 文字ラベルにはごくわずかなバイトしか要りません。より長く多様な非 ASCII ラベルはより長い ACE 文字列を生成します。

出力が入力と同じに見えます——何か起きましたか？#

入力のすべてのラベルがすでに純粋な ASCII（例えば example.com）なら、エンコードすべきものはなく、出力は入力と等しくなります。内訳表が信頼できる指標です——出力 が 入力 と一致するラベルは、その必要がなかったため変換されていません。

メールを貼り付けたがローカル部分が変換されませんでした。それは正しいですか？#

はい、意図的です。国際化メール（SMTPUTF8）はメールボックス名に UTF-8 を許しますが、一般的なケースでは xn-- への変換は間違いです——ローカル部分は DNS 名ではなく、Punycode で解決されません。このツールは DNS セーフでなければならない部分、すなわちドメイン側だけを変換します。これも、複数の @ が拒否される理由です——「ドメイン側」が曖昧になるからです。

ASCII 形式を使って任意のドメインを登録・解決できますか？#

モダンなブラウザやリゾルバによる解決なら、はい。登録については、ルールはより厳格です——IDNA2008 は、古いマッピング（IDNA2003）が許していた特定の文字や正規化を排除しています。このツールは忠実にエンコードしますが、完全な IDNA2008 妥当性検査は行わないため、ここで問題なくエンコードされる文字列でもレジストラに拒否されることがあります。迷ったら、レジストラの照会ツールで確認してください。