開封確認メッセージが文字化けする。状況は下記のとおりです。

１、Thunderbirdで受信すると本文が文字化けするものがある。
　　件名は正常に表示する。

２、Thunderbirdの文字エンコーディングは送・受信メッセージとも
　　日本語(ISO-2022-JP）に設定してある。

３、送信者が１名のみなら送信者のエンコーディング問題として
　　片付けますが、複数の送信者からの開封確認メールが化ける。

４、そのメールはEdMax(Free),OUTLOOK,OutLookExpressで受信すると
　　件名、本文とも正常に表示される。

５、Thunderbirdの文字エンコーディングをShift-JISにすると本文が読める。
　　（ただし、件名が文字化けする。）

６、Microsoft Office Outlook 11、Microsoft Office Outlook 12使用者に
　　文字化けが多い。

＜使用環境＞
PC : FMV-7000NA4
OS : Windows XP Professional SP2（最新パッチ適用済）
Thunderbird : 2.0.0.16 (20080708)
Firefox : 3.0.1

送信側で件名と本文で違うエンコードを使っているのでしょうか？
文字化けするメッセージのソースで件名のエンコード（頭の =?iso-2022-jp?b?... といった部分）と本文のエンコード（Content-type の charset）はどうなっていますか？

_________________
[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

ほんのちょっと前に Thunderbirdで受信すると文字化けする というトピックがあり、
解決済みになっておりますが、そちらはご覧いただいてますでしょうか？

【 確認済み 】→ 確認済みで、その方法では解決しなかった旨をご明記ください。
【 未確認 】→ ご覧いただいて、一度同様の部分をご確認ください。

Caiさん　レスありがとうございます。


ソースリストを確認致しましたが、件名のエンコードはiso-2022-jpです。
本文のエンコードはマルチパートのMIMEフォーマットでcharsetはiso-2022-jpです。
以下ソース（抜粋）

From: "aaaaaaaaaa" <a@ab.cd.com>
To: '=?iso-2022-jp?B?GyRCMEtGIyEhNUhPQhsoQg==?=' <a@ab.cd.com>
Subject: =?iso-2022-jp?B?GyRCMytJdRsoQiA6IBskQjMrSXUzTkcnJE5KODt6Mj0kMUQ0OjobKEI=?=
Date: Thu, 18 Sep 2008 14:07:54 +0900
Message-ID: <000001c9194c$821b0eb0$86cd5b0a@aaaaaaaaaa>
MIME-Version: 1.0
-------------------------------------

Content-Type: multipart/report;
report-type=disposition-notification;
boundary="----=_NextPart_000_0001_01C91997.F202B6B0"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AckZS64LSMAu4JpCQ0iaxftGHHBTfAAACyR1
In-Reply-To: <48D1DD08.9090402@ab.cd.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C91997.F202B6B0
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0002_01C91997.F205C3F0"

------=_NextPart_001_0002_01C91997.F205C3F0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Sakibaさん　レスありがとうございます



すみません。そのスレを見てこのスレを挙げましたので、【 確認済み 】です。

Thunderbirdは規格に忠実に作っているのは充分承知していますが、忠実すぎて
日本語のようにエンコードが多い国ではこんな事が起きるのかなと思っています。
でもIncrediMailみたいなのゲテでも化けないんですよね。

こちらでも Thunderbird 2.0.0.16 と Outlook 11 の組み合わせで試してみました。
メッセージの表示形式をテキスト形式にしていると文字化けせず表示されますが、表示形式を HTML 形式（オリジナル、シンプルのどちらでも）にすると、かまかさんと同じく文字化けしました。

自分の手元のソースを見ていて気づいたのですが、以下の点についてもう一度ソースを確認していただけますか？
1. text/plain ではなく text/html パートの MIME での charset の指定
2. text/html パートの本文中の META タグでの charset の指定

おそらく 1. が iso-2022-jp、2. が shift_jis とちぐはぐになっていると思います。
このせいで、MIME の charset 指定を信じた Thunderbird で文字化けが発生したのだと思われます。

Outlook Express 6 ではこのような食い違いはないので、Outlook のバグでしょう。
暫定的な対処法としては、テキスト形式で表示するくらいしかなさそうです。

_________________
[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

Caiさん　検証ありがとうございます。



ご指摘のとおりtext/html パートの本文中の META タグでの charset は3Dshift_jisでした。
Outlook のバグの様ですね。
ただ、他のメーラが化けないので、Thunderbirdももう少し柔軟なエンコードを望むのは、
私だけでしょうか？

ちなみに正統ではありませんが、回避方法を見つけましたので、記入しておきます。
Thunderbirdのメッセージに添付されているファイル(Part 1.2など）を開くプログラムに
Word等を規定に割り当てると、なぜか本文も正常に表示が可能となります。
どうもありがとうございました。

追加情報です。
Caiさんは、「メッセージの表示形式をテキスト形式にしていると文字化けせず表示されますが、
表示形式を HTML 形式（オリジナル、シンプルのどちらでも）にすると、かまかさんと同じく
文字化けしました。」とお書きになっていますが、私の場合はテキスト形式でも文字化けして
いました。
私の書いた回避方法はテキスト形式のみに有効の様です。
現在も HTML 形式では文字化けしたままでした。

むむ、微妙に症状が違うみたいですね。根っこは同じですが。


Firefox でも拡張子ではなくレスポンスヘッダを優先していますし、この辺は愚直なまでに相手を信用する設計ですからね。
一長一短で、どちらがいいのかは難しいところです。

_________________
[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かということを考えてもらえば柔軟な対応が出来ると思うんですが、
RFCや昔からの慣例に だらしないMUAの動作とは違うということを強調しすぎていると、結局は目的である「通信」が出来ないということでユーザーが離れていくんでしょうね。
RFCをきっちり守るのは送信だけで良いと思うんです。受信はどんな形式でもデコードして読めるように。