From: matz@... (Yukihiro Matsumoto) Date: 2000-11-13T13:30:37+09:00 Subject: [ruby-dev:11491] Re: class Character (was: Ruby I18N) まつもと ゆきひろです In message "[ruby-dev:11490] Re: class Character (was: Ruby I18N)" on 00/11/13, Tanaka Akira writes: |EUC-JP と Shift_JIS において、コードポイントはどのように割り当てるつも |りでしょうか? 現時点ではシングルバイトなものはそのまま、マルチバイトなもの は (byte1<<16) | byte2 で得られたものとしようと考えてます。 ですから、結果として |具体的にいえば、仮に、String::XXX#[] が n 番目のコードポイントを返すも |のであるとすれば、EUC-JP な "あ"[0] と Shift_JIS な "あ"[0] の値は等し |いのか異なるのか、ということです。 は異なるものとなるでしょう。あくまでも結果として、ですが。 で、そのコードポイントが自分のコード系を知っているかどうかは 未定です。 |まぁ、ひとつの立場ではあります。だれもが文字とコードポイントと整数の違 |いを理解してくれればうまくいきます。でもそれは無理だと歴史が証明してい |る気がします。 なるほどねえ。 |例えば、C でバイトと文字が両方とも char であることを信じているプログラ |ム(と信じている人の意識)を変えることは現在進行形な苦難の道なわけです。 | |同様に、コードポイントと文字は Fixnum であることを信じているプログラム |(と信じている人の意識)を変えることは苦難の道になるのではないかなぁ、と。 | |変える必要がある状況というのは、たとえば、合成文字のように Fixnum には |収められないものを文字として扱いたくなったときなどです。合成文字を扱う |コードをアプリケーション毎に入れていくか、文字列側に入れてアプリケーショ |ン側の不都合を一つ一つ潰していくかという選択肢はありますが、どちらにし |てもあまり楽しい作業ではないと思います。 | |文字クラスを入れようという提案は、文字そのものを与えることによって上記 |の信仰を防ごうという背景があります。EUC-JP と Shift_JIS のコードポイン |ト割当の話も、信仰を防ぐという背景は同じです。やりかたはずいぶんと違い |ますが。 | |そう信仰されてもべつに構わない、でしょうか? これについては現在の私は、まだ結論を持ってないです。「別に構 わないじゃない」という思いも正直あるのですが、ほぼ間違いなく 将来後悔しそう... |あと、合成文字のような面倒な問題は扱わない、というのは Unicode よりも |低い目標です。日本語については文字の数が多いという点を除けば処理は非常 |に簡単なので問題ないでしょうが。それ以外の問題は扱わない、というのは |「まぁ、日本語のことしか知らないとこうなるよな」といわれてもしかたがな |い選択でしょう。それだったらまじめに Unicode を実装した方がましだと思 |います。 | |Unicode は世界中の文字コードを集めて、その上での処理(アルゴリズム)を決 |めています。表示するには、比較するには、合成文字を扱うには、文字の並び |が逆だったらどうするか、とか。もちろんこれは Unicode 流のやりかたであっ |てそれが常に正しいという話ではありませんが、それなりには処理できるかも |しれません。もし、Unicode 「も」扱えるようにするのなら、これらの処理が |適切に収まるべき場所を用意する必要がありますが... これらの処理の処理の居場所は文字列(Stringとかそのサブクラス) にあるんじゃないかと思ってるんですが、そう思うのはただ単に私 がUnicode の勉強をサボってるからですかねえ。 まつもと ゆきひろ /:|)