# Punycode変換 国際化ドメイン名を、Unicodeとxn--で始まるASCII形式の間で、入力に合わせて変換します。ドメイン名、URL、メールアドレスのどれを貼り付けてもよく、変換はすべてお使いのブラウザの中で行われます。 ## 要点 Punycode（RFC 3492）は、Unicodeのラベルを英字、数字、ハイフンだけで書き表す符号化方式です。IDNAはこれに接頭辞`xn--`を付けるため、`bücher.example`はDNS上では`xn--bcher-kva.example`として保存されます。変換後の各ラベルは最大63文字です（RFC 1035）。 ### 調べ方 変換はラベルごとに行います。まずラベル内のASCII文字をそのまま写し、1文字でもあればハイフンを続けます。次に、ASCII以外の各文字を、どのコードポイントをどこに挿入するかを表す可変長の36進数として符号化します。使う定数はRFC 3492で決められたもの（base 36、tmin 1、tmax 26、skew 38、damp 700、initial bias 72、initial n 128）です。その前段として、ドメインの入力にはブラウザと同じIDNAのマッピング（UTS #46）を適用し、全角英字や句点「。」をASCIIの形に直して、名前を小文字にします。 ### 例 `bücher`の場合、`bcher`を写して`-`を付け、位置1に挿入するü（U+00FC）を`kva`と符号化して`bcher-kva`になります。つまり`bücher.example`は`xn--bcher-kva.example`です。逆方向では、`xn--wgv71a119e.jp`をデコードすると`日本語.jp`になります。 ### 制限事項 - 長さと文字はチェックしますが、IDNA2008の規則すべて（たとえば結合子に関する文脈規則）までは確認しません。また、レジストリごとに使える文字の一覧があります。 - 複数の文字体系が混ざった名前は、なりすましの可能性があるとして警告します。ただし、ラテン文字の単語に見えるキリル文字だけで書かれた名前のように、1つの文字体系だけで作られたなりすましは検出できません。 ### 出典 - [RFC 3492: Punycode](https://www.rfc-editor.org/rfc/rfc3492)：アルゴリズムと定数。 - [RFC 5890: IDNA Definitions](https://www.rfc-editor.org/rfc/rfc5890)：接頭辞xn--とAラベル。 - [RFC 5891: IDNA Protocol](https://www.rfc-editor.org/rfc/rfc5891)：DNS向けに名前を変換する手順。 - [Unicode UTS #46: IDNA Compatibility Processing](https://www.unicode.org/reports/tr46/)：ブラウザが適用するマッピング。 - [RFC 1035, section 2.3.4: Size limits](https://www.rfc-editor.org/rfc/rfc1035#section-2.3.4)：ラベルあたり63オクテット。 ## 変換の中身 この変換ツールは、国際化ドメイン名（IDN）を、人が読む形とDNSに保存される形の間で行き来させます。`bücher.example`と入力すれば`xn--bcher-kva.example`が得られ、`xn--wgv71a119e.jp`のような名前を貼り付ければ、元のUnicodeの名前`日本語.jp`がわかります。入力に合わせて双方向に、ラベル単位で変換するので、`shop.bücher.example`ならASCII以外の文字を含むラベルだけに`xn--`が付きます。 符号化方式はPunycode（RFC 3492）で、ブラウザ内のJavaScriptとして実装しているため、入力した内容はどこにも送信されません。エンコードの前に各ラベルを小文字にし、UnicodeのNFC正規化を適用するので、1文字の「が」と、「か」のあとに結合用の濁点（U+3099）を続けたものは同じ結果になります。IDNA2008やUTS #46のマッピング規則をすべて適用しているわけではないため、変換できたことは正しく符号化されたことを示すだけで、レジストリがその名前を受け付ける証明にはなりません。 結果の横には、各ラベルの内訳（Unicode形式、ASCII形式、長さ）、DNSの上限（ラベルごとに63オクテット、名前全体で253）に対するチェック、そして1つのラベルの中でラテン文字とキリル文字、ラテン文字とギリシャ文字のように文字体系が混ざっているときの警告が表示されます。 ## 使い方 1. ドメイン名、URL全体、またはメールアドレスを入力するか、貼り付けます。 2. 変換結果が更新されるのを確認します。Unicodeを入れれば`xn--`形式が、`xn--`形式を入れればUnicodeが表示されます。 3. ラベルの内訳で、長さ、上限超過のエラー、文字体系の混在の警告がないかを確かめます。 4. 貼り付け先が求める形式のほうをコピーします。 URLの場合はホストの部分だけを変換し、それ以外は入力したまま残します（Webでは、パスやクエリ文字列に含まれるASCII以外の文字はUTF-8でパーセントエンコードされ、Punycodeにはなりません）。メールアドレスの場合は@より後ろだけを変換します。`やまだ`のようなローカル部にはPunycodeの形がなく、そこへメールを届けるには経路上のすべてのサーバーがSMTPUTF8（RFC 6531）に対応している必要があります。 ## こんな場面で使えます - **怪しいリンクの確認。**メッセージに書かれたURLを、開く前にここへ貼り付けてみましょう。ホストが2種類の文字体系の文字にデコードされたり、見慣れた名前が実は`xn--`のラベルだったりしたら、クリックする前によく確かめてください。 - **DNSレコードを書くとき。**ゾーンファイルやほとんどのDNS管理画面はASCII形式を前提にしています。CNAMEの参照先やMXのホストも含め、レコードの中でその名前を指す箇所には、すべてその文字列をそのまま使います。 - **TLS証明書の申請。**認証局やACMEクライアントは、サブジェクト代替名に`xn--`形式を受け取ります。証明書のSAN一覧をデコードすれば、実際にどのUnicodeの名前が対象になっているかがわかります。 - **ログを読むとき。**Webサーバーのログ、HTTPのHostヘッダー、TLSのSNIの値にはエンコードされた名前が入っています。見慣れない項目もデコードすれば読めます。 - **IDNでメールを使う準備。**MX、SPF、DKIM、DMARCのレコードはすべて`xn--`形式の名前の下に置きます。`info@xn--bcher-kva.example`のようなアドレスは、一般的なメールソフトでそのまま使えます。 - **登録前の長さの確認。**文字体系によっては、エンコードで大きく長くなります。7文字のタイ語のラベル「ภาษาไทย」は`xn--o3crh0a8bb0k`（16オクテット）になるため、短く見えるラベルでも63を超えることがあります。 `bücher.example`のレコードや証明書署名要求（CSR）でも、ほかのホスト名と同じようにエンコード済みの名前を使います。 ``` xn--bcher-kva.example. 3600 IN A 192.0.2.10 www.xn--bcher-kva.example. 3600 IN CNAME xn--bcher-kva.example. xn--bcher-kva.example. 3600 IN MX 10 mail.xn--bcher-kva.example. openssl req -new -key site.key -out site.csr \ -subj "/CN=xn--bcher-kva.example" \ -addext "subjectAltName=DNS:xn--bcher-kva.example,DNS:www.xn--bcher-kva.example" ``` ## Punycodeがホスト名にUnicodeを収めるしくみ 厳密には、DNSのワイヤーフォーマットはどんなバイト値でも運べます。しかし実際には1980年代から、ホスト名はASCIIの英字、数字、ハイフンに限られてきました（RFC 952とRFC 1123のLDH規則）。リゾルバーもメールサーバーも証明書のチェックも、この前提の上に作られています。IDNAはそれらに手を入れる代わりに、問い合わせを送る前のアプリケーションの中で名前を変換し、もともと古い規則に従っている文字列にします。 Punycodeは2段階で動きます。まず、ラベルのASCII文字を順に写し、1つでもあればハイフンを付けます。`bücher`なら`bcher-`です。次に、抜けている文字それぞれを、どのコードポイントをどこに挿入するかを表す1つの数値で表します。üはU+00FC、10進数で252です。128から数え始め、すでに5文字が置かれているので挿入できる位置は6か所あり、数値は(252 − 128) × 6 + 1 = 745になります。最後の1は「1文字目の後ろ」を意味します。この数値を、a〜zと0〜9を使う可変長の36進数で書きます。しきい値が適応的に変わるので、小さな数値は短いままです。結果は`kva`となり、`xn--bcher-kva`ができあがります。 デコードはこの逆で、最後のハイフンより前をそのまま写し、後ろの文字を挿入の指示として読み戻します。上のタイ語のようにASCII文字を1つも含まないラベルでは、接頭辞の後ろに区切りのハイフンがありません。`日本語`を符号化した`xn--wgv71a119e`も同じです。DNSを流れるのはエンコード後のラベルなので、63オクテットの上限はUnicodeの文字列ではなく、エンコード後のラベルに対して適用されます。 ## なりすましドメインとアドレスバー 異なる文字体系の中には、見た目がまったく同じ文字が数多くあります。キリル文字のа（U+0430）はほとんどのフォントでラテン文字のaと見分けがつかないため、2文字目にキリル文字を使った`bаnk.example`は普通の単語に見えますが、エンコードすると`xn--bnk-6cd.example`になります。これがホモグラフ攻撃です。 ブラウザは、Unicodeで表示するか`xn--`形式で表示するかをラベルごとに判断します。方針はベンダーによって異なりますが、実在の名前ではめったに見られない組み合わせで文字体系が混ざっていないか、ラテン文字をまねた文字だけで綴られていないか、有名なドメインにそっくりではないか、といった点がよく確認されます。Firefoxでは、`about:config`で`network.IDN_show_punycode`をtrueにすると、すべての名前がASCII形式で表示されます。 このページの文字体系の混在チェックは、1つのラベルの中に2つ以上の文字体系があるかを調べます。ラテン文字に似たキリル文字だけで綴られたラベルは混在していない扱いになるので、警告が出なくても本物の名前だという証明にはなりません。デコードした名前を期待していたアドレスと見比べ、迷ったらアドレスを自分で入力してください。 ## よくいただく質問 **アドレスバーに日本語ではなくxn--で始まる名前が出てくるのはどうしてですか？** ブラウザがUnicodeのまま表示するのは、ラベルがそのブラウザの表示ポリシーを満たした場合だけだからです。普通ではない組み合わせで文字体系が混ざっている、ラテン文字をまねた文字だけで書かれている、有名なドメインに似すぎている、といった場合は、代わりにエンコードされた形が表示されます。サイト自体は通常どおり読み込まれます。そのxn--のラベルが何を表しているかは、ここに貼り付ければわかります。 **xn--で始まるドメインは危険なのですか？** いいえ。この接頭辞は、ラベルがUnicodeからエンコードされたことを示すだけで、ドイツ語、中国語、アラビア語、ロシア語などの言語で運営される正規のサイトも数多く使っています。大切なのはデコードした文字列のほうです。予想どおりの名前が1つの文字体系で書かれていれば、特に変わったところはありません。よく知られた名前を別の文字体系から借りた文字でまねているなら、そのリンクには注意してください。 **ドイツ語のßを含む名前で、ほかの変換ツールと出力が食い違うのはどうしてですか？** 古いIDNA2003の処理や、UTS #46の移行（transitional）モードでは、エンコードの前にßをssに、語末のシグマςをσに置き換えるため、straßeは単なるstrasseになります。IDNA2008ではこれらの文字をそのまま残します。このツールが行う小文字化とNFC正規化ではßは変わらないので、ここではfaßがxn--fa-hiaになります。登録先のレジストリや、利用者のソフトウェアがどちらの形を前提にしているかを確認してください。 **ゾーンファイルや証明書に、Unicodeの名前をそのまま書いてもよいですか？** どちらにもxn--形式を使ってください。証明書はDNS名をASCII専用のフィールドに格納するため、認証局はサブジェクト代替名（SAN）の一覧にエンコード済みの形を求めます。ゾーンファイルにUTF-8のバイト列のまま名前を書くと、リゾルバーやブラウザが送るxn--形式の問い合わせと一致せず、そのレコードはいつまでたっても見つかりません。 **メールアドレスの@より前の部分はどうなりますか？** 入力したまま変わりません。Punycodeが適用されるのはドメイン名だけだからです。「やまだ」のようにローカル部へASCII以外の文字を使うと、配送できるかどうかはRFC 6531で定められたSMTPUTF8拡張にかかっています。経路上のすべてのサーバーが対応している必要があり、PunycodeのようなASCIIへの逃げ道もないため、対応していないサーバーがあると、そのアドレス宛てのメールはたいてい差し戻されます。 **日本語ドメインでもメールアドレスは使えますか？** ドメインの部分はxn--形式で扱えば使えます。MX、SPF、DKIM、DMARCのレコードはすべてxn--形式の名前の下に置き、info@xn--bcher-kva.exampleのようなアドレスなら一般的なメールソフトでそのまま扱えます。一方、@より前に日本語などASCII以外の文字を使う場合は、経路上のすべてのサーバーがSMTPUTF8（RFC 6531）に対応している必要があります。 **ここで問題なく変換できた名前が、レジストリに断られる場合があるのはどうしてですか？** このツールは小文字化とNFC正規化のあと、RFC 3492どおりの正しいエンコードを行いますが、IDNA2008やUTS #46の規則のすべてを実装してはいません。IDNA2008はほとんどの記号を禁止し、結合子のような文字には文脈に応じた規則を設けています。さらに、各レジストリは自分のトップレベルドメインで使える文字の表を独自に公開しています。ここできれいにエンコードできても、そうしたチェックで不合格になることがあります。 **入力した文字列は、どこかのサーバーへ送られますか？** ありません。変換、長さのチェック、文字体系の混在の警告はすべてブラウザ内のJavaScriptで動くため、貼り付けた名前やURL、メールアドレスがあなたの端末から出ていくことはありません。そのうえ、iseeu.ccはIPアドレスや調べた内容のログも訪問者のデータベースも持たず、Cookieも広告も使いません。 問題なく変換できたことは、名前が正しく符号化されていることを示すだけで、登録できることや安全であることまでは示しません。レジストリは独自の文字規則を適用しており、なりすましの名前は文字体系を混ぜずに作ることもできます。 ## iseeu.ccのほかのツール - [DNSルックアップ](https://iseeu.cc/ja/dns-lookup/): A・AAAA・MX・TXT・NS・CNAME・CAA・SOAレコードをDNS over HTTPSで引きます。 - [Whois検索](https://iseeu.cc/ja/whois/): ドメイン名、IPアドレス、AS番号の登録情報を調べます。 - [メールヘッダー解析](https://iseeu.cc/ja/email-header/): Receivedの経路をたどり、SPF・DKIM・DMARCの判定結果を読み取ります。 - [セキュリティヘッダーチェック](https://iseeu.cc/ja/security-headers/): URLのレスポンスヘッダーを取得し、HSTSやCSPなどを採点します。 - [IPアドレス確認](https://iseeu.cc/ja/): グローバルIP、おおよその地域、プロバイダ、ヘッダー、TLS、リークテストを1ページで確認できます。 [すべてのツールを見る](https://iseeu.cc/ja/tools/) 最終更新：2026-10-11 元のページ：https://iseeu.cc/ja/punycode/