ruby-dev

Yuguiです。


> で、おおむねここまでの議論でカバーできていると思うんですが、
> Rails びと的には問題を切り分けできていないように思うので、
> 彼らにはまずデータベースのドライバが適切なものになっているかの確認を
> 徹底させるのがよいかと思います。
> というか、Rails 3 側でドライバのバージョン見た方がいいんじゃないかな。
>
> とりあえずこれでかなり地雷が減ると思うので、データベース周りが綺麗に
> なったところで改めて残った問題を見るとよいかと思います。


wycatsと話しまして、railsサイドでのM17N実例からの知見というものを聞き取りました。
それによれば、誤ってBINARYなまま(バイト列のまま)低レベルレイヤーから上がってきた文字列を、文字列リテラル由来の(script
encodingな)文字列と結合した際の互換性エラーが問題で、多数のバグ報告に遭遇しているそうです。

これは第一には、データベースドライバなどレイヤー境界にあるソフトウェアモジュールのバグであるのは確かです。しかしながら、このバグを検出するにあたりBINARYがASCII-compatibleであることが妨げとなっているとのことです。低レベルから上がってくる文字列データが西欧語である場合、バイト列の殆どは0x20-0x7Eです。このため、殆どの場合はエンコーディングがBINARYであるにも関わらずscript
encodingの文字列との結合に成功します。そして、アクセント付き文字のようなものが稀にデータとして出現したときにだけこのバグが発現します。

結局の処、BINARYエンコーディングをASCII-compatibleとして扱うのは英語を処理するアプリケーションを救うにも足りないのみならず、それらのアプリケーションないしそれが依存する低レベルのバグを早期検出するのを疎外しているわけです。

1.9.1リリースから時間を経て、1.9.2リリースも準備段階に入り、この段階に及んで大きな仕様変更とも取れるのは承知ですが、BINARYエンコーディングをASCII
compatibleとしないことを提案します。そもそも、octet
streamを大クラス的に文字列に統合するためのエンコーディングを、script encodingとさえできる状況が異常であったのです。
wycatsから聞いたRails界での実例からは、ドライバのバグに由来する理不尽な例外にアプリケーション開発者が困惑している状況を認識しました。そして、wycatsによれば「この理不尽に見舞われる限りユーザーは1.9に移行しないだろう」と。

何か積極的にBINARYをASCII-compatibleにしておくべき理由がない限り、私はこれをRuby
1.9がまともに使える言語であるための障害と認識し、バグと認定します。
ご意見を伺いたく思います。


-- 
Yuki Sonoda (Yugui)
yugui@yugui.jp
http://yugui.jp

Thread

Prev Next

In This Thread

Prev Next