高橋征義です。

2010年4月30日11:32 Yukihiro Matsumoto <matz / ruby-lang.org>:
> |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)