そんなムズカシそうなこと書かれたって、読む気もしねぇよ〜
って、まぁ当たり前ですよね。でも、私にはこんなことぐらいしか能がありません。興味のある方のみ、読んでやってください。
しかし、一気に書き上げられる程度のものではありません。今回は概要に止まりますが、後日、詳細を書き加えていきます。
すぐに詳細を知りたい場合は、下記の RFC を参照してください。
RFC 3454：Preparation of Internationalized Strings ("stringprep")
RFC 3490：Internationalizing Domain Names in Applications (IDNA)
RFC 3491：Nameprep
RFC 3492：PunyCode
IDN（国際化ドメイン名） は、元来 ASCII コードのみで運用されていたドメイン名を UNICODE が使用できるように拡張したものです。
しかし、インターネットなど、世界中で使用されているシステムは ASCII コードで運用されているため、システム自体を UNICODE に変換するとなると、多大なリスクを負うことになります。そこで、UNICODE を ASCII に変換する方向で検討され、従来のシステムに大きな変更を伴わない方法で決定されまた。
一口に IDN 変換 といっても、単純なものではありません。例えば、UNICODE では、全く同じ意味合いの文字を表現するのに異なったコード列が存在できること、ドメイン名は ASCII コードで 64 文字以内という長さの問題などです。
IDN（国際化ドメイン名） は、世界で唯一の存在であるハズのドメイン名を表すのだから、視覚的に同一な文字は決まった ASCII コードに変換されなければなりません。また、ASCII で表現された IDN を復元したときに、もとの UNICODE に復元されなければなりません。つまり、同一文字の表現に揺れにある UNICODE のコード列を、ある決まったコード列に決める必要があるのです。
このことは、UNICODE の正規化 と呼ばれ、様々な方面で話題になりました。IDN では、この正規化と、ドメイン名を表すのに不適切な文字などの禁則や、同一の意味合いの文字のマッピングなどが、RFC 3454 で定義されています。
Preparation of Internationalized Strings ("stringprep")
IDN 変換の前処理として適用する処理を定義したものが RFC 3491 の Nameprep です。どの正規化方式を使用し、禁止文字や、マッピングなどについて具体的に記述されています。
Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
入力された UNICODE 文字列は、Nameprep で定められた通りに前処理された後に ASCII コードへの変換作業が行われます。この方法に Punycode が採用されています。変換処理に圧縮的な要素もあり、出力コードが比較的に短いというのも採用の一因になったようです。Punycode の変換アルゴリズムは RFC 3492 に書かれています。
Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
このページの内容をここまで読んでいただけた方は、ひょっとしたら IDN の処理を実装しようと思っているプログラム関係の方かもしれませんね。ここまで書いてきて何ですが、正直言って大変です。そんな方には idnkit というものが公開されていますので紹介しておきます。