Logo address

国際文字を含むファイル名

目次

2007/12/29

IRI の意義

現在では殆どのブラウザは
のようにアドレス欄のディレクトリ名やファイル名の日本の文字を認識すると思う。かってはアドレス欄の中に日本の文字を含める事は規約違反であり、"%" に続けて文字の内部コードを書く方法(URL エンコーディング)で
のように書かなくてはならなかった。これでは HTML のドキュメントを書く方も負担であり、またネットを利用するユーザも頭の中が "???" となる。

2005 年に RFC3937 が出され IRI(Internationalized Resource Identifiers) によってアドレス欄に日本の文字を含める事が正当化されたわけである。そのおかげで Wikipedia も「ネコ」のページは

ではなく
と、分かりやすく書いても良い事になった注1。

注1: Wikipedia の場合には「ネコ」と言う名前のファイルは実際には存在しないであろう。Wikipedia のように膨大な項目がある場合には項目毎にファイルを持つのは現実的な方法ではないからである。Wikipedia は項目をデータペースで管理していると思われる。その方が効率的に管理できるし、また任意の項目名が許される。例えば "/" を含む
のようなケースを考えたらよい。

IRI 以前は

RFC3937 以前に

と書いたらどのような問題が発生するのかを考えてみる。
この場合にブラウザは単に、「これは規約違反だ」と言ってアクセスを拒否する方法もあるだろうが、最大限に努力するとすれば、規約違反を承知で(正確に言えば何も考えないで)
	/こんにちは/皆さん.html
の文字列(内部コードの列)をそのままサーバー
	ar.aichi-u.ac.jp
に送る事だろう。

その場合の日本の文字のコードに関しては何が使われるのか? ドキュメントに使われている文字コードがそのまま使われるであろう。しかしドキュメントに使われている文字コードは全くあてにならないのである。例えば日本の Win 系のサーバーにあるドキュメントは殆どが Shift-JIS で書かれていると考えてよい。しかし Windows のディレクトリやファイルは UNICODE 文字セットを利用している注2。Mac/OSX についてもシステムは完全に UNICODE でファイルインターフェースは UTF-8 である。他方ではユーザは好きな文字コードでドキュメントが書けるようになっており、現実に使われているドキュメントの文字コード方式は多様であろう。

注2: Win のファイルインーターフェースに使われている日本の文字コードは、僕は知らない。Win のプログラムやシステムの仕組みには僕は疎い。

実のところ、サーバがどのような文字コードでファイルを管理しているかは外部からは見えないのである。

このような状況の下でファイル名に日本の文字を使った場合には、そのファイルへのアクセスは、文字コードを露に使う

のような表現にならざるを得ず、これをどのように解釈するかはサーバに任せられる(サーバーのみぞ知る)事になる。従ってリンクを張る場合には 16 進数表現を使わざるを得なかった。

UTF-8 を使う

問題の解決は簡単である。単にアドレスを記述する際の文字コードを決めておけば良い。IRI(RFC3937) は UTF-8 を使うように定めたのである注1。UTF-8 は事実上のインターネットスタンダードであったが、IRI によって UTF-8 が完全にインターネットスタンダードになった事を意味する。

注1: ドメイン名は UTF-8 をさらにエンコードされる

簡単な事だと書いたが実はまだ問題を抱えている。「ダ」のように濁点や半濁点を含む平仮名、片仮名について UTF-8 で二通りの表現法があるのだ。内部コードで e3 83 80 と e3 82 bf e3 82 99 の「ダ」である。後者の表現法は OSX のファイルシステムで採用されている。

以下の 4 つはいずれも同じアドレスを表している。

  1. http://ja.wikipedia.org/wiki/ダニ
  2. http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%8B
  3. http://ja.wikipedia.org/wiki/ダニ
  4. http://ja.wikipedia.org/wiki/%E3%82%BF%E3%82%99%E3%83%8B
通常のブラウザでは 1 と 3 は見え方が異なる。しかし、正しくは同じに見えなくてはならない。実際 OSX の Safari でこのページを見ると 1 と 3 は見た目には全く区別が付かないはずである。2 と 4 は各々 1 と 3 の URI 表記であり、UTF-8 による内部コードが露に現れている。

濁点、半濁点文字の複数の表現法に伴う問題をブラウザが解決すべきか、それともサーバーが解決すべきか、今のところ僕は知らない...

ここが分からない

しかし僕にはまだ分からない事がある。RFC3937 は URI のパスに国際文字が含まれる場合には UTF-8 に変換してから URL エンコードしろと言う。これでは UTF-8 を使っていないサーバーは困らないか? 例えば古い UNIX 系のサーバーではでファイル名を EUC でエンコードしているものもあろう。そのようなサーバーではリクエストされているアドレスは EUC による文字コードであると解釈してきたはずである。またそのような前提で多数のリンクが張られてきたはずである。しかし新しいルールでは UTF-8 であると解釈しなくてはならない。自動判別できればよいが、それはそんなに簡単な事ではない。そうしたサーバーでは暫くは移行期の混乱を覚悟しなくてはならないだろう。

参考 URI

基本 URI

その他の参考 URI