[FDclone-users:00377] Re: 日本語文字コード(UTF8) 環境での動作について

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20050413145349.25680806.25999@nifty.ne.jp>
        =?ISO-2022-JP?B?GyRCSXBEZyEhMGw7MBsoQg==?= <HCD02054@nifty.ne.jp>さんwrites:
> 　　1.通常（日本語ファイル名以外）からの起動時に比べ、若干時間がかかる
> 　　2. UTF-8 以外のディレクトリからの起動は不可のまま

　1. は私が最初に書いたとおり非常にコストが大きくなった結果
ですので仕方がありません。
　いつ設定が変わるか判らないので、command line 1 行の処理の
度にその前後での漢字コードの変化をチェックしています。起動時
は /etc/fd2rc や .fd2rc のサイズに比例して起動が遅くなります。


　2. は構成文字によります。うまく行けば起動可能ですが文字に
よっては無理です。
　例えば EUC-JP で「日本語」は c6 fc cb dc b8 ec の 6 bytes
です。もしこれを UTF-8 だと思い込んで内部コードの EUC-JP に
変換しようとすると、UTF-8 では c6 次に fc は現れ得ないので、
不正な文字と見なしてしまいます。
　FDclone では不正な文字を便宜上「?」で表しているので、こう
変換された時点でもう二度と元には戻せなくなってしまう訳です。

　これを防ぐには、不正な文字が現れた時点で FNAMEKCODE や各種
漢字 PATH 設定を無視するという措置が必要になりますが、んー、
これが実装出来るかどうかは余り期待しないで下さい。
　というのも、その「不正な文字だったので無視しましたよ」とい
う情報を各種パス名についてどこまで保持出来るかというのがまた
問題になるからです。
　これをきちんと憶えておかないと、正しく UTF-8 -> EUC-JP の
変換が成功したと思ってしまいますから、次の file access の際
に EUC-JP -> UTF-8 の逆変換を試行してしまいます。
　UTF-8 としてあり得ない文字列に変換可能な EUC-JP 文字列とい
うものはあり得ないので、不正文字をどのように変換しようがしま
いが、何かおかしな文字列に逆変換してしまうでしょうね。

　実用上支障があるというのは判るんですが、そもそも設定と実態
が異なるような状況を生み出したのはユーザ自身なので、ある程度
の支障は容認して貰えないでしょうかね。


> 3.ディレクトリ移動３（内蔵シェル使用）
> 　EXECUTE_SH にて、内蔵シェルを起動し、以下のコマンドを実行
> 
> 　$ cd <日本語ディレクトリ名> 

　上と合わせてこの件も見直しておきます。詳細は後日ということ
で。

                                               しらい たかし