[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