[ruby-dev:11490] Re: class Character (was: Ruby I18N)

In article <[e-mail]>,
  [e-mail] (Yukihiro Matsumoto) writes:

> ですから、今後とも提案、助言は歓迎します。

ふむ。では少し違う側面から。

EUC-JP と Shift_JIS において、コードポイントはどのように割り当てるつも
りでしょうか?

具体的にいえば、仮に、String::XXX#[] が n 番目のコードポイントを返すも
のであるとすれば、EUC-JP な "あ"[0] と Shift_JIS な "あ"[0] の値は等し
いのか異なるのか、ということです。

たぶん、UTF-8 な "あ"[0] とは異なるものになるでしょうから、私としては
ぜひとも異なるものにして欲しいと思っています。

これを同じものにしてしまうのは、日本語圏内における新たな文字コードを設
計することそのものです。文字コードを新しく作ることはしないと書いていた
ような気がするので、そうはしないのであろうと期待していますけれど。

それに、ISO-2022-JP (を適当に変換して stateless にしたもの)な文字列を
扱おうと思えば、JIS X 0208 1978 をどうするかも問題になりますしね。

> というか、標準で提供する文字列処理から「文字」を切り離してし
> まうことを考えています。つまり、バイト列またはコードポイント
> 列だけを扱うというスタンスです。そうすると文字列処理は数値の
> 並びの処理に還元されるので。これが「それなり」ってことなのか
> しら？

まぁ、ひとつの立場ではあります。だれもが文字とコードポイントと整数の違
いを理解してくれればうまくいきます。でもそれは無理だと歴史が証明してい
る気がします。

例えば、C でバイトと文字が両方とも char であることを信じているプログラ
ム(と信じている人の意識)を変えることは現在進行形な苦難の道なわけです。

同様に、コードポイントと文字は Fixnum であることを信じているプログラム
(と信じている人の意識)を変えることは苦難の道になるのではないかなぁ、と。

変える必要がある状況というのは、たとえば、合成文字のように Fixnum には
収められないものを文字として扱いたくなったときなどです。合成文字を扱う
コードをアプリケーション毎に入れていくか、文字列側に入れてアプリケーショ
ン側の不都合を一つ一つ潰していくかという選択肢はありますが、どちらにし
てもあまり楽しい作業ではないと思います。

文字クラスを入れようという提案は、文字そのものを与えることによって上記
の信仰を防ごうという背景があります。EUC-JP と Shift_JIS のコードポイン
ト割当の話も、信仰を防ぐという背景は同じです。やりかたはずいぶんと違い
ますが。

そう信仰されてもべつに構わない、でしょうか?

あと、合成文字のような面倒な問題は扱わない、というのは Unicode よりも
低い目標です。日本語については文字の数が多いという点を除けば処理は非常
に簡単なので問題ないでしょうが。それ以外の問題は扱わない、というのは
「まぁ、日本語のことしか知らないとこうなるよな」といわれてもしかたがな
い選択でしょう。それだったらまじめに Unicode を実装した方がましだと思
います。

Unicode は世界中の文字コードを集めて、その上での処理(アルゴリズム)を決
めています。表示するには、比較するには、合成文字を扱うには、文字の並び
が逆だったらどうするか、とか。もちろんこれは Unicode 流のやりかたであっ
てそれが常に正しいという話ではありませんが、それなりには処理できるかも
しれません。もし、Unicode 「も」扱えるようにするのなら、これらの処理が
適切に収まるべき場所を用意する必要がありますが...

私の推測としてはこの調子でいくとわりと中途半端というか、寿命が短いとい
うか、不満を解消しにくいものになるんじゃないかなぁ、と思っています。個
人的には多言語処理はめったにしないので、まったく困りませんし、いろんな
立場があっていいという主義なのでそれはそれでいいと思ってはいますが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]
「くっだらないコト聞いちゃったねー$(C⊇ ごっめーん$(C⊇」
  (魔法使い養成専門 マジックスター学院 2, 南澤ミヅキ)