[ruby-dev:41104] Rails3 M17N

まつもと ゆきひろです

Yehuda KatzからRails2を1.9で動かした場合、エンコーディング関
係の例外が大量に発生するので、一般ユーザのRail3への移行に障
害になる可能性があると連絡をもらいました。

彼らだけで1.9を用いた適切なM17N化を自分で考えるのは大変困難な
ことだと思いますから、助けてあげたいところです。いぜんとして
RailsはRubyにとって重要なアプリケーションなので、Rails3に対し
て親切にしておくのは有意義だろうと考えます。

とはいえ、私自身がRailsやWebアプリについて無知なのは認めざる
をえません。また、自分が基本デザインしたとはいえ、M17Nについ
ても、成瀬さんにかなわないと言うのが実情です。

というわけで、むしろ私の方が助けていただきたい。

ざっと考えてみたところ、文字列のソースは

 (1) Rails本体
 (2) プラグイン
 (3) テンプレート
 (4) モデルなどユーザーが書いたRubyコード
 (5) データベース
 (6) クライアント(ブラウザ)からの入力

に分類できるのではないかと思います。漏れはありませんか？

(1) Rails本体についてはASCIIのみにしなさいと言いたいところで
    す。そんなに困難ではないと思うのですが。

(2) プラグインもASCIIのみにするか、そうでなければプラグインが
    提供するエンコーディングを明示することを求めたいところで
    す。ASCIIのみでない場合、ユーザアプリとプラグインのエンコー
    ディングが一致しない場合、そのプラグインは使えないという
    のは厳しすぎる制約でしょうか。

(3) ユーザアプリは自分が内部エンコーディングとして用いるエン
    コーディングをひとつ決める必要があるとします。テンプレー
    トはそのエンコーディングで記述しなければなりません。

(4) ユーザコードも同様です。マジックコメントなしでも内部エン
    コーディングで記述しているとみなしてあげると親切かもしれ
    ません。

(5) データベースは難しい問題ですが、データベースのエンコーディ
    ングを指定して、内部エンコーディングに明示的にencode()す
    ることになるのではないでしょうか。

(6) これは私の知識が足りないところです。requestに含まれる情
    報には適切な(信頼できる)エンコーディング情報がついている
    のでしょうか。ついているのであれば、内部エンコーディング
    へencode()してやればよいわけですが。

このことから考えると、Railsの設定ファイルに、

  * アプリ内部エンコーディング
  * データベース(ごとの)エンコーディング

を、(たぶんデフォルトはUTF-8で)設定できるようにしてやれば、
外部インタフェースとしては十分のような気がします。で、Rails
内部で必要に応じてencode()しまくるんでしょうね。

さて、大量に見落としがある気がして不安なのですが、みなさんの
ご意見を聴かせてください。上記のアイディアが寝言でないと思え
たら、Railsチームに提案します。

                                まつもと ゆきひろ /:|)