MozillaZine.jp フォーラム

希望を繰り返しますと、次の感じになります。

Thunderbirdの改良の方向として、どのようなメールでも柔軟に、文字化けを起こすことなく表示するという方が、スマートなように思います。

これについては、今年の１月に、既に他者において問題点の指摘があるようですが、今後も当面は、ご対応いただけないという結論でしょうか？
それとも、このフォーラム以外で他にお願いすべき適切なところがあるのでしょうか？

オオカミ中年 さんが書きました:希望を繰り返しますと、次の感じになります。

Thunderbirdの改良の方向として、どのようなメールでも柔軟に、文字化けを起こすことなく表示するという方が、スマートなように思います。

これについては、今年の１月に、既に他者において問題点の指摘があるようですが、今後も当面は、ご対応いただけないという結論でしょうか？
それとも、このフォーラム以外で他にお願いすべき適切なところがあるのでしょうか？

このフォーラムはMozillaZine.jpフォーラムと言いまして、MozillaやMozilla Japanとは別の「コミュニティ」なんです。
なので、ここでソフトウェアに関するバグの報告や機能追加などの希望を書いても開発者には届きませんし、そのような要望に対する結論などは出しません。
たまたま関係者（日本にも開発に携わっている人が居るので）が見ていて、重要なバグの話題や世界的に要望されるような機能追加の話題が有れば巻き取られることが有るかもしれません。しかし、おそらくそういうことはほとんどないでしょう。

しかし、ユーザが要望を出したりバグの報告をする場所は有ります。
https://bugzilla.mozilla.org/
基本的にバグの報告がメインだと思いますが、「本文と件名（ヘッダ部）が異なる文字コードの場合に文字化けが発生するバグ」として押し切る英語力と説得力が必要だと思います。
つまり、MIME/RFCの規約を無視したMUAからのメッセージを正常に表示できないのはバグである、ということを。

私の場合は英語力も説得材料も説得するべき理由もないので無理です。
というのは、MIME規約違反のMUAの尻拭いをすること自体がMIME規約やRFC規約そのものを陳腐化させてしまう危険が有るからです。
また、この問題が極東の島国の一部だけで使用されている陳腐なMUA（またはWebサービス）から送信されるメッセージでだけ発生するトラブルのためにThunderbirdが対応しなければならない理由が必要だと思います。
どんな風に書いたら納得してもらえるのかが想像できません。

あるいは、オープンソースの利点を生かして自分でソースを修正して送りつけるとか、自分でソースを修正してコンパイルして自分で使うとかという手も有るらしいです。

私からは以上です。

kiyo4_k さんが書きました:いいえ、件名と本文が異なる文字コードというのはダメだという話しです。

かずさんの文章を読み違えているようですね。
「文字コードには charset パラメータと同じ値を用います。」
というのは、そのメールの本文の charset パラメータと同じ値を指定しろというわけではなくて、
charset パラメータに使用できるものと同じものを指定しろという意味です。

マルチパートの場合、そもそもどの charset に合わせるべきなのかと。

ほほほ さんが書きました:マルチパートの場合、そもそもどの charset に合わせるべきなのかと。

あっ、すみません。
途中にも他のとごっちゃになって変なことを書いていますね．．．

この件は本文部がiso-2022-jp指定なのに中味がsjisなので文字化け、
Thunderbirdでエンコードを指定するとSubjectにも影響して文字化けということですが。
仰る通り、Subject等ヘッダは本文部の指定とは別（独立）ですね。

Thunderbirdのバグとするなら、「Thunderbird側でエンコード指定を行ってもSubject等ヘッダには影響を与えないで！」というところでしょうか。
でも、全体のエンコードを指定するという意味（わざわざ書いてないですが）ならバグとも言えません。
バグと言うより機能を拡張してSubject等ヘッダ毎に指定の変更を行うかどうかをチェックマークで選択できると便利かもしれません。

----
受信側はSubjectと本文が異なるエンコードでもそれぞれ正しくデコードして欲しいです。
Thunderbirdにはエンコード指定を変えてもSubjectは関係なくMIME指定通りに表示して欲しいです。
また、送信側はマルチパートでもないのに異なるエンコードをSubjectに指定しないようにして欲しいです。