In message <199710201246.VAA02166@bfree.rim.or.jp>
"[b-free 817] Re: 実身名についての見解"
"Naitoh Ryuichi <night@bfree.rim.or.jp>" wrote:
night> > まず、多国語対応の処理はファイルシステム・レベルでは不要です。コード
night> > に0xff(TRON特殊コード、TRONエスケープ)が入っている場合だけ特別の処理
night> > が必要なのです。言語指定コードは無視して構いません。
night>
night> うーむむむ。
night> たとえば、get_lnk で指定するパス名の中に、言語指定コードに同じものが入っ
night> ている場合も考えられます。そういう場合には、余分な言語指定コードを外す
night> とかする必要はないですか。
night> それに、ネットワークワイドの環境を考えた場合、ディスク中にあるファイル
night> の名前がどの言語コードではじまっているかを考慮する必要があります。
night> また、文字コードは、一文字の長さが 1 バイトの場合と 2 バイトの場合があ
night> ります。それぞれ、処理を変える必要があります。一文字の長さがどれくらい
night> かは言語コードによって変わってきますから、ファイルシステムは、言語コー
night> ドがきたら、以降の文字がどういうものかを調べる必要があります。
night>
night> ちょっと思いついたものを並べただけでも、これだけあります。
night> 結局、ファイルマネージャは、パス名を処理する場合に、言語コードを認識す
night> る必要があるのではないでしょうか?
night>
night> パス名中に言語コードが多重に入っている場合の扱いについては、考えかたに
night> よると思います。私としては言語コードの入りかたが違っていても、ファイル
night> 名が同じかどうかをきちんと処理できるようにしたいところです。
問題点は
・言語指定コードが重複して入っている名前の同一性
・デフォルト言語指定
・1バイトコードと2バイトコードの扱い
でしょうか。
言語指定コードについては上位で正規化(言語指定コードの重複なし)して
扱うべきではないかと思います。ビット表現は違うが同じ文字列という話
になると、英語のアルファベットと日本語のアルファベットは同じか否か
といった問題も出てきますし、ファイルシステムでカバーするのは無理が
あるでしょう。
# アルファベットは勝手に正規化できないから上位での処理も面倒だけど。
1バイト/2バイト混在は上記の方針(言語解釈は上位に任せる)では問題に
ならないでしょう。基本的に1バイトずつ0xffを探すことになると思います。
# 準TADを考えると問題がもう少し複雑になるけど。
デフォルト言語指定については、本格的多国語環境の仕様や3Bでの実装
がどうなるのか分からないですが、個人的には、なしにするのが正解かと
思っています。要するに「文字列は常に言語指定コードから始める」よう
にしてしまえば良いのです。あるいは「0xfe21(基本多国語面)は省略可」
でも良いです。
--- 林(takanori@ohsaki.meidensha.co.jp)