要約

  • RFC 3987は、Unicodeを含められる国際化リソース識別子（IRI）を、URIを前提とするソフトウェアと共存させる位置付けで定義した。変換は構成要素によって異なる。ドメイン形式のホスト名にはIDNA処理が関わる一方、パスやクエリのUnicode文字はUTF-8とパーセント符号化で表される。
  • RFC 3987の著者はMartin J. DürstとMichel Suignardであり、Dürstの大学公式CVは彼をIRI仕様の主要著者と記す。この標準は読者が使う文字と既存ソフトウェアをつなぐが、ドメインの登録や管理権を与えず、見た目の似た二つの文字列が同一のリソースを示すとも保証しない。

まずパスを見れば、変換の違いが分かる

パスに日本語が入り、ホスト名は別の文字体系で書かれたWebアドレスを考えてみたい。読む人には一つのURLでも、クライアントはスキーム、authority、パス、クエリ、必要ならフラグメントに分解する。その後、それぞれが異なる規則に従う。人に読める表記と、URIだけを受け取るソフトウェアに渡る表記には対応関係があるが、一文字ずつ一致する必要はない。

このための仕組みがInternationalized Resource Identifier、略してIRIだ。RFC 3986はUniform Resource Identifier（URI）の一般構文を定め、使える文字をUS-ASCIIの一部に制限する。2005年1月のRFC 3987は、古い定義を暗黙に変更せず、Unicodeを扱う補完的なプロトコル要素を追加した。著者は、新しい要素として定義すれば既存ソフトウェアとの明確な区別を保ち、互換性の問題を避けられると説明する。IRI対応のソフトウェアはそのまま扱えるが、取得経路の構成要素がURIしか受け付けない場合には、対応するURIへ写像する必要がある。

これは、古いネットワークの各部品があらゆる文字体系を理解するようになる、という約束ではない。対応できる場所では幅広い文字列を保ち、狭いインターフェースに渡す地点を定義する相互運用の設計だ。識別子は保存、表示、コピー、リソース取得に使われるが、これらの処理が同じ構成要素で同時に行われるとは限らない。

//の後ろには、別の名前空間がある

重要な分かれ目は、Webアドレスの//より後ろにあるauthority部分だ。ホストがDNS形式のドメイン名なら、RFC 3987の2005年時点の写像は、ドットで区切られた各ラベルにIDNAのToASCII処理を適用する。結果は、URIを前提としたソフトウェアでも扱えるASCII互換表記になる。RFCの例ではホストrésumé.example.orgがxn--rsum-bpad.example.orgに変換される。

この例はPunycodeの役割と、その範囲外を同時に示す。ドメインラベルをASCII互換形式にするが、URL全体を変換するものではなく、すべての非ASCII部分に使うものでもない。xn--という接頭辞だけで有効性が証明されるわけでもない。RFC 5890は、IDNAの条件を満たすA-labelと、見た目が似ているだけの文字列を区別する。外観ではなく、プロトコル上の検証が必要だ。

標準の世代にも注意がいる。RFC 3987がホスト名の処理で参照するのは、2003年のIDNA仕様であるRFC 3490だ。その後のIDNA2008（RFC 5890、RFC 5891など）は用語とプロトコル規則を改訂した。情報提供文書のRFC 5895は、IDNA2008の処理に入る前にアプリケーションが入力をどう写像しうるかを説明し、適切な対応が言語、アプリケーション、入力方法によって異なり得ると述べる。したがってRFC 3987の例は2005年の規範的な文脈として読むべきで、現在のすべてのブラウザーが共通の変換を行うという意味ではない。

パスはドメインラベルではない

同じ文字でもパスに移せば処理が変わる。パスの一部/研究は、UTF-8のオクテットをパーセント符号化して/%E7%A0%94%E7%A9%B6と表せる。パスにPunycodeは使わない。パスはWebサーバー、アプリケーションのフレームワーク、ファイルストア、専用ルーターなどが解釈し、DNSが各セグメントを解決するわけではない。

クエリとフラグメントにも固有の意味がある。パーセント、スラッシュ、疑問符、ハッシュ記号は普通のデータではなく区切りとして働く場合があり、解析とエスケープの順序が重要になる。RFC 3987はURIの構成要素の構文を維持したまま、IRIで直接使える文字を増やした。つまり「Unicode文字をすべてASCIIの綴りに置き換える」規則ではない。適切な処理はスキームと構成要素で決まる。

そのため、IRIを扱えない構成要素に渡る直前まで変換を遅らせることが推奨される。早すぎる変換は、別のIRI対応アプリケーションに渡す前に人にとって有用な表記を失わせることがある。サーバーが異なる順序で正規化やデコードを行えば、二つのシステムは要求されたパスを異なって解釈しかねない。DürstとSuignardの設計は、アドレスバーに非ラテン文字を表示することだけでなく、ソフトウェア間の接合部を扱っている。

有効な符号化はドメインを登録しない

IDNAが答えるのは狭い問いだ。対象のラベルは適用規則のもとで表現・検証できるか。RFC 5891ではIDNの登録と検索を別の処理として扱う。登録申請がゾーン管理者に届く前のレジストラ側の取扱いはIDNAプロトコルの範囲外であり、レジストリまたはゾーン管理者は申請された特定の文字列を検証する。構文上正しいA-labelでも、その名称が登録済みか、DNSで委任されているか、利用者が期待するサービスに管理されているかは証明できない。

見慣れたUnicodeの名称を文書に貼り付けると、この区別は見えにくくなる。少なくとも、利用者が入力した文字、ユーザーインターフェースが適用した写像、DNSに提示されたホストラベル、Webサービスが返した応答という別々の記録がある。登録情報やサービス管理権の証拠はさらに別のもので、同じ文字列の別表記ではない。変換が成功しても、どれも確定しない。

ここにはセキュリティ上の論点もある。RFC 3987はホストとパスの両方でなりすましが起き得ると注意する。見た目の似た文字、正規化に対する期待のずれ、クライアントとサーバーの処理差は、似て見えるアドレスから別のリソースを選ばせる可能性がある。規格はUnicode自体を危険だとしているのではない。どの構成要素と変換に依拠したのかをシステムが理解すべきだということだ。画面表示は見え方の証拠であって、本人確認の証明書ではない。

Dürstの役割を正確にたどる

RFCの著者欄にはM. DürstとM. Suignardの二人が記されている。Dürstの青山学院大学公式CVは彼をIRI仕様の主要著者とし、Webの国際化、Unicodeの利用、合成文字の正規化に関する初期の仕事を紹介している。また、RFC 3987が形になる時期のかなりの期間、W3C国際化活動を率いていた。大学は彼を理工学部の教授として紹介する。

この記録が裏付けるのは大きな貢献であって、単独の発明者という物語ではない。設計上の意味は、URIを読むソフトウェアに新しい文字の意味を推測させる代わりに、Unicodeに対応するソフトウェアのための表現を定義し、変換が必要な地点を定めたことにある。Dürstの仕事は共同の標準化活動の一部であり、RFCはSuignardにも共同の著者クレジットを与えている。

Heng Luの「正確な記録への権利」と本稿を結ぶのは、あくまで限定的な分析上の類比だ。Note 72は地域インターネットレジストリとインターネット番号資源を対象にしており、DNSポリシーでもドメイン名を支配する規則でもない。ここで借りる問いは、記録が主張する状態を正確に記述しているか、という点だけだ。Unicode表記、A-label、DNSの委任、Webサービスのリソースキーは関連しているが、異なる層の記録であり、互いの代用にはならない。

出典