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

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20050406173056.25680806.20927@nifty.ne.jp>
        =?ISO-2022-JP?B?GyRCSXBEZyEhMGw7MBsoQg==?= <HCD02054@nifty.ne.jp>さんwrites:
> 　んと、ロケール(LC_*、LANG、LANGUAGE)を用いるんでは駄目でしょうか。

　ご指摘のとおり、locale に頼ってしまうと locale 未整備環境
で躓いてしまいます。
　Zaurus の例ですと LANG の未設定というレベルの問題ではなく
て /usr/lib/locale も /usr/share/locale も用意されていません
から OS を入換えるくらいの手入れが必要になりますね。

　そもそも locale というのは言語の選択であって文字コードの選
択ではないんですよね。単一言語の表現に複数のコード体系が存在
するなんてことは locale 世代では考慮されてませんでした。
　なので、システム毎に「日本語を使うなら EUC-JP」といったよ
うに決打ちされていて、「LANG=ja」みたいな指定でもまかり通っ
ていたという次第です。


>     4.EXECUTE_SH(h)でコマンドを実行
>       $ echo "Test Arguments" > ./日本語ファイル    # 作成成功

　これは正しいんですよ。redirect の対象は filename に決まっ
ていますから、設定された文字コードに変換してから open() しま
す。
　と言うか FDclone の中では system call に全て wrapper が介
在しているので、FDclone 自身が filename を扱う場合にはきちん
とコード変換出来る訳です。
　ところが ls(1) にしろ cat(1) にしろ、外部コマンドは一般の
system call を使って file access しますから、LD_PRELOAD か何
かを使わない限りはコード変換出来ません。


>     5.再度EXECUTE_SH(h)でコマンドを実行
>       $ cat "./日本語ファイル"                      # エラー。読み込み不可。

　Linux の場合 FDclone の内部コードは EUC-JP ですからねー。
入力された UTF-8 を EUC-JP に変換して持っておいて wrapper が
UTF-8 に再変換する訳です。
　wrapper を通さない場合は EUC-JP のまま通りますから、この場
合 cat(1) に渡されるのは確かに EUC-JP です。これを内部コマン
ドの dtype にすれば wrapper を使うので file access 出来るん
ですが。

　んー難しいですねー。少なくとも既存の LANGUAGE, INPUTKCODE,
FNAMEKCODE 以外にシステム標準コードを規定する設定項目が必要
になりそうですね。混乱して使いにくくなるかも。
　意図を明確にするには、「コマンドライン入力文字列に使われる
漢字コード」とすべきかな。EXECUTE_SH や EXECUTE_FILE で入力
された文字列は全てこの漢字コードに変換して処理されます、と。

　一番の問題点はどの phase で変換するかなんです。入力直後に
変換すると、shell parsing の際に漢字の中に meta character が
現れても認識出来ません。
　じゃあ execve(2) の直前がいいかと言うと、今度は %C マクロ
などにより本来の正しいコードに変換済の引数まで変換してしまっ
ておかしくなります。
　となると、順番からするとマクロ展開前で parse 終了後という
ことになりますが、現行実装ではマクロを展開してから parse し
てるのでそんな phase は存在しません。

　んー meta character の存在は無視するしかないかなー。今の実
装でも「$PATH」とか「\」とかいった名前の file は開けませんも
のね。
　悩みの種は尽きませんが、次のバージョンの仕様としてちょっと
考えてみます。

                                               しらい たかし