[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1032] Re: 内部文字コード
隆一です。
From: Kazuhiko Iwama <with@st.rim.or.jp>
Subject: [b-free: 1020] Re: 内部文字コード
Date: Sat, 07 Feb 1998 11:43:19 +0900
> ■ [b-free: 1017] Re: 内部文字コード
> □ Katsuhiro MIHARA<mihara@is.titech.ac.jp> さんへのお返事
>
> 岩間です。
>
> ■ Katsuhiro MIHARA さんのメールからの引用です
> □もっと早く実装していれば議論になったと思いますが、この春には 3B/V が出
> □るでしょうから、今となってはそれを見てからでも遅くはないと考えます。
>
> ぼくもそう思ったんですが、3B/V とバイナリ互換性はないんですよ
> ね? だったら、内部文字コードは
> 3B/V のことを考えなくてもいいのではないでしょうか?
内部文字コードについていえば、3B/V のことを考える必要はないと思います。
内部文字コードは、プログラム内部で閉じるものなので、はっきり言えば、
そのプログラムを作る人が勝手に決めてしまっていい。
たとえば、ファイルマネージャ内部では 4 byte 固定長で内部文字コードを
決めてしまい、メモリマネージャでは、3 byte 固定長で内部文字コードを
扱ってもかまわないと思います(あくまでも例なので、実際に 3 byte で内部
文字コードを決めても問題ないのかは考えていません)
で、周辺核同士の通信やアプリケーションとのやりとりは、TAD というデータ
形式で行うようにすれば、問題ないと思います。
以下の話は、内部文字コードというより、外部コードの話だと思います。
>
> □さらに、ISO-2022 の中に含まれていない文字を扱うには新たに文字集合を定
> □義しなければなりません。私たちに10万字の文字集合を定義するのはきっと無
> □理でしょう。それは荷が大きすぎます。
>
> たとえ荷が大きすぎても、内部コード云々とは関係なく、TRON コー
> ドという選択をした時点で、何らかの形でコード変換をサポートすべき
> ものだと思います。単純な話をすると、メールソフトの作者は、その作
> 者ごとにコード変換のルーチンを自作し付加しないといけないのか?
> ということです。単純な計算式でマッピングできるものであるのならと
> もかく、テーブル参照が必要なコード変換を各ソフトが持つのはちょっ
> と違うと思います。MSだって、SJIS<=>Unicode はAPIで持ってい
> るわけですしね。
メールソフトについていえば、大抵のメールソフトは内部で文字変換ルーチン
をもっていると思います。
(ISO 2022-JP から SJIS とかの変換は自前で行っていると思います。
Unicode を扱うことができるメールソフトってありましたっけ?)
TRON コードについていえば、ISO 2022-JP は単純な文字コード変換で済むと
思います。TRON コードにあって、ISO 2022-JP にない文字については、変換
不可能ではないでしょうか? (異体字の問題はありますが。。。)
> □多くのシステムでは、Unicode と他のコードの変換を実装するのは Java のラ
> □ンタイムの方です。UNIX や MacOS ではシステム内で Unicode を使っていな
> □いので、Java のランタイムが文字コードを変換して画面表示やファイルの読
> □み書きをしています。
>
> ランタイムというのは、結局のところOSごとの実装ですし、B-Free
> の場合、TRON コードへの相互変換は必要でしょ? だから、JavaVM を
> 移植する段階で、その移植者が B-Free での Unicode に対する実装を
> する必要があるわけですよね。で、それを JavaVM のみが使うのはもっ
> たいないと思いませんか?
うーん、Java VM 以外に、B-Free OS 上で動く(であろう) Unicode を扱うソ
フトウェアというのは、思い浮かばないので、Unicode 変換をサポートしても
メリットがあるのかわからないです。(SMB は、まだ Unicode ではないと思い
ましたが。。。)
> □Java1.1 の FAQ です。システムが Unicode に対応したために Java がうまく
> □動かないという笑えない笑い話が現実にあるのです。
>
> まぁ、Unicode そのものが当初の理想からかけ離れてしまった中途半
> 端な実装ですから仕方がないでしょう。だからといって、サポートしな
> くても良いというものではなくなってしまったので、ごまかしながら使
> うことになるんでしょうね。
これも、同上。
Unicode って、サポートしなくても良いというものではない(ややこしい!)と
いう位、使われているんでしょうか? 特に、B-Free OS ではあまり使われな
い文字コードと思っているんですが。。。
(Windows のファイルで Unicode が使われるようになれば別かもしれません)
> □私の意見
> □文字コードは、多少効率が落ちたとしても TRON コードを素直に実装したほう
> □がいいのではないでしょうか。
>
> ぼくもそう思うんですよね。まぁ、効率が落ちるのはともかく、文字
> 列を扱うプログラムを組むのが大変じゃあないかなぁ……と思いまして。
> OS側の実装が複雑になるのはしょうがないとしても、アプリケーショ
> ンを作る側には手軽に扱えた方がいいと思うんですよね。
>
>
> たとえば、4Byte 固定長化した TRON コードというのができるのであ
> れば、それもシンプルでいいかもしれませんね。で、TRON コード,
> ISO-2022, Unicode あるいは他の地域コードとの相互変換をAPIでサ
> ポートするという感じです。
>
> うーん……やっぱり、難しいなぁ。
API というか、文字コードの変換は、ライブラリでも十分かと思います。
Unicode のような、ほとんど他の文字コードと対応がない特異な規格 :-)はと
もかく、他の文字コードは JIS からの派生だと思っているので、変換も単純
な計算式でできるでしょう(TRON コードも JIS にある部分については、そっ
くりそのまま入っている(ハズ)だし)。
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d