Punycode / IDN コンバーター

つまり Punycode は言語でもフォントでも国コードでもなく — 同じ名前の 2 つの綴りの間の変換です。Unicode 綴りは U ラベル（中文.com、bücher.de）、ASCII 綴りは A ラベル（xn--fiq228c.com、xn--bcher-kva.de）と呼ばれ、国際名を DNS に入れるという発想全体は IDN（国際化ドメイン名）またはその上に築かれた規則群 IDNA と呼ばれます。

これが存在するのは、DNS が 1980 年代初頭、意図的に小さなアルファベットの周りに設計されたためです。DNS を通り、ゾーンファイル、リゾルバーキャッシュ、ログ行、TLS 証明書に入るホスト名は純 ASCII でなければなりません — 回線形式にはそれ以外の場所が単にないのです。Punycode は非常口です：非 ASCII の名前をあたかも ASCII であるかのように移動させ、受信側で元の文字を正確に再構築させます。中国語ドメインがブラウザーで動くのはこのためであり、Unicode 綴りを送れないあらゆる場所で見かける文字列が xn-- なのもこのためです。

入力するもの（U ラベル）	DNS が受け取るもの（A ラベル）	意味
中文.com	xn--fiq228c.com	「中文（中国語）」を意味する中国語
中国	xn--fiqs8s	中国語の「中国」
例え.jp	xn--r8jz45g.jp	日本語の例
bücher.de	xn--bcher-kva.de	ドイツ語の bücher（「本」）
münchen.de	xn--mnchen-3ya.de	ミュンヘン
😂.com	xn--e28h.com	絵文字ラベル — エンコーディング上は有効だが、大半のレジストリでは登録不可

覚えておく価値のある長さ比較：中文 は 2 文字・UTF-8 で 6 バイトですが、xn--fiq228c は 11 ASCII バイトです。Punycode は通常、名前を長くし、短くすることはありません。

bücher を例に 3 つの手順を見てみましょう。このエンジンはブートストリングと呼ばれ、アルゴリズム全体はわずか数十行のコードです（このページのスクリプトで読めます）。

1. 素の文字を先頭に写す。基本 ASCII 文字はすべて元の順序で写され、読める状態に保たれます：bücher → bcher。写されたものと余ったものの両方があるため、境界として 1 つの - が付きます：bcher-。
2. 残りを base-36 の数として書く。残った文字はコードポイント昇順に処理され、それぞれ a=0…z=25、0=26…9=35 の可変長 base-36 数として書かれます。bücher の余り文字 ü は桁列 kva になります。
3. プレフィックスを付ける。エンコード部分を写し取った部分に繋げると bcher-kva、ドメイン文脈では xn--bcher-kva と書かれます。

これを賢くしているトリックは、あの base-36 数が含むものです：文字そのものではなくデルタ — その文字が直前のコードポイントからどれだけ離れているか、そして文字列内のどこに属するか。エンコーダーはコードポイントを昇順に歩き、各桁列が位置と距離を記述します。文字ごとにバイアスと呼ばれる共有の数が調整され、次の数ができるだけ少ない桁で済むようになります。

上の例で自分の目で確かめられる 2 つの帰結：

• 似た文字は安い。距離だけを格納するため、同じ文字の連続はほぼ無料です：中 を 30 個並べても xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa、わずか 36 バイトです。よく選ばれた無関係だが近い中国語の文字の mix は、合法な 63 バイト ラベル 1 個に約 41 文字詰め込み、単一文字の繰り返しなら 57 文字まで届きます。
• 散らばった文字は高い。前の文字から遠い文字は、より長いデルタ数を必要とします。多くの異なる文字を含む中国語テキストは通常、1 文字あたり約 2〜3 文字分余分に消費します。ラベル上限が 63 バイトでも、CJK ラベルが 20〜40 文字あたりで容量切れするのはこのためです。

デコードは同じレシピの逆方向です：ASCII プレフィックスを写し、桁を読み、デルタをコードポイントに戻し、各新しい文字をデルタがエンコードする位置に挿入します。ブートストリングに存在するのは小文字の桁だけです。だからこそ、エンコード部分内の大文字は推測されずに拒否されます — DNS は大文字小文字を区別しないため、両方の綴りを許すと 2 つの異なる表記が曖昧になるからです。

• アドレスバー。ブラウザーは 中文.com の代わりに xn--fiq228c.com を表示することがあります。同じサイトです。一部のブラウザーは、名前が複数の文字体系を混ぜるとき、意図的に Punycode 形式を表示します — 紛らわしい文字（キリル а とラテン a）が URL に隠れないようにするためです。
• DNS そのもの。ゾーンファイル、dig / nslookup / DNS-over-HTTPS の応答、リゾルバーのログには xn-- 形式しか現れません。素の Unicode は拒否されるか黙って壊されます。
• TLS 証明書。国際ドメインのサブジェクト代替名は A ラベルとして格納されます（DNS:xn--fiq228c.com）。入力した名前と違って見える証明書は不一致ではなく正常です。
• 設定とツール類。Web サーバーの server_name / 仮想ホストエントリ、Cookie ドメイン、ホスティングや CDN のパネル、メールドメイン、ドメインに紐づく API キー、データベースのキーは、すべて A ラベル形式のほうが安全です。
• テストとデータパイプライン。Unicode をそのままリゾルバーに渡して失敗するライブラリもあります。先に Punycode へ変換するのが定番の修正です。写像は標準的（1 つの Unicode ラベルはちょうど 1 つの A ラベルに対応）なので、xn-- 形式はログや検索の安定した識別子にもなります。

Punycode は可逆な綴り方にすぎません。暗号でもセキュリティ機能でもありません：上のツールで誰でもデコードできるので、xn-- ラベルが語るのは「これはエンコードされた」ということだけで、所有者については何も語りません。圧縮でもありません — 上の 6 バイト→11 バイトの例が示すように、通常はテキストを長くします。また、Unicode がインターネットを移動する他の方式とも別物です。それらは問題の別の層を解決しています。

方式	何を何に変えるか	使われる場所	中文 は
Punycode（RFC 3492）	Unicode ドメインラベルを ASCII の英数字に	国際化ドメインラベルのみ	xn--fiq228c
UTF-8（RFC 3629）	コードポイントをバイトに	すべてのファイルと Web リクエスト	E4 B8 AD E6 96 87（6 バイト）
パーセントエンコーディング（RFC 3986）	バイトを %XX エスケープに	URL パス、クエリ文字列、フォーム本文	%E4%B8%AD%E6%96%87
Base64（RFC 4648）	バイトを 64 個の ASCII 文字に	テキスト・JSON・メール・data URL 内のバイナリ	5Lit5paH
HTML エンティティ	コードポイントを名前付き・数値参照に	HTML と XML のソース	中文
Unicode エスケープ	コードポイントを \uXXXX に	ソースコードと JSON 文字列リテラル	\u4e2d\u6587

実用的な要点：Punycode は URL のドメインラベルに適用されるもので、URL 全体ではありません。パスとクエリ文字列は別の問題で、パーセントエンコーディングを使います（URL エンコーダーを参照）。

• サイズ上限は Punycode ではなく DNS 由来。1 ラベルは最大 63 バイト、名前全体は最大 255 バイト（RFC 1034/1035）。A ラベルは純 ASCII なのでバイト数＝文字数であり、非 ASCII 文字はそれぞれこの予算を消費します — Punycode 文字 1〜4 文字につき約 1 文字分の予算です。
• Punycode は何でも変換するが、レジストリが許すのは一部だけ。IDNA 規則がその上に乗り、どのコードポイントが登録可能かを制限します — 大文字、スペース、! のような句読点、国旗絵文字は実ドメインでは不正です。このページは RFC 3492 変換を行うため、レジストリが拒否するテキストも喜んでエンコードします。
• 1 つの文字体系に留める。IDNA が 1 ラベル内の文字体系混在を嫌うのは、まさに類似文字攻撃のためです。エンコードできても使えない名前、使えてもブラウザーにブロックされる名前が存在します。
• 二重エンコードしない。すでにエンコード済みのテキストに xn-- が続く形は無効です。また、純 ASCII ラベルは決して変わりません — エンコードするものがなく、プレフィックスも付きません。
• 末尾のドットは問題ない。例え.jp. は FQDN であり、末尾の空ラベルは保持されます。途中の空ラベルは有効なホスト名ではありません。

「中国語ドメインがアドレスバーで xn--fiq228c.com と表示されるのはなぜ？」

ブラウザーが A ラベルの表示を選んだからです。サイトは同一です。このページのデコード方向で Unicode 形式を確認するか、Unicode 形式をエンコードして両綴りが一致することを確かめてください。

「DNS レコード、証明書、ホスティングを変える必要はありますか？」

いいえ。機械が名前を読む場所（DNS、証明書、設定）ではどこでも xn-- A ラベルを維持し、Unicode 形式は人が読む場所だけで使ってください。

「結果が入力より長くなるのはなぜ？」

エンコーディングが文字そのものではなく base-36 の距離を運ぶためです。36 文字のアルファベットは、大きくなりうる数を書き下す必要があります。伸びるのは想定どおりで、バグではありません。

「デコードが『大文字』と言うのはなぜ？」

ブートストリングの桁は小文字のみ（a〜z、0〜9）と定義されているためです。DNS の大文字小文字無視を考慮すると、最後のハイフンの後の大文字 A-Z は曖昧になるため、黙って推測されずに報告されます。

「Punycode はメールアドレスの @ より前の部分にも適用されますか？」

ドメイン部分だけが DNS 名であり、Punycode になれます。ローカル部分は DNS ではなくメールシステムが扱うため、このエンコーディングは適用されません。

「2 つの異なる Unicode 名が同じ A ラベルを生むことは？」

なりません。このエンコーディングは単射です：異なるコードポイント列は常に異なるブートストリングを生むため、xn--fiq228c をデコードすると 中文 が正確に戻り、他にはなりません。衝突しうるのは見た目 — 違う文字が似て見えること — であって、それは Unicode レパートリーの性質であり、エンコーディングの性質ではありません。

• RFC 3492 — Punycode。このページが実装するブートストリングエンコーディング。上の既知ベクトルはこの文書のサンプル文字列と照合しています。
• RFC 5890、RFC 5891、RFC 5892、Unicode UTS #46 — IDNA2008 とそのブラウザー側解釈。どの文字が合法か、ラベルがどう正規化されるか、文字体系をどう混ぜられるかを決める規則です。
• RFC 1034 と RFC 1035 — DNS から受け継いだ 63 バイト ラベルと 255 バイト名の上限。
• RFC 3490 と RFC 3491 — 旧世代の IDNA2003。IDNA2008 に置き換えられました。古いソフトウェアで名前の挙動が違う場合、たいていこれが理由です。

適用範囲に関する注記：このツールは RFC 3492 変換のみを行います。IDN バリデータではなく、登録規則やドメインの価格・空き状況は確認しません — ネットワークに接続しないため、名前が存在するかどうかもわかりません。

上で試してください：中文 を貼ってテキスト → Punycode エンコードを押すと A ラベルが、xn--fiq228c を貼ってPunycode → テキスト デコードを押すと文字が戻ります。