プレーンテキストをデスクトップからFxにドロップしたときに、
ある条件を満たすと化けてしまいます。

テキストファイルの
・文字コード：ANSIもしくはSJIS
・文字数：1～3、4
・マルチバイト文字(漢字やひらがななど)

メモ帳などに例えば、
「明日は」だと化けますが、
「明日は晴」「明日は晴れ」などは化けません
更に「明日は雨」だと化けます。

こういった特殊な状況下ですが、他の方でも確認できますか？

使用環境：
Win Vista HP ja　Firefox 3.0.8 ja-JP
Win Home ja Firefox 3.0.8 ja-JP

雑駁な追試ですが、やってみました。
【方法】デスクトップに、いくつかの条件でマルチバイト文字を記述した test.txt という名称のテキストファイルを作成し、それを Firefox に D&D で読み込ませる。
　環境＝Windows XP Pro SP3
　テキストエディタ＝EmEditor Free（ version 6.00.4）
　改行コードは CR + LF ／ UTF-8 は BOM なし
　○＝文字化けなし、Ｘ＝文字化けあり

（１）「明日は雨」の 4 文字を記述。
┌──────────┬──────┬─────┬─────┐
│　　　　　　　　　　│　Shift_JIS │　EUC-JP　│　UTF-8　│
├──────────┼──────┼─────┼─────┤
│　Firefox 2.0.0.20　│　　○　　　│　　○　　│　　Ｘ　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.0.9 RC　│　　Ｘ　　　│　　Ｘ　　│　　○　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.1b3　　 │　　○　　　│　　○　　│　　○　　│
└──────────┴──────┴─────┴─────┘

（２）「明日は晴れ」の 5 文字を記述。
┌──────────┬──────┬─────┬─────┐
│　　　　　　　　　　│　Shift_JIS │　EUC-JP　│　UTF-8　│
├──────────┼──────┼─────┼─────┤
│　Firefox 2.0.0.20　│　　○　　　│　　○　　│　　Ｘ　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.0.9 RC　│　　○　　　│　　Ｘ　　│　　○　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.1b3　　 │　　○　　　│　　○　　│　　○　　│
└──────────┴──────┴─────┴─────┘

（３）「今日は雨」の 4 文字を記述。
┌──────────┬──────┬─────┬─────┐
│　　　　　　　　　　│　Shift_JIS │　EUC-JP　│　UTF-8　│
├──────────┼──────┼─────┼─────┤
│　Firefox 2.0.0.20　│　　○　　　│　　Ｘ　　│　　Ｘ　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.0.9 RC　│　　○　　　│　　Ｘ　　│　　○　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.1b3　　 │　　○　　　│　　○　　│　　○　　│
└──────────┴──────┴─────┴─────┘

（４）「咲いたさいた桜がサイタ」の 11 文字を記述。
┌──────────┬──────┬─────┬─────┐
│　　　　　　　　　　│　Shift_JIS │　EUC-JP　│　UTF-8　│
├──────────┼──────┼─────┼─────┤
│　Firefox 2.0.0.20　│　　○　　　│　　Ｘ　　│　　Ｘ　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.0.9 RC　│　　○　　　│　　○　　│　　○　　│
├──────────┼──────┼─────┼─────┤
│　Firefox 3.1b3　　 │　　○　　　│　　○　　│　　○　　│
└──────────┴──────┴─────┴─────┘

文字コードの自動判別に失敗するケースがあるようですね。
文字化けした場合も、手動で文字コードを選んでやれば正しく表示するのですけど。
自動判別の失敗が、単に文字数に依存しているわけでもなさそうだし、じゃあどんな文字種だとそうなるのか、これだけのテストじゃわかんないですね。（ぼくは文字コードのこととか、とんとシロウトですし......。）
でも、Firefox 3.1 系はさすが最新バージョンだけのことはあると思いました。

これまで、ローカルにあるテキストファイルをブラウザで開くなんてことはほとんどやったことがないので、ちょっと興味深かったです。
（長くなってすみませんでした。）
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
Firefox 3.0.9 RC + 3.1b3 + others
Thunderbird 2.0.0.21 + 3.0b2 + others
on Windows XP Pro SP3

偶然的通行人様、ご丁寧に検証ありがとうございます。

このような、極端に短い文章が記述されたテキストファイルは皆無ですが、
何れにせよ当面問題はござませんが、改善されるとありがたいです。

もしよろしければ、どなたか報告お願いいたします。
v3.0.9でも当然同現象発生します。
よろしくお願いいたします。

ローカルのファイルでも Web 上の物でも、プレーンテキストでも HTML でも、同様の物を自動判別まかせにすれば同様に文字化けするはずです。
そもそも、文字コードを完璧に自動判別することは不可能です。

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

失敗が当たり前だと思って見ていたんですけど．．．
その修正がThunderbirdにも加えられると喜ぶ人が多いかも知れませんね。

おお、それはなによりです。
ご返答ありがとうございます。

http://hg.mozilla.org/mozilla-central/rev/f1bb0f862b5b
http://hg.mozilla.org/releases/mozilla- ... bb0f862b5b
この修正は Firefox、Thunderbird 共通かつ trunk、branch 共通のもの (mozilla-central, mozilla1.9.1) です。
Thunderbird 3 Beta 2 では当該部分は修正済みです。
（ソースコードで確認）

_________________
[Desktop] Windows 10 Pro 22H2 (64bit) / Intel Core i7-2600 / Nvidia GeForce GTX 1650 GDDR6 / 32 GB Memory
[Laptop] Windows 10 Pro 22H2 (64bit) / Intel Core i5-520M vPro / Intel HD Graphics / 8 GB Memory
[Android] Android 13.0 (arm64) / Xperia 5 III (XQ-BQ42)
常用環境: Firefox ベータ版、リリース版 (Win64 x86-64, Android), Thunderbird ベータ版、リリース版 (Win64 x86-64)
テスト環境: Firefox (ESR, Nightly, Win64 x86-64, Android)
Cai/1.0 (Homo sapiens; N; Homo sapiens chemist; male; rv:0.0.4.2+)
-- いつまでたっても nightly

なんですとぉ！　．．．じゃ、あんなMUAやこんなMUAやスパムとか文字化けクレームが減るわけですね。
＃ そういえばBeta 2では文字化けを見かけなかったような．．．

うっ！　ソース．．．これ、最初の何バイトぐらいで判断しているか調べました？　速度と精度の閾値はどれぐらいなのか微妙ですが。

＃あとはEnigmail

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) またはそれ以前と比較すると日本語の自動判別のロジックが全く別物になっているため、以前はうまくいっていたのが失敗するようになった場合もあれば、逆に以前は失敗していたのがうまく行くようになる場合もあって、どちらの率が多いのかは母集団次第になってしまって、一概には言えません。


バイト数で切ったりはしていないはずで、速度に関しては相当遅い部類に入ると思います。
以前から全言語の判別に使われていて、Gecko 1.9.0 からは日本語でも使われるようになった判別方法の説明は UniversalCharsetDetection.doc にあります。

なるほど。これの恩恵としてはquoted-printableで中味のコード指定がないものの文字化けが少なくなるという認識で合っていますか？
スパムはすぐに自動で消えてしまうので今探してみてもquoted-printableしか無さそうです。たぶんsjisかな。

コードの判定のために先頭をチェックするというのではなくて、全部文字単位でやってしまうってことですか。

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

まず、quated-printable かどうかには関係ありませんが、
Tb2 との比較で言うと、文字化けしなくなるものもあれば新たに文字化けするようになる物もあり、「少なくなる」かどうかについては母集団次第です。
Tb3Alpha1〜2 との比較で言えば、少なくなると言っていいと思います。
なお、これは 自動判別->日本語 の場合の話です。
自動判別->全言語 については、上記の修正は影響しません。


単純に言うと、全体を調べて、文字の並びがありがちなものなのか、こりゃねーよってものなのかを候補の全コードに対して点数をつけて、一番点数の高い物を選ぶような感じです。

quated-printable などのデコード後のテキストデータに対して解析するわけですね。その状態のテキストに対してエンコード指定が有れば正しいかどうかを判断または参考にしながらテキストの文字コードとして可読性の有るものかどうかの判断を入れて決定するということなのでしょうか。
自動判別->全言語というのは現実的でもなさそうなことは理解出来ます。MUAと違ってブラウザの場合は処理も大変そうですね。

全体を調べるというのは非現実的なような気もしますが．．．　面白そうなので期待して待っていましょう。

ヘッダ等でエンコード指定があれば、それを信用することになっているので自動判別は働きません。(このあたりは、MS 製アプリとは違うところです。)
自動判別が働くのはそのような指定がない場合です。

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


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

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

ということは、やっぱりまだ騙されやすいんですか？　ヘッダを信用せず＆エンコード指定を決め打ちせず で強制的に自動判別 というオプションが欲しいと思うのは贅沢でしょうか。（ブラウザには必要がないかも知れないけど）

文字単位の統計データですか。　．．．誰がそんなことを言い出したんだろうって感じですね。
統計データと突合させるというなら、ベイジアンフィルタのコーパスみたいに『こんにちは』とか単語単位で文字コード別に用意しておいて．．．なんてバカなことをちょっと考えてしまいました。

これ、大昔に日本語限定で考えたこともありますが全言語対応というのは大変そうですね。私は出来たものだけ仕組みも知らずに使わせてもらうことになりますね。

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

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

嘘をつかれたら簡単にコロッと騙されるのは相変わらずです。


知らないのでちょっとググってみたら、任意の Web ページ上で使える GPG ですか？
というだけの情報では、文字コードをどうやって扱っているのかちょっと謎です。