しらいです。

In article <YAS.06Mar9140948@kirk.is.tsukuba.ac.jp>,
Yasushi Shinjo <yas@is.tsukuba.ac.jp> wrote:
>新城＠筑波大学情報です。こんにちは。

>こちらでも、問題が残っています。ネットニュースなので、他の人
>が見ても参考になるし、未来に同じ問題にぶつかる人も出てくるの
>で、いい情報を出してもらえるのはありがたいです。

　漢字コードに纏わる種々の問題は日本固有の問題なんですが、特
定のアプリ上の漢字問題を扱う場所はあっても統括的に扱う場所が
ないので、何度も同じ問題があちこちで表面化しますね。
　そういうポータルサイトがどこかにあると便利なんでしょうが。


>面白い機能ですね。複数の漢字コードに同時に対応するアプリケー
>ションというのは、探してもあんまりありません。

　日本固有の問題だけに、日本人の開発者じゃないとこの問題には
対応しようとは思わないんでしょう。
　現在の open source 文化は多分に欧米主導型なので、漢字コー
ド問題に対応したアプリはなかなか出て来ないかも知れません。本
家に対応 patch 送っても理解されないことも多いですし。


>> 　「UFT8PATH」は「UTF8PATH」の TYPO だとして、Mac OS X の場
>> 合は「UTF8MACPATH」の方が無難だと思います。じゃないと濁点付
>> の仮名文字辺りで正しく convert されない筈です。
>
>「が」と「か゛」の問題ですね。一応、どちらでも大丈夫だと学生
>が言っていました。比較する時に標準化しているみたい。

　Mac OS X 側の API を使えばきちんと正規化してくれると思いま
すが、非標準アプリは UNIX 汎用に設計されているものも多く、そ
ういうものは API ではなく独自に処理するでしょう。
　FDclone も API は使ってないので独自テーブルを使ってコード
変換しますので、UTF-8 の種類を指定してやる必要があります。

　Mac OS X ユーザの中にはこの辺りの区別のついていない人も多
くて、例えば OS 標準の Samba は API 処理ですが original の実
装では API を使わないので、source から build して使おうとす
ると漢字コード問題に躓いたりしますね。
　Apple の実装コードもどこかに転がってるので、それを本家にマ
ージすればみんなで幸せになれるんでしょうけど、Apple 側はそう
いうのに積極的ではないので、本家側では余り動いてないようです。


>あと、１つのディレクトリに EUC と Shift_JIS が混じっていると
>か、漢字コードを正規化すると、同じになってしまうファイル名が
>存在する（可能性がある）とか、細かい変な話がいろいろあります。
>u1 = toutf8(f1) と u2 = toutf8(f2) で、f1 != f2 なのに u1 ==
>u2 になってしまうとか、最初から f1 と u2 が混在しているとか。
>あんまりないとは思いますけど。

　そこまで複雑な環境だと、汎用ツールで対処しようとするのは難
しいのではないでしょうか。そんなややこしい構成にしてしまった
方が悪いとも言えますし。
　機械的に処理しようとすると漢字コード自動識別が必要になりま
すが、ファイル名のように短い文字列では完全に識別するのは難し
く、辞書等を用いた intelligent な解析をしないといけません。
　昔は ISO-2022-JP/EUC-JP/Shift_JIS くらいしか候補がありませ
んでしたが、今では後から後から新しいコード体系が出て来るので、
nkf みたいな自動識別はそのうち破綻して来るんじゃないかな。

-- 
                                               しらい たかし