《《=[前の記事に] 《=[前ページ]       [次ページ]=》 [次の記事に]=》》


コーディング方式が採用されています.この方式を使用して,"エスアールエー.jp"という日本語ドメイン名をエンコードすると"bq--gcultix45 oupy.jp"となります.

ACEの問題として,一般にはACEで多言語ドメイン名をエンコードした結果と,従来のASCIIドメイン名とを区別することができない,という点があげられます.これに関して,例えば上で述べたRACEでは,エンコードした名前の先頭に従来ドメイン名にはほとんど使用されていないと思われるプリフィックス("bq--")をつけることで区別するという方法をとっています.しかし多言語ドメイン名がビジネスになりそうだと考えている人は多いらしく,新しいドラフトが発表されるたびに,それで定義されているプリフィックスを持つドメイン名の登録が殺到するそうで,そのためワーキンググループでは特定のプリフィックスを予約して,それらを持つドメイン名の登録を一時凍結しようという提案もなされているほどです.

なお,ACEでは,ドメイン名を表すのに使える文字種が37種類しかない(ドメイン名ではアルファベットの大文字と小文字は区別されないため)ので,当然のことながらエンコーディング後の名前の長さは元の名前の長さよりかなり長くなります.ラベルの最大長63文字という制限からすると,単純な変換では十数文字以上の名前はこの制限を超えてしまいます.このため,現在提案されているACEは「実際にドメイン名として用いられる文字はランダムではなく,すべてある特定の言語の文字である可能性が高い」という仮定の元に圧縮を行うものがほとんどです.ACE方式が最初に発表されてから数々の提案が出てきましたが,これらはどれだけの圧縮できるかを互いに競っています.

とはいえ日本語のようにある程度文字の数が多いと,どうやってもあまり圧縮できません.例えばひらがなばかりとかカタカナばかりというような場合には結構圧縮できるのですが,漢字が混じるとだめです.JPNICでは日本語ドメイン名として登録できるのは最大15文字としていますが,これはこれ以上の長さだと,圧縮できない場合にACE変換後の長さが63文字を越えてしまうからです.
 
 

正 規 化

さて,多言語ドメイン名を扱うためにもう一つ重要なのが正規化と呼ばれる処理です.これは,
 

Unicodeをベースにした文字の表現方法を採用した場合には本質的に必要となる処理です.なぜならUnicodeでは同じ文字を表現する方法が複数あるからです.例えば同じアクセント付きの文字を表すのに
  • アクセント付きの文字1文字(例:ё)
  • アクセントなしの文字+合成用アクセント記号の計2文字(例:е + ¨)
という2通りの表現方法があります.これらはどちらも同一の文字を表しているので,DNSの検索においては両者を同一の文字として扱う必要があります.正規化はこのように同一文字の複数表現をいずれか1つの表現にまとめてしまうもので,正規化を行うことにより,文字列一致の検査が単純なバイトごとの一致検査でできるようになります.現在,世界の主要なDNSサーバはものすごい量の問い合わせをさばいているので,単純比較で一致が検査できるということは非常に重要なことなのです.

正規化においてもう1つ重要なのが大文字と小文字の統一です.従来のASCIIドメイン名では大文字と小文字は区別されません.そこで多言語ドメイン名でも区別しないのが自然ですが,多言語になると大文字小文字の区別をしない文字列比較が難しくなります.特にACEを使用する方式では,文字を複雑な方式でエンコードしているのでその処理はさらに複雑になります.そのためDNSの問い合わせを行う前にあらかじめ大文字あるいは小文字に正規化しておくことが重要になります.

さらに,それぞれの国や地域においてはそれぞれ独特の正規化が必要になることがあります.例えばJPNICの日本語ドメイン名の技術細則というものには

  • 半角かなを全角に
  • 全角英数字を半角に
  • 全角かな+濁音,半濁音を1文字に(例 `か' + `゛' → `が')
というような正規化が定義されています.
 
 

mDNkit

さて,やっと我々がやっているプロジェクトの宣伝をする個所にきました.

SRAではJPNICから多言語ドメイン名の評価キットの開発を受注し,今年の4月から開発を進めています.この成果は「mDNkit」という名称で一般公開され,JPNICのWebページからダウンロードす


《《=[前の記事に] 《=[前ページ]       [次ページ]=》 [次の記事に]=》》