From: matz@... (Yukihiro Matsumoto) Date: 2000-11-08T14:26:14+09:00 Subject: [ruby-dev:11428] Re: Ruby I18N まつもと ゆきひろです In message "[ruby-dev:11427] Re: Ruby I18N" on 00/11/08, Tanaka Akira writes: |ここで「理想的な文字コード系なんてないのさ、状況に応じて使えるものを使っ |ていくしかないんだ」と悟ると、複数の文字コードを同時に扱いたい気分にな |るのですが... 悟っていただけませんかね? 実は結構悟ってる方だと思うんですが(他人の邪魔はしたくないが 自分ではその存在を信じていないっていうような気分)。 じゃあ、なんで文字オブジェクトでなく整数(コードポイント)に固 執するのかというと、やはり互換性とメリットが見えないからなん ですね。というわけで、[ruby-dev:11427]のような説得メールはむ しろ歓迎します。 |* MIME な世界ではことごとく charset がついているので、どんな charset | が指定されても(その charset をサポートするモジュールが用意されていれ | ば、ないしは追加すれば)処理できるようなプログラムを書きたくなる。 これはできないといけないとおもいます。 が、その「処理」においての「文字オブジェクトの働き」は私には 自明じゃないです。ある文字コード系での「文字」が他の文字コー ド系において対応する文字があるとは限らない以上、あまり有効な 局面がありそうには思えないんです。 |* HTML とかの文字参照を扱うには、(内部コードとして主に何を使っていよう | が)UCS との変換が欲しくなる。 しかし、それは「任意の文字コード系のコードポイントからUCSの コードポイントへの対応表(関数)」という形で用意されるべきだと 思います。文字オブジェクトにその機能を持たせるなら、UCSを特 別扱いするというポリシーを導入することになりかねません(し、 任意の文字コード系の相互変換はそもそも不可能でしょう)。 「UCSのコードポイントへの対応表(関数)」を導入するのであれば、 コードポイントを示す整数だけで十分なような気がします。 私自身に「文字集合やエンコーディングの変換は明示的に」という 前提があるのも、(なんとなく暗黙の変換を支援しそうな)文字オブ ジェクトに抵抗がある理由かもしれません。 |* なんらかの autodetect 機能を入れることになるでしょうが、autodetect | の結果のコード自体を直接処理するモジュールがあるんなら、そのまま扱え | て何がいけない? なぜ EUC-JP とかに normalize する必要がある? | (もちろん(stateful なのとか)変換せざるを得ないものもあるでしょうけど | ね。) これはちょっと理解できませんでした。あ、「おおむねひとつの文 字コード系で閉じているのが普通」ってことに対してですね。 これはアプリケーション全体が「おおむねひとつの文字コード系で 閉じているのが普通」と考えているという意味ではなく(読み返す とそうとしか読めますが ^^;;;)、ただ、「ある文字列から取り出 した文字に対する処理」はひとつの文字コード系に閉じているんだ ろうなと思います。UTF-2000的アプローチをとらない以上、文字集 合と独立に存在できる「文字」はありえないので。 ある文字集合のある文字と別の文字集合のある文字が対応している と言う知識は、今回話している文字処理とは別の場所で与える必要 があると思います。 念のためですが、「そのまま扱える」ことは今回の開発の目標の一 つです。 autodetectも悩ましい点ですよねえ。 |他にもきっとたくさんあるに違いない... 「文字オブジェクトの必要性」を感じさせてくれる説得メールを待っ てます。;-) まつもと ゆきひろ /:|)