タイトル	【Darwinシリーズ】ファイル名の扱いはUTF-8	カテゴリー	Darwin, Darwin 1.0
作成日	2000/6/1 9:34:34	作成者	新居雅行

Darwinを起動すると、HFS+のボリュームが自動的にマウントしていることは以前に説明した。ルート（/）に、ディスク名のディレクトリが存在するが、それがDarwinとは異なるボリュームがマウントされているのである。たとえば、「HDD1-1」というMac OS 9がインストールされたボリュームの中身は、/HDD-1というディレクトリで参照できるのである。それでファイル一覧を見て見た。やはり漢字は見えないで、アルファベットだけが見えている。 ◇Mac OS 9が存在するボリュームのルートを見てみた 　figs/darwin/DSC00016.JPG 「Apple」のあとに?がいくつあるかを数えてみる。15個だ。これは明らかに「Apple エクストラ」フォルダであるが、2バイト文字が3つの?で表現されている。HFS+ボリュームはファイル名の管理にUNICODEが使われているのだが、このファイル名や他のファイルから判断できるように、明白にUTF-8が使われている。 UTF-8はUNICODE文字のエンコードの方式の1つだ。非常におおざっぱな言い方を許してもらえれば、UNICODEは16ビットで表すことになっている。UTF-8はそのコードのうち、ASCIIコードで00h〜7Fhの範囲内にあるものは、そのまま1バイトとして表現し、80h〜FFhは2バイト、それら以外は3バイトとなる形式のものだ。2バイト以上になるものは、各バイトの最上位ビットが1になるということで、7Fh以下の1バイト文字と区別できる。日本語（つまり現在の2バイト文字）は1文字あたり3バイトとなる。つまり、UTF-8であるということは、ASCIIコードで使う上ではUNICODEとなっても何ら変化がないという点では問題点が少ないと見られなくはないのだが、日本語を使う上では文字数的に非効率だし、英語に変化がないのに日本語にコードの変換が伴うという不公平感もあるのだが、これは仕方ない。したがって、HFS+の場合、英語のファイル名なら255文字までOKだが、日本語だと、85文字までしか扱えないし、UNICODEの特性を考えるとより条件が悪くなる可能性もある。 プログラムやあるいはアプリケーションのレベルでは、今後はこうしたことを考えないといけなくなることもあるだろう。HFS+の機能をフルに使った時に、ファイル名の長さをチェックする必要があるかどうかという点については異論があるかもしれないが、基本的にはチェックの必要性がある。このとき、UTF-8でエンコーディングされたファイル名の文字列のバイト数をカウントして、255より大きい場合には、文字コードの切れ目を考慮して末尾のカットなどのプログラムを組む必要がある。少なくとも、日本語を2バイトのようにカウントして判断すると、もしかするとHFS+で収まらない長いファイル名で書こうとしてしまう可能性も出てくるわけだ。Mac OSの世界にいると、思考回路がShift-JIS化しているかもしれないが、Mac OS Xに向かって、UNIXの世界、すなわちエンコードがいろいろあるという世界に頭を切り替えないといけないのではないだろうか。

関連リンク