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

[武貞 一三 <HCD02054@nifty.ne.jp>]

> 　Zaurus の例ですと LANG の未設定というレベルの問題ではなく
> て /usr/lib/locale も /usr/share/locale も用意されていません
> から OS を入換えるくらいの手入れが必要になりますね。

　あ、そうですね。
　あの書き方だと、環境変数レベルで話終わってるようにも取れちゃいますね。
　そのへん、リンク先のページの方でも、もちょっと追記しときます(^^;)。


> >     4.EXECUTE_SH(h)でコマンドを実行
> >       $ echo "Test Arguments" > ./日本語ファイル    # 作成成功
> 
> 　これは正しいんですよ。redirect の対象は filename に決まっていますから、設
>定された文字コードに変換してから open() します。

　あ、成程。言われてみればその通りです。
　むしろ、内蔵シェル内で扱われる文字コード確認するって上では、ファイルの中身も
日本語にしとくべきだったかもしれませんね。


> >     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 出来るん
> ですが。

　あ、すいません、内部コマンド dtypeの存在は見落としてました。申し訳ない。
　早速、試してみましたが、確かにこちらだと正常に引数受け取ってくれますね。


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

　結局のところ、使われている言語と文字コードが特定出来ないのであれば、その都度
アプリケーションが動的に判断するか、それかユーザレベルで静的に指定するかのどち
らかしか選択肢はありませんからね〜。

　ただ、ユーザレベルに限って言うのであれば、FDの内部と外部で扱っている文字コー
ドが変わってしまっていると言うのが、混乱につながるのでは無いかと思います。
　それはユーザが FDの内部と外部の動作の違いを意識しなければならないと言うこと
に繋がっちゃうわけですんで。

　むしろ、そう言う意味では FD自体の機能を増やすと言うより、ホントはポーティン
グのレベルで、持ってくシステムに合わせておくってのがスジなのかもしれません。

　まぁ、贅沢を言えば完全に動的に文字コード判断して、複数のコードを同時に扱える
のが理想ではあるわけですが(^^;)。


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

　このへんが日本語文字コード特有の問題ですね〜。
　お手間取らせて申し訳ありませんが、どうぞよろしくお願いします。


                                                        TAKETYON こと 武貞一三