[#40961] [Bug #3137] complex.rb changes exceptions of Math — Yusuke Endoh <redmine@...>

Bug #3137: complex.rb changes exceptions of Math

15 messages 2010/04/12
[#40967] Re: [Bug #3137] complex.rb changes exceptions of Math — keiju@... (石塚圭樹) 2010/04/13

けいじゅ@いしつかです.

[#41038] Windows と DL が使用条件の libffi — Aaron Patterson <aaron.patterson@...>

こんにちは!アーロンです。

17 messages 2010/04/22
[#41039] Re: Windows と DL が使用条件の libffi — "U.Nakamura" <usa@...> 2010/04/22

こんにちは、なかむら(う)です。

[#41040] Re: Windows と DL が使用条件の libffi — "NARUSE, Yui" <naruse@...> 2010/04/22

成瀬です。

[#41059] Re: Windows と DL が使用条件の libffi — Aaron Patterson <aaron.patterson@...> 2010/04/26

2010/4/21 NARUSE, Yui <naruse@airemix.jp>:

[#41060] Re: Windows と DL が使用条件の libffi — Yugui <yugui@...> 2010/04/26

2010/4/26 Aaron Patterson <aaron.patterson@gmail.com>:

[#41067] [Feature #3203] LazySweepGC patch — Narihiro Nakamura <redmine@...>

Feature #3203: LazySweepGC patch

15 messages 2010/04/26
[#41069] Re: [Feature #3203] LazySweepGC patch — Yusuke ENDOH <mame@...> 2010/04/27

遠藤です。

[#41104] Rails3 M17N — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

29 messages 2010/04/30
[#41111] Re: Rails3 M17N — Urabe Shyouhei <shyouhei@...> 2010/04/30

Yukihiro Matsumoto =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=

[#41113] Re: Rails3 M17N — Yukihiro Matsumoto <matz@...> 2010/04/30

まつもと ゆきひろです

[ruby-dev:41109] Re: Rails3 M17N

From: masayoshi takahashi <maki@...>
Date: 2010-04-30 04:23:59 UTC
List: ruby-dev #41109
高橋征義です。

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)

In This Thread