From: matz@... (Yukihiro Matsumoto)
Date: 2000-11-03T00:44:53+09:00
Subject: [ruby-dev:11372] Re: Ruby I18N

まつもと ゆきひろです

In message "[ruby-dev:11370] Re: Ruby I18N"
    on 00/11/02, TAKAHASHI Masayoshi <maki@inac.co.jp> writes:

|> ま、それはそれとして、元々の文字集合は元のままエンコーディン
|> グだけ揃えるというアイディアよりは、元の文字コード(文字集合
|> とエンコーディング)のまま、処理する方向に傾いています。
|
|後者のアイデアはどことなくUTF-2000の思想を彷彿とさせますね。
|内部表現に依存しないAPI、というところとか。

UTF-2000ってそんなのなんですか？ 守岡さんにヒアリングしにい
かねばならんかな。

|# かっこいい……。
|# あとはパフォーマンスの問題がクリアできればいいのですが、
|# PerlやPython流の「UTF-8決め打ち」に比べ、遅くなることはあれ、
|# 早くなることはないんですよね。

えーと、速度的な要因については

  * 入出力時に文字コード系の変換がないぶん、速い

  * マルチバイト文字対応の場合、UTF-8決め打ちより速くはなら
    ないだろうが、遅くもならないようにはできるんじゃないか

と見積もってます。甘すぎかな？

|変換テーブルが複数ある問題は、デファクトスタンダードな一つに
|統一させる、という解決も可能かもしれませんが、YEN SIGN問題だけ
|は「過去の遺産は捨てる」とか「ヒューリスティクスを導入する」
|(間違ったときはごめんなさいする)とか「全部手で直す(;_;)」とか
|以外、どうにも解決しようがないんじゃないでしょうか。

同感です。

|あるいは、「どうせもうすぐ世の中みんなUnicodeになるから、
|(c)はさして問題ではない」という人はいるかもしれませんけど、
|それはちょっと嫌すぎる……。

その嫌さ加減をもうちょっとアピールしないと、特に外人から「な
んでわざわざそんなことするの」と言われそうなんですよねえ。

|# 『びっくり!  君の教科書もUnicode』というか(謎)

えと、ゴレンジャー？

                                まつもと ゆきひろ /:|)