[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1023] Re: 内部文字コード
三原@東工大です。
私が論点を広げすぎてしまったので整理したいのですが、
ここで話し合っているのは
・OS 内部で使う文字コードをどうするか
・外部と通信するときの文字コードをどうするか
のどちら、あるいは両方でしょうか。
ここをはっきりさせないと、後の話が変わってしまいますから。
私は、OS 内部で使う文字コードについて話をしていると思っています。
From: Kazuhiko Iwama <with@st.rim.or.jp>
Subject: [b-free: 1020] Re: 内部文字コード
Date: Sat, 07 Feb 1998 11:43:19 +0900
> 岩間です。
>
> ■ Katsuhiro MIHARA さんのメールからの引用です
> □もっと早く実装していれば議論になったと思いますが、この春には 3B/V が出
> □るでしょうから、今となってはそれを見てからでも遅くはないと考えます。
>
> ぼくもそう思ったんですが、3B/V とバイナリ互換性はないんですよ
> ね? だったら、内部文字コードは
> 3B/V のことを考えなくてもいいのではないでしょうか?
3B/V とバイナリ互換性を持たせるわけではないのですが、
一から作ったとしても TRON コードを扱うとなると難しいんです。
そのことは次の話から。
> たとえ荷が大きすぎても、内部コード云々とは関係なく、TRON コー
> ドという選択をした時点で、何らかの形でコード変換をサポートすべき
> ものだと思います。単純な話をすると、メールソフトの作者は、その作
> 者ごとにコード変換のルーチンを自作し付加しないといけないのか?
> ということです。単純な計算式でマッピングできるものであるのならと
> もかく、テーブル参照が必要なコード変換を各ソフトが持つのはちょっ
> と違うと思います。MSだって、SJIS<=>Unicode はAPIで持ってい
> るわけですしね。
コード変換をサポートすべきだと私も考えています。
3B/V の本格的多国語環境でも、コード変換を OS がサポートして通信や検索
に対処することにしていますから。
でも、内部コードを ISO-2022 にするか Unicode にするか TRON コードにす
るかは別の話だと考えます。
B-Free の場合、TRON コードを使って外部とも通信できなければならない(で
なければおもしろくない)ので、OS 内部では TRON コードにある文字を全て
区別できなければなりません。OS 内部で使われる文字コードが TRON コード
より大きな集合でないと、TRON コードの利点が失われてしまうんです。
ISO-2022 に登録されている漢字を含むコードは、中日韓の規格を集めても
TRON コードを全部サポートできないでしょう。
# 調べていないので説得力がないなあ。
B-Free が内部コードとして ISO-2022 を採用したら、サポートされていない
文字の扱い方が問題になります。サポートするとしたら、ISO-2022 の中に新
しい文字コードを - 既存の規格との関係を考えつつ - 定義しなければなりま
せん。ISO-2022 の中に TRON コードを組み込む作業は私たちには荷が重いと
思ってます。
同様に、Unicode を内部コードにするとしたら、TRON コードを扱えるように
するには Unicode を拡張しなければならないでしょう。どうします?
> ランタイムというのは、結局のところOSごとの実装ですし、B-Free
> の場合、TRON コードへの相互変換は必要でしょ? だから、JavaVM を
> 移植する段階で、その移植者が B-Free での Unicode に対する実装を
> する必要があるわけですよね。で、それを JavaVM のみが使うのはもっ
> たいないと思いませんか?
確かにもったいないと思います。
OS がコード変換機能を持ったほうが便利です。
恐れているのは、変換した結果に食い違いが出ることです。
Java の場合、Unicode -> ISO-2022-JP, Shift_JIS, EUC への変換は Sun が
提供していますからすでにあります。
Unicode -> TRON と TRON -> ISO-2022-JP, Shift_JIS, EUC は B-Free が提供。
Unicode -> Shift_JIS と Unicode -> TRON -> Shift_JIS で
結果が違ったらどうなるんでしょうか。
東大と PMC のアナウンスを待たないと分からないんですけどね。
# 中村正三郎氏の意見はよく分かります。
# 商品化前にレビューの時間が欲しいものです。
> まぁ、Unicode そのものが当初の理想からかけ離れてしまった中途半
> 端な実装ですから仕方がないでしょう。だからといって、サポートしな
> くても良いというものではなくなってしまったので、ごまかしながら使
> うことになるんでしょうね。
Unicode のどたばたを見ていると、文字コードにひるんでしまうんです。
Microsoft や Sun や Apple や Netscape や、あれだけマンパワーがある会社
が集まってもうまくいかないのですから。
# Java のカンファレンスがあると、国際化関係で優秀な人が欲しいという話
# がどこからも出るそうです。私たちは応えられるか?
東大と PMC が作ってくださるなら、それをいじらず使いたいんです。
> たとえば、4Byte 固定長化した TRON コードというのができるのであ
> れば、それもシンプルでいいかもしれませんね。で、TRON コード,
> ISO-2022, Unicode あるいは他の地域コードとの相互変換をAPIでサ
> ポートするという感じです。
坂村健氏は、TRON コードは無制限と繰り返しおっしゃっています。
あくまで規格上の話です。
2Byte のコード選択空間(造語)を使い切るかどうかでしょう。
# たぶん使い切らないんじゃないかと思いますが、
# 準 TAD のように実装を優先させると後が怖い…
--
三原 克大 (Katsuhiro MIHARA)
東京工業大学理学部情報科学科
mailto:mihara@is.titech.ac.jp
http://www.is.titech.ac.jp/%7Emihara/index-j.html