From: "U.Nakamura" Date: 2008-09-25T06:03:31+09:00 Subject: [ruby-dev:36532] Re: Encoding.default_internal のためのパッチ こんにちは、なかむら(う)です。 In message "[ruby-dev:36523] Re: Encoding.default_internal のためのパッチ" on Sep.25,2008 00:49:10, 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