[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 <[e-mail]> 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 の勉強をサボってるからですかねえ。

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