[quote="kiyo4_k"][quote="あ"][quote="kiyo4_k"]ということは、やっぱりまだ騙されやすいんですか？[/quote]
嘘をつかれたら簡単にコロッと騙されるのは相変わらずです。[/quote]あらら、ぜひオプションを！[/quote]
オプション化は手間がかかるので、無条件に MIME ヘッダの charset パラメータを無視するように手元で改造してみました。これで必ず自動判別が動作します。
オレ専用仕様としては結構いいのかも。
標準化には逆行する動作なので、大元には取り込まれるはずがありませんが。

あと、[url=http://www.archive.org/]Internet Archive[/url] で嘘の charset が指定されていて日本語ページが文字化けしまくったような記憶があったので、HTTP ヘッダの charset パラメータを無条件に無視するような Firefox も作ってみましたが… 今見たらすでにサイトの方が直っている！？
動作確認はできませんでした。
最近は、どこのサイトも比較的ちゃんとしてるんですかね。

1分違いですが、完全にすれ違いで気付きませんでした。
[quote="あ"][quote="kiyo4_k"]ということは、やっぱりまだ騙されやすいんですか？[/quote]
嘘をつかれたら簡単にコロッと騙されるのは相変わらずです。[/quote]あらら、ぜひオプションを！

[quote="あ"][quote="kiyo4_k"]あぁ、これってFireGPGがどんなコードでも日本語で表示出来るようになる（今はもう そうなっているかもしれないけど）ってことでしょうか？　（ って、あさんFireGPGって知ってます？）[/quote]
知らないのでちょっとググってみたら、任意の Web ページ上で使える GPG ですか？
というだけの情報では、文字コードをどうやって扱っているのかちょっと謎です。[/quote]扱える訳がないです、ダメダメでした。
完全に日本語に対応したMUAから送信したPGP暗号は文字化けし、ISO-2022-JPに署名されたPGP署名は不正な署名になってしまいました。送信は試していません（前回ダメだったので）
MUAとブラウザのデコードのやり方をごっちゃにしても無理でしょ。

これについて興味のある人は雑談に話題があるので繋げていただいて結構です。

[quote="kiyo4_k"]あぁ、これってFireGPGがどんなコードでも日本語で表示出来るようになる（今はもう そうなっているかもしれないけど）ってことでしょうか？　（ って、あさんFireGPGって知ってます？）[/quote]久々に試してみましたが、3.0.9では まだFireGPGでの日本語は使えませんでした。3.5が出たら真っ先に試してみます。

[quote="kiyo4_k"]ということは、やっぱりまだ騙されやすいんですか？[/quote]
嘘をつかれたら簡単にコロッと騙されるのは相変わらずです。

[quote="kiyo4_k"]あぁ、これってFireGPGがどんなコードでも日本語で表示出来るようになる（今はもう そうなっているかもしれないけど）ってことでしょうか？　（ って、あさんFireGPGって知ってます？）[/quote]
知らないのでちょっとググってみたら、任意の Web ページ上で使える GPG ですか？
というだけの情報では、文字コードをどうやって扱っているのかちょっと謎です。

[quote="あ"]ヘッダ等でエンコード指定があれば、それを信用することになっているので自動判別は働きません。(このあたりは、MS 製アプリとは違うところです。)
自動判別が働くのはそのような指定がない場合です。[/quote]ということは、やっぱりまだ騙されやすいんですか？　ヘッダを信用せず＆エンコード指定を決め打ちせず で強制的に自動判別 というオプションが欲しいと思うのは贅沢でしょうか。（ブラウザには必要がないかも知れないけど）

[quote="あ"]可読性というか、普通の文書での文字の出現頻度というか、あらかじめ取られた統計データを利用しています。[/quote]文字単位の統計データですか。　．．．誰がそんなことを言い出したんだろうって感じですね。
統計データと突合させるというなら、ベイジアンフィルタのコーパスみたいに『こんにちは』とか単語単位で文字コード別に用意しておいて．．．なんてバカなことをちょっと考えてしまいました。

[quote="あ"]もともと全言語用の判定ロジックだということから、latin 系言語も対象に入っているということも、全体を調べる理由のひとつでしょうね。[/quote]これ、大昔に日本語限定で考えたこともありますが全言語対応というのは大変そうですね。私は出来たものだけ仕組みも知らずに使わせてもらうことになりますね。

あぁ、これってFireGPGがどんなコードでも日本語で表示出来るようになる（今はもう そうなっているかもしれないけど）ってことでしょうか？　（ って、あさんFireGPGって知ってます？）

＃ すみません、もう許容範囲外の脱線かも知れないですね

[quote="kiyo4_k"]その状態のテキストに対してエンコード指定が有れば正しいかどうかを判断または参考にしながらテキストの文字コードとして可読性の有るものかどうかの判断を入れて決定するということなのでしょうか。[/quote]
ヘッダ等でエンコード指定があれば、それを信用することになっているので自動判別は働きません。(このあたりは、MS 製アプリとは違うところです。)
自動判別が働くのはそのような指定がない場合です。

可読性というか、普通の文書での文字の出現頻度というか、あらかじめ取られた統計データを利用しています。
ということは、あらかじめ取られた統計データに反するもの、つまり普通は滅多に使わないような珍しい文字ばかりを並べると、誤判定をしやすくなります。

[quote="あ"]全体を調べるというのは非現実的なような気もしますが．．．　面白そうなので期待して待っていましょう。[/quote]
もともと全言語用の判定ロジックだということから、latin 系言語も対象に入っているということも、全体を調べる理由のひとつでしょうね。
latin 系言語の文書だと出現する文字の大部分が ASCII 文字で、先頭をバイト数で切り出してくると全部 ASCII 文字でまったく判別ができない、なんてことが多発しますから。
ASCII 文字は一部分だけ、という日本語の文書とは大きく違うところですね。

Gecko 1.8 系までの日本語専用の判定ロジックでは、決定できるところまで読んだら残りはバッサリ捨ててました。

[quote="あ"]Tb2 との比較で言うと、文字化けしなくなるものもあれば新たに文字化けするようになる物もあり、「少なくなる」かどうかについては母集団次第です。
Tb3Alpha1〜2 との比較で言えば、少なくなると言っていいと思います。
なお、これは 自動判別->日本語 の場合の話です。
自動判別->全言語 については、上記の修正は影響しません。[/quote]quated-printable などのデコード後のテキストデータに対して解析するわけですね。その状態のテキストに対してエンコード指定が有れば正しいかどうかを判断または参考にしながらテキストの文字コードとして可読性の有るものかどうかの判断を入れて決定するということなのでしょうか。
自動判別->全言語というのは現実的でもなさそうなことは理解出来ます。MUAと違ってブラウザの場合は処理も大変そうですね。

[quote="あ"]単純に言うと、全体を調べて、文字の並びがありがちなものなのか、こりゃねーよってものなのかを候補の全コードに対して点数をつけて、一番点数の高い物を選ぶような感じです。[/quote]全体を調べるというのは非現実的なような気もしますが．．．　面白そうなので期待して待っていましょう。

[quote="kiyo4_k"]なるほど。これの恩恵としてはquoted-printableで中味のコード指定がないものの文字化けが少なくなるという認識で合っていますか？[/quote]
まず、quated-printable かどうかには関係ありませんが、
Tb2 との比較で言うと、文字化けしなくなるものもあれば新たに文字化けするようになる物もあり、「少なくなる」かどうかについては母集団次第です。
Tb3Alpha1〜2 との比較で言えば、少なくなると言っていいと思います。
なお、これは 自動判別->日本語 の場合の話です。
自動判別->全言語 については、上記の修正は影響しません。

[quote="kiyo4_k"][quote="あ"]バイト数で切ったりはしていないはずで、速度に関しては相当遅い部類に入ると思います。
以前から全言語の判別に使われていて、Gecko 1.9.0 からは日本語でも使われるようになった判別方法の説明は [url=http://mxr.mozilla.org/mozilla-central/source/extensions/universalchardet/doc/UniversalCharsetDetection.doc?raw=1&ctype=application/msword]UniversalCharsetDetection.doc[/url] にあります。[/quote]コードの判定のために先頭をチェックするというのではなくて、全部文字単位でやってしまうってことですか。 :shock: [/quote]
単純に言うと、全体を調べて、文字の並びがありがちなものなのか、こりゃねーよってものなのかを候補の全コードに対して点数をつけて、一番点数の高い物を選ぶような感じです。

なるほど。これの恩恵としてはquoted-printableで中味のコード指定がないものの文字化けが少なくなるという認識で合っていますか？
[quote="あ"]自動判別で失敗するケースがあったら、サンプルとして欲しいのでどこかにアップしてもらえませんか^^;[/quote]スパムはすぐに自動で消えてしまうので今探してみてもquoted-printableしか無さそうです。たぶんsjisかな。

[quote="あ"]バイト数で切ったりはしていないはずで、速度に関しては相当遅い部類に入ると思います。
以前から全言語の判別に使われていて、Gecko 1.9.0 からは日本語でも使われるようになった判別方法の説明は [url=http://mxr.mozilla.org/mozilla-central/source/extensions/universalchardet/doc/UniversalCharsetDetection.doc?raw=1&ctype=application/msword]UniversalCharsetDetection.doc[/url] にあります。[/quote]コードの判定のために先頭をチェックするというのではなくて、全部文字単位でやってしまうってことですか。 :shock:

参照先のWordの文書はダメです、よくわかりません。まぁ読める人の役に立つかな。
ありがとうございます。

[quote="kiyo4_k"][quote="Cai"]Thunderbird 3 Beta 2 では当該部分は修正済みです。[/quote]なんですとぉ！　．．．じゃ、あんなMUAやこんなMUAやスパムとか文字化けクレームが減るわけですね。
＃ そういえばBeta 2では文字化けを見かけなかったような．．．[/quote]
Thunderbird で文字化けするのは、送信側が嘘の encoding を指定している(のを Thunderbird が信用してしまって、自動判別を使わない)場合とか、件名と本文とで違う encoding が使われている場合を Thunderbird がうまく扱えないバグ、とかが多いような気がします。
あるいは、自動判別 -> 日本語 に設定していて、フランス語のメールが文字化けするという当然の結果と言うか何と言うか。

少なくとも自分のところにくる日本語(ISO-2022-JP or Shift_JIS or EUC-JP or UTF-8)メールでは、自動判別 -> 日本語で自動判別に失敗して文字化けするケースは見た記憶がありません。
自動判別で失敗するケースがあったら、サンプルとして欲しいのでどこかにアップしてもらえませんか^^;

あと、「失敗する可能性を減らす修正」というのは、Gecko 1.9.0 (Fx3, Tb3Alpha1〜2 等)で失敗が多かったのに対する物です。
Gecko 1.8.1 (Fx2, Tb2) またはそれ以前と比較すると日本語の自動判別のロジックが全く別物になっているため、以前はうまくいっていたのが失敗するようになった場合もあれば、逆に以前は失敗していたのがうまく行くようになる場合もあって、どちらの率が多いのかは母集団次第になってしまって、一概には言えません。

[quote="kiyo4_k"][quote="Cai"]（ソースコードで確認）[/quote]うっ！　ソース．．．これ、最初の何バイトぐらいで判断しているか調べました？　速度と精度の閾値はどれぐらいなのか微妙ですが。[/quote]
バイト数で切ったりはしていないはずで、速度に関しては相当遅い部類に入ると思います。
以前から全言語の判別に使われていて、Gecko 1.9.0 からは日本語でも使われるようになった判別方法の説明は [url=http://mxr.mozilla.org/mozilla-central/source/extensions/universalchardet/doc/UniversalCharsetDetection.doc?raw=1&ctype=application/msword]UniversalCharsetDetection.doc[/url] にあります。

[quote="Cai"]Thunderbird 3 Beta 2 では当該部分は修正済みです。[/quote]なんですとぉ！　．．．じゃ、あんなMUAやこんなMUAやスパムとか文字化けクレームが減るわけですね。
＃ そういえばBeta 2では文字化けを見かけなかったような．．．

[quote="Cai"]（ソースコードで確認）[/quote]うっ！　ソース．．．これ、最初の何バイトぐらいで判断しているか調べました？　速度と精度の閾値はどれぐらいなのか微妙ですが。

＃あとはEnigmail

[quote="kiyo4_k"][quote="あ"]失敗する可能性を減らす修正は完了していて、Fx3.5 にはその修正が含まれますのでお待ちください。[/quote]失敗が当たり前だと思って見ていたんですけど．．．
その修正がThunderbirdにも加えられると喜ぶ人が多いかも知れませんね。[/quote]
http://hg.mozilla.org/mozilla-central/rev/f1bb0f862b5b
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f1bb0f862b5b
この修正は Firefox、Thunderbird 共通かつ trunk、branch 共通のもの (mozilla-central, mozilla1.9.1) です。
Thunderbird 3 Beta 2 では当該部分は修正済みです。
（ソースコードで確認）

[quote="あ"]Fx3.5 にはその修正が含まれますのでお待ちください。[/quote]
おお、それはなによりです。
ご返答ありがとうございます。

[quote="あ"]失敗する可能性を減らす修正は完了していて、Fx3.5 にはその修正が含まれますのでお待ちください。[/quote]失敗が当たり前だと思って見ていたんですけど．．．
その修正がThunderbirdにも加えられると喜ぶ人が多いかも知れませんね。

[quote="anon"]プレーンテキストをデスクトップからFxにドロップしたときに、
ある条件を満たすと化けてしまいます。[/quote]
ローカルのファイルでも Web 上の物でも、プレーンテキストでも HTML でも、同様の物を自動判別まかせにすれば同様に文字化けするはずです。
そもそも、文字コードを完璧に自動判別することは不可能です。

ただし、Fx2 までの 自動判別→日本語 はそれなりに日本語向きな判定方法になっていたのに対して、Fx3 では全言語用の判定ロジックをそのまま使ってしまっているため、日本語で失敗する可能性は増えてしまっています。
失敗する可能性を減らす修正は完了していて、Fx3.5 にはその修正が含まれますのでお待ちください。
参考: [url=http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=6137]bug 6137 – 日本語文字コードの自動判別が、Fx2 では正しくできるのに trunk では誤判別する場合がある[/url]