いますぐ使える国際化ドメイン名の理論と実践
〜アプリケーションとネットワークのIDNへの対応〜

米谷嘉朗
JPNIC IDN-TF/NTTソフトウェア
2003/2/11

間もなく、国際化ドメイン名（Internationalized Domain Name：以降IDNと表記）がインターネットの標準技術として利用できるようになります。IDNとは、従来のドメイン名で使用可能な英数字以外の文字、例えば漢字や仮名を、ドメイン名として使えるようにする技術のことを指し、国際化ドメイン名の技術により、日本語ドメイン名が実現できるようになります。そのIDN技術の仕組みとアプリケーションでの対応方法、IDN対応のネットワークにする方法を、それぞれページを追って紹介していきます。

　IDNの標準化は、1998年7月にAPNG（Asia Pacific Networking Group）にWGが設立されアジアで最初に議論が開始しました。その後2000年初めにインターネットで使用されるプロトコルの標準化を行っているIETF（The Internet Engineering Task Force）にIDN WGが設立されて、議論の舞台はIETFに移り、インターネットの標準（Standard Track）プロトコルとして検討されるようになりました。それからほぼ3年という歳月をかけて2003年3月に、アジアを発信地としたドメイン名を国際化するという新しいプロトコルが誕生したのです。

◆識別子の国際化 　IDNは、ドメイン名という識別子を国際化するための技術標準である。ドメイン名が国際化され日本語が使えるようになれば、メールアドレスにも日本語を使いたくなるのは自然な要求だろう。2003年2月6日にメールアドレス（正確にはメールアドレスのユーザー部）を国際化するための技術仕様がインターネットドラフトInternationalizing Mail Address In Applications (IMAA)として提案されたばかりだ。 　 本文中に説明したが、IDNを標準化する過程でSTRINGPREPが規定され、識別子を国際化するための枠組みが完成した。メールアドレスの国際化は、メールアドレスへのSTRINGPREPの適用法と、ネットワーク上でのエンコーディング（符号化）方式を決めることになる。

図1　各国の自国語ドメインのイメージ

　この解説では、IDNがどのような技術に基づいているのか、利用者や運用者はどのような対応が必要なのかについて述べていきます。

1.IDN技術の仕組み

　ドメイン名とはインターネット上の資源に一意に定まる論理的な名前を付与するものです。そしてDNS（Domain Name System）により物理アドレス（IPアドレス）などに変換されます。一方、ドメイン名は多くのアプリケーションプロトコルにおいてプロトコル要素の一部として利用されています。そのため、ドメイン名の名前解決を行うDNSはインターネットで最も重要な基盤技術の1つであり、安定運用が求められています。

　DNSやドメイン名への仕様の追加や変更は、インターネット全体に大きな影響を及ぼしかねないため、IDNワーキンググループが設立されてすぐに、IAB（Internet Architecture Board）はIDNに対する懸念として、既存プロトコルとの互換性維持（RFC 2825）と一元的なDNS階層構造の維持（RFC 2826）を求める2つのInformational RFCを発行しました。

　従って、IDNワーキンググループでは既存プロトコルとの下位互換性を保ちつつ、ドメイン名の階層構造に依存しないように最大の注意を払いながら、ドメイン名を国際化する方式を検討しました。

　IDNにおいては、早い時期に使用する文字セットとしてUnicodeの採用が合意されていましたが、Unicodeの文字をどのように符号化してネットワーク上で伝えるかについては多くの議論が行われ、ASCII文字（厳密にいうと、ドメイン名で使用可能な英数字とハイフンの37文字）のみで表現するASCII Compatible Encoding（以降ACEと表記）とすることが合意されました。ACEを採用することで、DNSサーバやメールサーバなどインターネットに広く普及しているASCII文字のみの使用を前提とした既存インフラへの影響を最小限となりました。

　その結果、Unicodeの符号化には数多くのACEアルゴリズムが提案されたなかから、効率に優れたPunycode（RFC 3492） が採用されました。

◆RACEとPunycode 　RACEもPunycodeもACEアルゴリズムである。RACEはIDN WGの初期に提案されたアルゴリズムであり、ラベルごとにプリフィクスを付けること、アルゴリズムが簡単でかつ圧縮機能を持っていたことなど、その後のACE提案の方向を決定付ける重要な役割を果たした。また、RACEの提案によりIDNの実現にめどが立ったため、VeriSignやJPNIC（当時、現在はJPRS）などのレジストリがIDNの名前解決試験に採用し、広く認知され普及した。 　しかし、RACEも完全だったわけではなく、圧縮の効く局面が限られていたり（漢字が複数文字入るとほとんど圧縮が効かない）、セキュリティ上の問題を内包していた（1つのIDNに対して、圧縮が効いた形と効かない形の複数のACEが存在する場合があり、対応付けが1対1にならないことがあった）ため、より適切なACEアルゴリズムが望まれていた。10近いACEが提案され、その中から、どんな文字列でも一定の圧縮効果が期待でき、セキュリティ上の問題もなく、アルゴリズムが比較的簡単なPunycodeが採用された。 　現在、VeriSignやJPRSではIDNの名前解決はRACEで行われている。これは、近い将来Punycodeに移行しなければならない。最も簡単な移行方法は、PunycodeのACE Prefixが決定した段階でRACEおよびPunycodeの両方をサーバに設定しておき、RACEでの名前解決が終了した後に、Punycodeに一本化することである。

　Punycodeはpuny（小さい、取るに足らないなどの意）とcodeの合成語で、Unicodeと音が似ていること、プログラムが小さいこと、少ない文字数（英数字とハイフンの37文字）でIDNを表現できることを理由に、アルゴリズム考案者が命名したものです。

　IDNを表現するために特別に設計されたPunycodeの特徴は以下のとおりです。

1. ASCII文字はASCII文字で表現する（コード変換しない）。
2. 非ASCII文字は文字コード順に並べ替え、前の文字との文字コードの差分
   と元の文字位置を数値化する。
3. 数値化された文字データを、特別な演算でASCII文字に変換する。

　符号化の概念を非常に単純化して紹介します。

1. ASCII文字のくくり出しと並べ替え 文字列⇒ Unicodeの字コード⇒ ASCII文字のくくり出しと並べ替え 3年B組 U+0030 U+5E74 U+0042 U+7D44 U+0030 U+0042 U+5E74:1 U+7D44:3(A) 2. 前の文字との文字コードの差分と元の文字位置(A)の数値化 3. 数値化された文字データ(B)を特別な演算でASCII文字に変換 ■逆変換例

　この例を見て分かるとおり、単純に36進数化した場合、逆変換の際にASCII文字化された部分の区切りが判読できませんので（22MPとOCJなのか、22MとPOCJなのかなど）、実際のPunycodeでは36進数に固定せず、元の文字列から計算で求められる複数のN進数（25進数や30進数など）を使用し、符号化された数値の区切りが容易に求められるよう工夫されています。実際のPunycodeでは「3年B組」は「3B-W52DZ04I」に変換されます。

　Unicodeでは、ディスプレイ上に表示されたり印刷されたりしたときには全く同じに見える同一の文字でも、文字コードの並びとしては異なる文字列であることがあります。これは、ほかの文字セットとの互換性のために設けられた互換文字や、合成用文字の存在が原因です。ドメイン名は識別子であるため、同じ名前は同じ文字列として照合される必要がありますが、上記のUnicodeの多様性はこの照合を困難にするため、IDNとして入力されたUnicode文字列を前処理し、同じ文字列となる可能性を最大限にする必要があります。IDNではこの前処理をNAMEPREP（Name Preparation：以降NAMEPREPと表記、RFC 3491）として標準化の一部としています。

NAMEPREPでは、以下の3ステップで処理が行われます。

1. Map
   Unicodeの規格として決められているCase MappingsのCase foldingを使用し、大文字・小文字など文字種（Case）のある文字の文字種を統一する。例えば、このステップでAはaに変換される。
2. Normalize
   Unicodeの規格として決められているUnicode Normalization FormsのNFKCを使用し、互換文字の統一や合成用文字の合成を行う。 例えば、このステップで（半角の）カは（全角の）カに変換される。
3. Prohibit
   コントロール文字などIDNとして使用が不適切な文字（使用禁止文字）をチェックする。使用されていれば、前処理はエラーとする。例えば空白文字（スペース）など。

　NAMEPREPで検討された前処理の概念は、インターネットプロトコルで使用される国際化された文字列の前処理方式の枠組みとして一般化され、STRINGPREP（Preparation of Internationalized Strings）と名付けられてRFC 3454として発行されています。

　ここまで見てきたPunycodeおよびNAMEPREPは、重要なIDNの要素技術ですが、それらをどのように適用するかが規定されていなければ、NAMEPREPされていない文字列がPunycodeに変換され、照合に失敗するといったことが生じてしまうため、IDNA（Internationalizing Domain Names in Applications、RFC 3490）がその規定を与えています。

　IDNAの基本的な考え方は以下のとおりです。

1. すべてのIDNはドメイン名をプロトコル要素として扱うアプリケーションによって処理されなければならない。
2. IDNをプロトコル要素としてネットワークに送信する際は、IDNをラベルに分解し、ラベルごとにNAMEPREPしPunycodeに変換しなければならない。Punycodeに変換したラベルには、それがPunycodeであることを示す識別子（プレフィクス）を前置しなければならない（ACE Prefix）
3. プロトコル要素としてネットワークから受信したACE Prefix付きのPunycodeをIDNとして表示する際は、Punycodeから逆変換した文字列がNAMEPREPされているか確認し、NAMEPREPされていなければIDNではないと判断する（逆変換した結果を表示してはいけない）。
   
   　また、フォントがないなどの理由で逆変換した結果を表示できない場合は、ACE Prefix付きのPunycodeのまま表示する。

　ACE Prefixはxn--の形式で、IDNAのRFCの中で規定されています。

　IDNは、IDNAの処理を経ることで、Punycodeと完全に1対1に対応付けられます。つまり、Punycodeのみに対応したアプリケーションは、IDNに対応しているとはいえないことになります。

◆国際化ドメイン名と日本語ドメイン名 　「国際化ドメイン名（IDN）」はプロトコルの名称である。国際化ドメイン名の標準化作業が始まった当初は、「多言語ドメイン名」という呼称もあったが、標準化の過程で地域化を必要とする言語の概念は導入しないことが確認され、その後は多言語ドメイン名という呼び方はされなくなった。 　日本語ドメイン名は、広義では日本語で使われる文字で表現された国際化ドメイン名を指すが、日本語の定義があいまいであるため、狭義にはレジストリ（ドメイン名の登録業者）の定義によるサービスを指す。

更新履歴 2003.03.10　 3月7日にRFCが発行され、決定事項を更新。

ページ目次

1　IDN技術の仕組み 2　アプリケーションでの対応方法（利用者の対応） 3　IDN対応のネットワークにする方法（管理者の対応）

関連リンク
	集中連載：DNSの仕組みと運用

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）