[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/ /
----------------------------------------------