From: masayoshi takahashi Date: 2010-04-30T13:23:59+09:00 Subject: [ruby-dev:41109] Re: Rails3 M17N 高橋征義です。 2010年4月30日11:32 Yukihiro Matsumoto : > |2. 変換したいencodingがある項目はアプリ側で把握し、 > | UTF-8へのforce_encodingを試みる > > UTF-8なんですか。私はアプリエンコーディングを用いるべきだと思っ > ていたのですが。ISO-8859-1なページからPOSTされたリクエストで > もUTF-8で来るというのが最近のブラウザの挙動なんでしょうか。もっ > ともこの辺はバッドノウハウもたくさんありそうですが。 # 私見では、アプリ内での内部エンコーディングはUTF-8で統一しないと # 収拾つかないんじゃないかなあ、という気がします。 > 一般的にどのようにリクエストのエンコーディングを推測している > のでしょう。ヒューリスティック？ 一般的には、フォーム等からのPOSTの場合、そのフォームの 画面のエンコーディングが使われます。つまりShift_JISの HTML内のフォームに入力してPOSTした場合のエンコーディングは Shift_JISのはず。 そのフォームのHTML自体もフレームワーク側で生成して いるはずなので、その文字コードはわかってるはず。なので、 それに合わせておけば処理できる感じです。 さらに、日本では古来から伝わる「確認画面で入力内容を再表示 させ、文字化けしてないことを人間に確認させる」という手法も 併用しておけばかなり安心できます。 困るのはGETのクエリパラメータとして与えれる文字列の エンコーディングで、これはリンク等の場合、リンク元の HTMLのエンコーディングに依存するため、同一ページへの アクセスでも（リンク元が異なれば）Shift_JISだったり UTF-8だったりすることがしばしばあります。まあ アプリ内では使用するHTMLのエンコーディングは把握・ 制御できるはずなので、それ以外（外部サイトからの リンクの場合とか）は推測 and/or 間違ったらごめん、かなあと。 > |3. 変換後、encodingのチェックをして、おかしいのは例外を投げる > |が理想的だと思います。 > |一緒にaccept-encodingみたいな列挙項目をpostしてもらうとか。 > > このアプローチはアプリ側での対応が必要なので望ましくありませ > んね。確実でしょうけど。 例外はいろいろ厳しいかも…。validationのオブジェクトに エラーの情報が入っててほしい（制御フローは通常のまま）が 理想的かもです。って、その辺りはフレームワークとの兼ね合い ですが。 高橋征義 (takahashimm@gmail.com)