From: "NARUSE, Yui" Date: 2010-05-12T17:49:51+09:00 Subject: [ruby-dev:41297] Re: [BUG:1.9] BINARY should not be ASCII-compatible 成瀬です。 2010年5月11日20:44 Yugui : > wycatsと話しまして、railsサイドでのM17N実例からの知見というものを聞き取りました。 > それによれば、誤ってBINARYなまま(バイト列のまま)低レベルレイヤーから上がってきた文字列を、 > 文字列リテラル由来の(script encodingな)文字列と結合した際の互換性エラーが問題で、 > 多数のバグ報告に遭遇しているそうです。 初期に「ASCII-8BIT ってなんだよ」という悲鳴が上がるのは Ruby 自体でも結構ありましたね。 > これは第一には、データベースドライバなどレイヤー境界にあるソフトウェアモジュールの > バグであるのは確かです。しかしながら、このバグを検出するにあたりBINARYが > ASCII-compatibleであることが妨げとなっているとのことです。低レベルから上がってくる > 文字列データが西欧語である場合、バイト列の殆どは0x20-0x7Eです。このため、殆どの場合は > エンコーディングがBINARYであるにも関わらずscript encodingの文字列との結合に成功します。 > そして、アクセント付き文字のようなものが稀にデータとして出現したときにだけこのバグが発現します。 Rails では非 ASCII なケースのユニットテストを書かないんですか? > 結局の処、BINARYエンコーディングをASCII-compatibleとして扱うのは英語を処理する > アプリケーションを救うにも足りないのみならず、それらのアプリケーションないし > それが依存する低レベルのバグを早期検出するのを疎外しているわけです。 まぁ、そういう見方はあるでしょう。 > 1.9.1リリースから時間を経て、1.9.2リリースも準備段階に入り、 > この段階に及んで大きな仕様変更とも取れるのは承知ですが、 > BINARYエンコーディングをASCII compatibleとしないことを提案します。 wycats が言うのでしたらそのレベルの思いつきでも心情はわかりますが、 yugui さんにはもうちょっと詰めてから仰って欲しいところではあります。 > そもそも、octet streamを大クラス的に文字列に統合するためのエンコーディングを、 > script encodingとさえできる状況が異常であったのです。 script encoding はこの話の本質とは違いますよね。 > wycatsから聞いたRails界での実例からは、ドライバのバグに由来する理不尽な例外に > アプリケーション開発者が困惑している状況を認識しました。そして、wycatsによれば > 「この理不尽に見舞われる限りユーザーは1.9に移行しないだろう」と。 これ自体は Rails のアダプタが古いドライバを蹴ればいい話だと思います。 > 何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby > 1.9がまともに使える言語であるための障害と認識し、バグと認定します。 > ご意見を伺いたく思います。 ここまでの問題意識と、よりよい仕様を探っていく姿勢そのものは正しいと思います。 しかし、ここまで荒削りの案をぼちぼち動いている現状をバグ扱いして、 1.9.2 に入れようというのはリリースエンジニアリング的にもおかしいですし、 またあまりに見通しが甘すぎます。rb_str_new の戻り値を ASCII incompatible に した場合、今年中のリリースすら無理でしょう。 そもそも、現状の Ruby 1.9.2 のリリース時期は 1.9.1 からの乖離や、1.9.1 への固定化を 避ける意味からすると受忍限度の限界で、これ以上遅らせることには全面的に反対です。 また、この変更が互換性を壊すことがそもそもの目的である以上、採用した場合リリース時期への 影響は不可避でしょう。つまり、1.9.2 での変更は有りえないと思います。 この案自体の評価は率直に言って判断できる水準にないと思うので保留します。 -- NARUSE, Yui naruse@airemix.jp