🌐 Punycode / IDN 変換ツール

国際化ドメイン (例: 日本語.jp) と Punycode (例: xn--wgv71a119e.jp) を双方向変換。URL 全体の貼り付けにも対応し、ラベルごとに自動判定します。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

🔒 プライバシーについて

・すべての処理はあなたのブラウザ内で完結します
・入力データは一切サーバーに送信されません

入力 (ドメインまたは URL)

出力 (Punycode ⇄ Unicode)

📖 動作仕様

入力にドット (.) があれば各ラベルごとに変換します。
https:// などのスキームやパスを含む URL も自動的にホスト部分のみ変換。
ASCII のみのラベルは「decode (xn-- → Unicode)」、非 ASCII を含めば「encode (Unicode → xn--)」と自動判定。
Bootstring (RFC 3492) 算法を純 JS で実装。外部ライブラリ不要。

📖 つまずきやすいポイント

国際化ドメイン (IDN) と Punycode を RFC 3492 の Bootstring 算法で相互変換します。ドットで区切られたラベルごとに判定するので、URL 全体を貼り付けてもホスト部分だけが変換されます。処理はブラウザ内で完結し、入力は送信されません。ただしこのツールが行うのは符号化だけです — そのドメインが登録できるか、安全かは判定しません。IDNA2008 や UTS-46 が課す文字種の制限、スクリプト混在の禁止、レジストリごとの独自ルールは、この変換の後段で別に適用されるものです。

ケース	何が起きるか	どうする
見た目が同じなのに別のドメイン (ホモグラフ)	多くの文字体系にはラテン文字と見分けがつかない字があります。たとえば `U+0430 CYRILLIC SMALL LETTER A` は、ほとんどのフォントでラテン文字の `a` と同一に描画されます。これを 1 文字目に使ったドメインは `xn--pple-43d.com` と符号化されますが、アドレスバーには本物と同じ綴りで表示され得ます。ブラウザは「ラベル内でスクリプトが混在している」「表示言語と一致しない」といった条件で Punycode 表示に切り替えますが、その判定基準はブラウザと利用者の言語設定によって違います。つまり自分の画面で普通の綴りに見えたことは、何の保証にもなりません。	`xn--` 形が唯一の判断材料です。疑わしいリンクをここに貼り、出力を読んでください。ASCII に見えるドメインなのに `xn--` が出たら、非ラテン文字が混じっています。逆方向も同じで、`xn--` 形を貼れば実際の文字列が読めます。組織として対策するなら、目視ではなく機械で弾いてください — メールゲートウェイやチャットの受信側で `xn--` を含む URL に警告を出す、業務で使うドメインを許可リストにする、といった方法です。人間の目視は原理的に通り抜けられるので、教育だけを対策とするのは成立しません。
変換できることと、登録・到達できることは別	符号化は機械的な処理なので、どんな文字列でも変換自体は成功します。しかし DNS 側には別の制限があります。1 ラベル 63 文字の上限は「符号化後」の長さに対する制限で、`xn--` の 4 文字も数に入ります。かな・漢字は 1 文字が平均 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 は実装によってどちらを記録するかが違い、同じサイトが 2 行に割れます。メールはさらに厄介で、ドメイン部分は `xn--` にできてもローカル部分 (@ の左) を非 ASCII にするには SMTPUTF8 (RFC 6531) が必要で、対応していない MTA は今も珍しくありません。	保存と比較には `xn--` 形だけを使い、Unicode 形は画面表示のときにだけ復元する — これを 1 箇所で徹底するのが唯一の解です。データベースに入れる直前、ログに書く直前、外部 API に渡す直前で `xn--` に正規化してください。「片方だけ正規化」が最悪で、リダイレクトやリンクが無限ループしたり、同じユーザーが 2 人に見えたりします。Search Console は両方のプロパティを登録して合算するのが確実です。メールアドレスを扱うなら、ローカル部分の非 ASCII は当面サポートしないと決めて、その旨をフォームに書くほうが、中途半端に受け付けて送信時に失敗するより親切です。

Punycode は暗号でも難読化でもありません。Bootstring は可逆な符号化で、鍵も乱数もありません — 誰でも 1 秒で元に戻せます。「xn-- だから読めない」という前提の設計は必ず破綻します。もうひとつ、ラベル単位で処理されるという性質は攻撃側にも使えます — example.com.xn--.... のように本物のドメインをサブドメインとして左側に置く手口では、xn-- は右端のラベルにだけ現れます。ドメインの所有者を決めるのは常に右端 (TLD の隣) のラベルで、左に何が書いてあるかは無関係です。判定するときは、必ず右から読んでください。

📖 使い方

1

ドメインを貼り付け

国際化ドメイン (例: 日本語.jp) や Punycode (xn--wgv71a119e.jp) を入力します。URL 全体の貼り付けも可能です。
2

変換結果を確認

入力に非 ASCII 文字があれば encode (xn-- 形式) に、ASCII のみなら decode (Unicode) に自動変換します。
3

コピーして利用

コピーボタンでクリップボードに保存。WHOIS 検索や DNS 設定、メールサーバー設定にそのまま使えます。

❓ よくある質問

Punycode とは何ですか？

Unicode を ASCII のみで表現する DNS 用のエンコーディング (RFC 3492)。xn-- で始まるラベルが Punycode 形式の国際化ドメインです。

絵文字ドメインも変換できますか？

技術的には可能で本ツールも処理しますが、現在多くの TLD は絵文字ラベルを受け付けないため実用性は限定的です。

ブラウザの URL.host と何が違いますか？

ブラウザ実装には差異があり、IDN を自動的に xn-- に変換する場合と Unicode のまま返す場合があります。本ツールは RFC 3492 に厳密に従い、明示的に変換します。

🔗 関連ツール

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。