[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 1020] Re: 内部文字コード



■ [b-free: 1017] Re: 内部文字コード
□ Katsuhiro MIHARA<mihara@is.titech.ac.jp> さんへのお返事

 岩間です。

■ Katsuhiro MIHARA さんのメールからの引用です
□もっと早く実装していれば議論になったと思いますが、この春には 3B/V が出
□るでしょうから、今となってはそれを見てからでも遅くはないと考えます。

 ぼくもそう思ったんですが、3B/V  とバイナリ互換性はないんですよ
ね? だったら、内部文字コードは
 3B/V のことを考えなくてもいいのではないでしょうか?


□さらに、ISO-2022 の中に含まれていない文字を扱うには新たに文字集合を定
□義しなければなりません。私たちに10万字の文字集合を定義するのはきっと無
□理でしょう。それは荷が大きすぎます。

 たとえ荷が大きすぎても、内部コード云々とは関係なく、TRON  コー
ドという選択をした時点で、何らかの形でコード変換をサポートすべき
ものだと思います。単純な話をすると、メールソフトの作者は、その作
者ごとにコード変換のルーチンを自作し付加しないといけないのか? 
ということです。単純な計算式でマッピングできるものであるのならと
もかく、テーブル参照が必要なコード変換を各ソフトが持つのはちょっ
と違うと思います。MSだって、SJIS<=>Unicode  はAPIで持ってい
るわけですしね。


□多くのシステムでは、Unicode と他のコードの変換を実装するのは Java のラ
□ンタイムの方です。UNIX や MacOS ではシステム内で Unicode を使っていな
□いので、Java のランタイムが文字コードを変換して画面表示やファイルの読
□み書きをしています。

 ランタイムというのは、結局のところOSごとの実装ですし、B-Free 
の場合、TRON コードへの相互変換は必要でしょ? だから、JavaVM を
移植する段階で、その移植者が B-Free での Unicode  に対する実装を
する必要があるわけですよね。で、それを JavaVM のみが使うのはもっ
たいないと思いませんか?


□Java1.1 の FAQ です。システムが Unicode に対応したために Java がうまく
□動かないという笑えない笑い話が現実にあるのです。

 まぁ、Unicode そのものが当初の理想からかけ離れてしまった中途半
端な実装ですから仕方がないでしょう。だからといって、サポートしな
くても良いというものではなくなってしまったので、ごまかしながら使
うことになるんでしょうね。


□私の意見
□文字コードは、多少効率が落ちたとしても TRON コードを素直に実装したほう
□がいいのではないでしょうか。

 ぼくもそう思うんですよね。まぁ、効率が落ちるのはともかく、文字
列を扱うプログラムを組むのが大変じゃあないかなぁ……と思いまして。
OS側の実装が複雑になるのはしょうがないとしても、アプリケーショ
ンを作る側には手軽に扱えた方がいいと思うんですよね。


 たとえば、4Byte 固定長化した TRON コードというのができるのであ
れば、それもシンプルでいいかもしれませんね。で、TRON コード, 
ISO-2022, Unicode あるいは他の地域コードとの相互変換をAPIでサ
ポートするという感じです。
 
 うーん……やっぱり、難しいなぁ。

   ------------------- ________________________________________________
 / 岩間和彦@雑居部屋 /   EMail .. Kazuhiko Iwama <with@zakkyo.or.jp> /
/____________________/ Homepage .. http://www.st.rim.or.jp/~with/    /
                      ----------------------------------------------