変換の中身
この変換ツールは、国際化ドメイン名（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つのラベルの中でラテン文字とキリル文字、ラテン文字とギリシャ文字のように文字体系が混ざっているときの警告が表示されます。
使い方
- ドメイン名、URL全体、またはメールアドレスを入力するか、貼り付けます。
- 変換結果が更新されるのを確認します。Unicodeを入れれば
xn--形式が、xn--形式を入れればUnicodeが表示されます。 - ラベルの内訳で、長さ、上限超過のエラー、文字体系の混在の警告がないかを確かめます。
- 貼り付け先が求める形式のほうをコピーします。
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も広告も使いません。
問題なく変換できたことは、名前が正しく符号化されていることを示すだけで、登録できることや安全であることまでは示しません。レジストリは独自の文字規則を適用しており、なりすましの名前は文字体系を混ぜずに作ることもできます。