[FDclone-users:01040] Re: internal character code

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <5659E2B4.2050803@m20.jp>
        Masaaki Matsuo <masaaki@m20.jp>さんwrites:
> こんにちは松尾です。

> fdcloneの内部文字コード(漢字コード)はShift JISかEUCで、
> これに変換できないファイル名場合に
> 文字化けを起こすのではないかと予想しました。
> 
> この予想が当たっていたとしてですが、
> 内部文字コードを別のコード(utf8でしょうか…)も使えるようにする
> 考えというか予定はありますでしょうか?

　この問題は実に悩ましい問題で、どうしたらいいか悩んでいるう
ちに半年も過ぎてしまいました。これ以上待たせる訳にもいかなく
なって来たので、未整理ながら回答してみますね。

　まず先に、一体何に悩んでいるかを説明しておきます。一つには
どうすれば実現可能かという単純に技術的な局面と、もう一つには
どう説明すべきかというややメタな局面とがあります。
　技術的な話は後述するとして、Unicode の特殊性をある程度理解
して貰わないと説明出来ないことが多いため、どういう切口で話を
したら良いのかが非常に難しいのです。

　多くの人は Unicode とそれ以外の文字コードとを表現の違い程
度にしか認識していないと思います。大文字と小文字だとか平仮名
と片仮名だとかは表現の違いなので機械的に変換可能です。
　Unicode は従来の JIS 系の文字コードとは全く別の体系なので、
英語と日本語のように機械的には変換不可能な文字コードです。ど
こかに恣意的なバイアスが生じます。
　FDclone は JIS 系の文字コードを念頭に設計されているため、
Unicode 対応は多分に ad-hoc な手法で実現されています。本当の
意味での Unicode 対応とは呼べないかも知れません。

　技術的な話をしますと、FDclone を Unicode 対応する上で障壁
となるものは大きく二つあります。一つはバイト数と文字数との変
換、もう一つはグリフ幅の取得です。
　前者に関しては JIS 系の体系とは異なるというだけの話なので、
実装の面倒さを除けば無理な話ではありません。JIS 系と共存させ
ようとするとソースが見づらくはなりますけどね。
　問題は後者です。所謂「全角」「半角」問題です。これは文字編
集機能を持つソフトにとっては避けられない点で、一文字分のカー
ソル移動の実際の移動量が判らないと編集画面を構成出来ません。
　そして、ここが一番 Unicode の困った点なのですが、そんな大
事なことが規格では定められていないのです。ベンダ任せで実装に
よりまちまちになっています。

　有名な例では Mac OS X の Unicode 実装が他のベンダと大きく
異なる点が挙げられます。Mac OS X の端末から Linux や Windows
にリモート接続すると一部の文字でカーソル位置がずれます。
　ある文字を画面に表示させた時に、リモート側で想定している表
示幅と、実際に表示する端末上での表示幅とが異なっているため、
その上を移動するカーソルの位置が出鱈目になります。

　まぁこのベンダ依存の点は置いておくとしても、Unicode の文字
体系は文字幅を考慮には入れていないため、JIS 系の文字コードの
ように「全角」と「半角」とがグルーピングされてはいません。
　JIS 系では文字コードのこの範囲は「全角」でこの範囲は「半角」
といった区分けが容易なのに対し、Unicode では各ベンダが定めた
文字幅テーブルを参照しないとなりません。
　そのテーブルを FDclone でどう管理したら良いでしょうか？既
存の文字であれば調べれば判ることですが、新規に追加された文字
がどれだけの幅を持つのか、ベンダが実装するまで全く不定です。


　ぶっちゃけた話をすると、Unicode 対応がぞんざいなのははっき
り言って私が Unicode 嫌いだからです。上記のようないい加減な
仕様は漢字文化圏を無視した仕様策定の結果です。
　欧米各国にとっては非 ASCII 文字と言えば Latin-1 等の普段使
わない文字だけなので、例外扱いにしてもさほど困りはしませんが、
漢字文化圏にとっては決して例外とは呼べない程一般的です。
　もう少し日本や中国に Unicode コンソーシアムでの影響力があ
れば、もっとましなコードになっていたかも知れませんが、結果的
に漢字の使いにくい文字コードと化してしまいました。

　私も、まさかこんな乱暴な規格が主流になるとは思っていなかっ
たので、その点は先見の明の無さですかね。こうなると判っていれ
ば、もっと真面目な Unicode 対応にしていたかも知れません。
　とは言え、ad-hoc な対応のまま進めて来てしまったことは否め
ませんので、必要なのであれば今からでも真面目な対応に実装し直
すべきだとは思います。
　となると、決め手はニーズの大きさになると思います。

　現在の実装でも殆んどの文字に関しては特に支障無く利用出来る
筈です。それで利用出来ない文字について、どの程度の需要があっ
て、利用出来ないとどの程度困るのでしょうか。
　そのニーズの大きさと実装の手間とを天秤に掛けて、私はそう大
きなニーズではないと判断したので、これまでこの問題は放置して
来ました。
　ですから、そのニーズの大きさを私に説得することが出来れば、
この問題は実装に向けて前に進めると思います。勿論、その方法論
についてはこれから考えることになりますけどね。

　という訳で、まずはニーズの大きさを示して貰えないでしょうか？
単純に困っている人の人数という訳ではなくて、深刻さや頻度を加
味して貰って構いません。
　半年も経ってこんな回答しか用意出来なくて申し訳ありませんが、
決して門前払いをするつもりはありませんので、必要だと思うので
あれば、まずは私を説得してみて貰えないでしょうか？

                                               しらい たかし