From: "NARUSE, Yui" Date: 2010-11-02T22:34:53+09:00 Subject: [ruby-dev:42515] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports many errors and failures without iconv (2010/11/02 21:50), Kouhei Sutou wrote: > 須藤です。 > > In<4CCF03C6.3090504@airemix.jp> > "[ruby-dev:42510] Re: [Ruby 1.9-Bug#3990][Closed] tests of rexml/rss reports > many errors and failures without iconv" on Tue, 2 Nov 2010 03:15:40 +0900, > "NARUSE, Yui" wrote: > >> この変更では、Ruby M17N の encoding system を使うようにしていますが、 >> 導入した非互換変更には反対です。 > > その意見はわからなくもわからなくもないです。 > 私も迷いました。 > > ただ、反対の理由として以下は弱いと感じます。 > 非推奨とかいつなくなるとかが確定しているくらい必要だと感じます。 わざわざ非互換を入れるようなライブラリではないという趣旨です。 必然性のある物ならばしょうがないですが、これは違うと思います。 >> 総論として、REXML は Ruby 的に非推奨という扱いになりつつあるというのは >> 合意がとれていると思われるところ、この状況下で非互換変更をするのは >> 避けるべきだと思います。 > > 個人的には標準添付されているXMLパーサはRubyのみで書かれたも > のの方がいいと思っています。Nokogiriとかはgemでいいと思って > います。 Nokogiri を添付すべきだとは言っていません。 >> また、今回の REXML::Document#encoding, REXML::XMLdecl#encoding, >> REXML::Output#encoding and REXML::Source#encoding は、 >> ドキュメントが自称しているエンコーディングと、Ruby が解釈し使っている >> エンコーディングは分離するべきでしょう。 > > 意図していることを理解できている自信がないのですが、エンコー > ディングを表すのにEncodingオブジェクトを使うのはよくない、と > いうことですか？ はい。 それぞれのエンコーディングの実際上の射程範囲は文脈によって代わります。 そして、HTTP や HTML、XML などのエンコーディングと、Ruby M17N の エンコーディングは一部射程範囲が異なります。 >> 直近では UTF-16BE/UTF-16LE は BOM なしを意味するので、 >> BOM 付きの UTF-16 が欲しいときに困ります。 >> （なお、UTF-16 は ASCII incompatible なので色々バグってる気がする） > > もともとREXMLは出力時にBOMをつけないのですが、BOM付きの > UTF-16が必要になるのはどういう場面を想定していますか？ BOM をつけないのは UTF-8 の話ではありませんか。 たとえば、1.9.2 までは以下で BOM 付き big endian な UTF-16 で出力しますね。 require 'rexml/document' doc = REXML::Document.new doc << REXML::XMLDecl.new('1.0', 'UTF-16') doc.write(s="") => "\xFE\xFF\x00<\x00?\x00x\x00m\x00l\xFE\xFF\x00 \x00v\x00e\x00r\x00s\x00i\x00o\x00n\x00=\x00'\x00" これの結果は、現在以下の通りになってしまっています。 => "" これによって、少なくとも XMLDecl#encoding の戻り値の意味は、 XML 宣言の encoding 属性で用いられる値であって、内容の Ruby の文脈における encoding とは異なる物であるといえるのではないでしょうか。 そもそも、UTF-16 の場合 UTF-8 に変換して扱うし。 > ここも意図を理解している自信がないのですが、RubyのEncodingは > まだIconvの代わりには使えないということですか？ まず、文字列のエンコーディングを扱う部分と、変換を司る transcode を 分けて考える必要があります。 で、iconv の代わりになる物は transcode であって Encoding は別の話です。 >> というわけで、encoding メソッドは以前のままにして、Encoding オブジェクトを >> 返すメソッドを新設した方がよいのではないかと思います。 > > encodingよりもEncodingオブジェクトを返すのに適切な名前を思い > つけないので、そういうAPIにはしない方がよいと思っています。 Encoding オブジェクトバージョンの名前をどうするか、というのは、 それはそれで難しいのですが、上述の理由からそうせざるをえないと思います。 私案では string の encoding なので str_encoding かなぁ。 -- NARUSE, Yui