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

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



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

     岩間です。

■ Katsuhiro MIHARA さんのメールからの引用です
□私は、OS 内部で使う文字コードについて話をしていると思っています。

     OS内部の話です。


□B-Free の場合、TRON コードを使って外部とも通信できなければならない(で
□なければおもしろくない)ので、OS 内部では TRON コードにある文字を全て
□区別できなければなりません。OS 内部で使われる文字コードが TRON コード
□より大きな集合でないと、TRON コードの利点が失われてしまうんです。

     やはり、そう思いますか。ぼくもそう思うんですが、本当にその
    選択しかないのかな……と思いまして。いろいろと書いているうち
    に、いいアイデアが浮かばないかなと。(^^;

     それに、TRON  コードは完全に別APIで対応するのでもいいと
    も思っていたんですが、やっぱり無理がありますね。


□ISO-2022 に登録されている漢字を含むコードは、中日韓の規格を集めても 
□TRON コードを全部サポートできないでしょう。
□# 調べていないので説得力がないなあ。

     そうでしょうね。サポートできるのであれば、わざわざ新しいコ
    ード体系を提唱する意味はありませんものね。(^^;


□恐れているのは、変換した結果に食い違いが出ることです。
□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 で
□結果が違ったらどうなるんでしょうか。

     そもそも、Unicode のみでは、使用言語の区別はつかないわけで
    すから(そうでしたよね?)、字体にコードを振っている TRON コ
    ードでは、Unicode -> TRON の変換が一意にできないと思います。
     それ以前に、Unicode どころか SJIS/EUC からの変換ですら、旧
    JISと新JISとの区別ができないので、正確な変換はできませ
    んよね。

     というわけで、PMC が 3B/V でどう対処するのか、非常に興味が
    あります。B-Free  では……コード体系と属性とのペアで変換する
    ようなAPIを提供するのが限度でしょうね。


□Unicode のどたばたを見ていると、文字コードにひるんでしまうんです。
□Microsoft や Sun や Apple や Netscape や、あれだけマンパワーがある会社
□が集まってもうまくいかないのですから。
□# Java のカンファレンスがあると、国際化関係で優秀な人が欲しいという話
□# がどこからも出るそうです。私たちは応えられるか? 

     これって、結局、必要としていない地域の技術者(企業)が発言
    力をもって話し合っているのですから、議論の方向がどうしても手
    を抜く(=低コストな)方向に偏ってしまうのではないかなって思
    います。だから、優秀な人以前に、コストを度外視した実装を許し
    てもらえるかどうかなのではないですか? 

     そういえば、他の国際化関連の研究をしているところと TRON 
    Project の交流ってどの程度あるのでしょうね。そういうところと
    協力していかないと難しいでしょうね。


□坂村健氏は、TRON コードは無制限と繰り返しおっしゃっています。
□あくまで規格上の話です。
□2Byte のコード選択空間(造語)を使い切るかどうかでしょう。

     では、すべての文字に「言語指定コード」を付加して扱うという
    のはどうでしょう。で、4Byte でパックして扱うんです。これであ
    れば、TRON コードを包括したコード体系と、4Byte  単位での文字
    処理というシンプルな扱いが可能になりますよね。
     TRON  コードに比べ2倍程度の作業領域が必要になりますが、状
    態遷移を保持をしなくてすむし、文字列の挿入削除や検索などに対
    してもメリットも大きいと思います。


     というわけで、長くなって、申し訳ありませんです。(_o_)

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