From: "NARUSE, Yui" <naruse@...>
Date: 2008-09-25T06:43:25+09:00
Subject: [ruby-dev:36536] Re: Encoding.default_internal   	のためのパッチ

成瀬です。

Yukihiro Matsumoto wrote:
> |混乱のデメリットが大きいそうなことは否定しませんが、CSVライブ
> |ラリがUTF-16対応に苦労するというのはそもそもrubyのm17n機能が
> |不完全なのではないかという気がします。
> |混乱とかいう話よりも、UTF-16だろうがなんだろうが自然に扱える
> |ようにするコストが問題なんだと言われると、受け入れるしかない
> |ですが...
> 
> 「不完全ではないか」という指摘には、その通りと答えざるをえま
> せん。具体的には"text=#{str}"のようなケースで、strがUTF-16だっ
> たりするとうまくいきません。あと、正規表現もリテラルでマッチ
> できませんし。要するに今のM17NではASCII コンパチでないエンコー
> ディングを直接扱うところは十分でなく、近い将来(1.9.1 とか
> 1.9.2)で完成する見込みもないので、直接UTF-16テキストを扱うこ
> とは(当面)サポートしなくてもよいのではないか、という意味です。

む、UTF-{16,32} に対する見通しがわたしと若干違うかも。

思うに、現在懸案の諸々の問題に一通り解はあって、端的に言えば
「7bit ASCII String を UTF-16 にしてくっつければいいだけ」です。

例えば、UTF-16LE の str="あ" に対して "text=#{str}" を行った場合、
期待される動作は UTF-16LE な "text=あ" に決まっています。
つまり、仕様上の悩みはありません。
実装も "text=".encode("UTF-16LE") するだけですので、問題ありません。
処理速度もまぁ大丈夫でしょう。

正規表現も仕様上の悩みは全くありません。
実装も、US-ASCII or UTF-8 ならば裏で UTF-16LE にコンパイルしなおす、
という方法があります。
具体的には Regexp.new(/\u3042/.source.encode("UTF-16LE")) と簡単なものです。

つまり、特に悩む点は多くなく、単に時間が足りないだけです。
とはいえ、作業量も絶望的なほど多いわけでもないので、
物好きが一人現れれば片付く量でしょう。

> |これができないようになるのであれば、私にとっては非常に残念な
> |決定ということになります orz
> 
> 個人的には「UTF-16→UTF-8→UTF-16」モデルで十分であり、かつ
> ASCII互換問題を回避できることの嬉しさの方が大きいと思っている
> のですが(正規表現とかも比較的自然に使えるようになるし)、いや、
> それでもUTF-16をそのまま変換なしに扱える方が良いのだというこ
> とであれば、ぜひ指摘してください。

以上のように、UTF-{16,32} はバイト列としては ASCII 非互換でも、
コードポイント列としては ASCII 互換なので、
そこまで悩みが多いわけではないのです。

-- 
NARUSE, Yui  <naruse@airemix.jp>