こんにちは、なかむら(う)です。

In message "[ruby-dev:36523] Re: Encoding.default_internal   のためのパッチ"
    on Sep.25,2008 00:49:10, <matz / ruby-lang.org> wrote:
| 今日一日考えて、導入することにしました。
| 
| 以下のような仕様を考えています。

びっくり仰天な感じですが、しばらく考えないとよくわかんなさそ
うです。
実質的に、UTF-8化へ利用者を導くことになりそうですが、それも意
図のうちだということですよね?


| これにともない、UTF-{16,32}対応はencから外した方がよいかもし
| れないと思うようになりました。これらはUTF-8とは符号化方式の
| 違いしかありません。まったくデータロスなしに変換できる以上、
| 対応するメリットは大きくなく、混乱のデメリット(たとえばCSVラ
| イブラリがUTF-16対応に苦労した)の方が大きそうです。

「encから外す」というのはどういう意味でしょうか?
「データロスなしに変換できる」という言葉があるということは、
変換はサポートするけど変換した結果得られる文字列は単なるバイ
ナリ列としてrubyは扱う、ということでしょうか?
それとも変換自体もサポートしないから勝手に外部のライブラリな
りなんなりを使って変換してからrubyに食わせろ、ということでし
ょうか?

混乱のデメリットが大きいそうなことは否定しませんが、CSVライブ
ラリがUTF-16対応に苦労するというのはそもそもrubyのm17n機能が
不完全なのではないかという気がします。
混乱とかいう話よりも、UTF-16だろうがなんだろうが自然に扱える
ようにするコストが問題なんだと言われると、受け入れるしかない
ですが...


以下は完全な私事ですが、私の手元には膨大なUTF-16LEのデータが
存在します。
つい先日もtrunkのm17n機能を使って処理したのですが、何の問題も
なく(というのは嘘で、open時にバイナリ指定が必要と怒られてちょ
っと困りましたが)処理できてとても嬉しかったです。
私のユースケースではUTF-16LEでのデータの入出力は日常のことで
あり、rubyのm17n機能に期待するのは何よりもUTF-16LEのデータを
自然に扱えることでした。
これができないようになるのであれば、私にとっては非常に残念な
決定ということになります orz


それでは。
-- 
U.Nakamura <usa / garbagecollect.jp>