[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1017] Re: 内部文字コード
三原@東工大です。
実は、以前の議論をまとめるように仰せつかっているのですが、
怠けて仕事をしていません。
# 「卒論が終わったら」という魔法の言葉で
# たくさんの仕事を抱えているような気が…
From: Kazuhiko Iwama <with@st.rim.or.jp>
Subject: [b-free: 1016] Re: 内部文字コード
Date: Fri, 06 Feb 1998 22:32:24 +0900
> 岩間です。
> ■ Tetsuji Ochiai さんのメールからの引用です
> □太田昌孝さんの本にもありましたが、ISO-2022もTRONコードと同じく
> □対外交換用のフォーマットで、可変長だったと思います。
>
> えぇ。可変長であれば、現時点で仕様がはっきりしている方がいいと
> 思いまして。
私は、現時点で仕様が決まっていないのは問題でないと考えています。
理由は、後ろ向きで、多国語対応環境が決まるまでに実装が始まったりはしな
いでしょうから…
もっと早く実装していれば議論になったと思いますが、この春には 3B/V が出
るでしょうから、今となってはそれを見てからでも遅くはないと考えます。
さらに、ISO-2022 の中に含まれていない文字を扱うには新たに文字集合を定
義しなければなりません。私たちに10万字の文字集合を定義するのはきっと無
理でしょう。それは荷が大きすぎます。
文字集合間のマッピングの問題は、次の話にもからみます。
> そうなんです。中途半端な独自コードを使うくらいなら、いっそのこ
> と Unicode にしてしまった方がいいのではないかと思います。JavaVM
> を実装するのであれば、いやでも Unicode の実装が必要ですからね。
多くのシステムでは、Unicode と他のコードの変換を実装するのは Java のラ
ンタイムの方です。UNIX や MacOS ではシステム内で Unicode を使っていな
いので、Java のランタイムが文字コードを変換して画面表示やファイルの読
み書きをしています。
Unicode に対応していれば言いというものでもなくて…
Windows の場合はシステムが Unicode を使っているので直接 Unicode を渡せ
るのですが、既存のコードとのマッピングが Sun の定義と Microsoft の定義
で食い違いがあり、一度 Unicode に変換してしまうともとに戻らなくなると
いう問題が起きています。食い違いのある文字ではどうなるかというと、ウィ
ンドウに文字を入力すると、Java は内部で Unicode に変換します。Java は
Unicode を直接 Windows の API に渡すのですが、Windows ではもとの文字は
別の位置にマッピングされることになっているので未定義の文字とされてしま
います(日本語フォントでは定義されていなかったりとか)。この問題は
Java1.1 の FAQ です。システムが Unicode に対応したために Java がうまく
動かないという笑えない笑い話が現実にあるのです。
JavaVM を移植するならマッピングを定義しなければならないのですが、
難しそうです。
私の意見
文字コードは、多少効率が落ちたとしても TRON コードを素直に実装したほう
がいいのではないでしょうか。
--
三原 克大 (Katsuhiro MIHARA)
東京工業大学理学部情報科学科
mailto:mihara@is.titech.ac.jp
http://www.is.titech.ac.jp/%7Emihara/index-j.html