URL の日本語表記について

2006/06/18

日本語ドメイン名

ここで筆者が「日本語ドメイン」と言っているのは漢字や仮名など日本で使用されている文字を使用したドメイン名の事である。従って誤解の無いように「日本文字ドメイン名」と言うべきところであるが世の(悪しき)慣習に従って「日本語ドメイン」とここでは言っている。

http://jprs.jp/ は日本語ドメイン名を普及させようとするサイトである。この入り口のページには日本語ドメイン名を持ついくつかのサイトが紹介されている。

このうち「新宿駅.jp」をクリックすると

が現れる。URL 入力欄に日本語で「 http://新宿駅.jp 」と現れるのが自慢である。
ところでブラウザの「ソースを表示」で内容を読むと

	<a href="http://xn--oct34u4y7b.jp/" target="_blank">新宿駅.jp</a>

となっている。つまり「新宿駅.jp」の本当のアドレスは「xn--oct34u4y7b.jp」と言う素人には訳の分からない暗号のような文字の列なのである。

国際化ドメイン名を Punny コードに変換する(あるいはその逆) Web サービスが
http://www.idnforums.com/converter/
で行われている。

次のサイトは文字、その UTF-8 code、Penny code など様々な変換を行ってくれる。
http://people.w3.org/rishida/scripts/uniview/conversion

これを

	<a href="http://新宿駅.jp">新宿駅.jp</a>

としたらどうであろうか?
新宿駅.jp

http://www.ietf.org/rfc/rfc3492.txt

http://日本レジストリサービス.jp/

http://www.idnforums.com/

日本語 URL

日本語のファイル名

日本語ファイル.html このリンクの書き方は

	<a href="日本語ファイル.html">日本語ファイル.html</a>

となっている。これをクリックすると Mac/Safari では

のように、URL 入力欄にはちゃんと日本語の「日本語ファイル.html」が見えるが、Mac/Firefox では

のように「日本語ファイル」の部分が文字コードによって表される。この文字コードは「日本語ファイル」の UTF-8 表現である。
では Firefox では URL 入力欄に

	http://ar.aichi-u.ac.jp/iri/日本語ファイル.html

と書いたらアクセスできないのかと言えば、それでもアクセスできる。しかしそのあと直ちに日本語の部分は16進数に置き換わる。

日本語のディレクトリ名

同様な事はディレクトリ名についても言える。
日本語ディレクトリ

ベートーベン

日本語を含むパス名のリクエストヘッダ

クライアントはサーバにアクセスするときにはリクエストしている URL (Request URL)をサーバに対して提示する。この内容はリクエストヘッダに含まれる。これは HTTP のルールである。そしてこの中には ASCII 文字以外を含む事はできない。
次をクリックするとリクエストヘッダを表示してくれる。
日本語テスト

「だ」の怪

OSX は変なの「だ」

筆者が Mac を使うようになったのは OSX 以降である。UTF-8 の環境が良い事が大きな動機になっている。ところが OSX を使いだして間もなく妙な事を発見した。OSX で使われている片仮名ファイルの名前の文字コードが筆者が期待しているものと異なるのである。
OSX で「だ」を含むファイル名を作成してみる。最もシンプルなケースとして名前が「だ」のファイルで実験する。

-bash$ cat>だ
abc
-bash$ cat だ
abc
- bash$

bash は非ASCII文字を扱えないので実際の表示は

-bash$ cat>\343\201\240
abc
-bash$ cat \343\201\240
abc
- bash$

となる。

ls でファイル一覧を表示すると

-bash$ ls
だ
-bash$

で何の変哲もないが、出力の内部コードを見るとあっと驚く

-bash$ ls |od -c
0000000  343 201 237 343 202 231  \n
0000007
-bash$

なんと「だ」が6バイトでコード化されているのである。
この様子をPythonでさらに調べてみた。

-bash$ python
Python 2.3.5 (#1, Aug 22 2005, 22:13:23)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> f=open('だ')
>>> f.read()
'abc\n'
>>> import os
>>> os.listdir('.')
['.DS_Store', '\xe3\x81\x9f\xe3\x82\x99']
>>> g=open('\xe3\x81\x9f\xe3\x82\x99')
>>> g.read()
'abc\n'
>>> ^D
-bash$

つまりファイル名が記憶される時に6バイトに引き延ばし、open コールで UTF-8 の3バイトの「だ」をその6バイトにマップしているらしい。この事自体が変なのであるが、たちが悪い事に、これが dirstat コールと首尾一貫していないのである。

ここでは「だ」を例に挙げたが、濁点や半濁点を含む平仮名と片仮名は全て同じ問題を抱えている。

OSX の「だ」は変ではない

ユニコードにおける濁点、半濁点問題は非常にややこしい混沌とした問題らしい。次の URL は問題を理解する上で参考になるかも知れない。

簡単に言えば「だ」をユニコードで表すには2つの方法があり、「だ」を1つのユニコードで表す伝統的な方法と、「だ=た+濁点」と考え、「た」を表すユニコードに続けて濁点を表すユニコードを追加する方法がある。濁点を表す表すユニコードには2種あり、昔の半角濁点のように濁点自体が独立した1文字として扱われるもの(309B)と、「た」に続けると完全に「だ」に見えるべき結合用濁点(3099)が存在する。OSX は「だ」を1つのユニコードで表す方法ではなく、「た」に結合用濁点を付加した方法を採用している。

これらの方法に寄って「だ」がどのように見えるかを次に示す。

	「だ」		1つのユニコードで表した「だ」	3060
	「だ」		「た」+ 結合用濁点			305F+3099
	「た゛」		「た」+ 独立濁点			305F+309B

現状では見え方はOSやブラウザに依存しているはずである。
最初の2つの「だ」が完全に同じに見えれば、ブラウザはユニコードの結合用濁点に正しく対応していると言える。

平仮名、片仮名、アイヌ用の特殊な片仮名に関するユニコードの規格文書が以下のURLから手に入る。

Unicode/UTF-8では同じ文字に複数の文字コードが対応する

次に示すのは UTF-8 換算で 3 バイトの「だ」と 6 バイトの「だ」である。

	だ		(e3 81 a0)
	だ		(e3 81 9f e3 82 99)

これらの2つの「が」は見た目には完全に同じである。これが違う事を確認するには、おのおのの「だ」をコピーして、どこかにペーストし文字コードを調べる以外には方法はない。以下は OSX のターミナルに「だ」を取り込んでエコーさせて違いを確認している。

-bash$ echo \343\201\240
だ
-bash$ echo \343\201\237\343\202\231
だ
-bash$

セキュリティ上の問題

同じ文字に複数の文字コードが対応すると言う問題は時にはややこしい問題をもたらす事を意味する。
例えば「ダイワ」を考えてみよう。この「ダ」は 3 バイトになるのか、それとも 6 バイトになるのだろうか?

	ダイワ.jp	e3 83 80 e3 82 a4 e3 83 af  .  j  p
	ダイワ.jp	e3 82 bf e3 82 99 e3 82 a4 e3 83 af  .  j  p

Punycode (rfc3492)
このアドレスは共に
xn--eckvc8g.jp
である。