http://forums.mozillazine.jp/viewtopic.php?p=43819#43819の続きです。
Thunderbirdの話も含んでいるので、Thunderbirdフォーラムに書きます。


その解釈は間違いだと思います。
"=?文字コード?…"の文字コードの部分に指定する値はContent-Typeヘッダーのcharsetパラメーターに書ける値と同じ値を使用できるという意味だと思います。


先の例は、山本さんが実装したMewで作成したものです。本文の文字コードは、あえてShift_JISに変更しましたが。
Shift_JISの例ではありませんが、例えば丸付き数字などを使えばあえて文字コードを変更せずデフォルトで異なる文字コードになります。


これは、「間違いだらけのメールリーダ - ああ文字コード - charset の決めうち」に書いてある通りの動作（正しい方）だと思います。
これが間違った実装だとおっしゃるなら、ぜひ山本さんにバグ報告していただきたいです。
（ちなみに、Thunderbirdでは作成は以下の通りバグっていますが、表示はできました。）

この例と同じ件名・本文をThunderbirdで書くと、間違ったデータを作成します。


丸付き数字はISO-2022-JPでは表せないのに、本文のcharsetをISO-2022-JPとしています。
これをMew version 6.3 on Emacs 23.2で表示すると、文字化け（丸付き数字の部分に何も表示されない）します。

電子メールの標準規格の理解として、件名と本文の文字コードをどう扱うのが正しいかを判断する能力は、ぼくにはありません。
そのことを前提に、MAD さんが例示された丸付き数字のサンプルについて少し気になる点があったので、そこだけオフトピ気味ですがコメントさせていただきます（議論ではなく感想的に...）。
（自明のこととして意図的に省略されていたのなら、余計なリプライでごめんなさい。）

ご例示の条件はつぎのとおりですよね。
　件名　(1)件名テスト
　本文　①件名テスト
トピックの本題として動作比較のポイントとなるのは「丸付き数字」のみです。

丸付き数字のように、いわゆる「環境依存文字」と呼ばれた文字には、それが JIS X 0213 や Unicode に規格内文字として取り込まれ、さらに実践的に普及していく上での歴史的経緯があります。

経験的にいえば、JIS 規格内の自由領域に配された外字の一つとしての丸付き数字ではあっても、JIS 規格内のコード領域が同一に扱われる環境間でのメールの送受信であれば、ISO-2022-JP で符号化されていても文字化けをせずに表示できていました。
文字規格が改良・進化し、コンピュータシステムも進化していくなかで、文字規格の実装に差があるシステムが混在している状況が生まれてくると、事態は少々ややこしくなっていきました。

最近はそうでもないんですが、Windows 9x 系などの古いシステム環境がそれなりに現場に残っていたころは、先進的なシステムがたった一文字の丸付き数字のために UTF-8 で送ってくるメールが、本文丸ごと文字化けするケースがけっこうあったのを思い出します。
本質的には、そのシステム（およびアプリ）が Unicode に対応しているかどうかの問題だと思いますが、実際上はそのようなことが起こっていました。

相手の環境によっては解釈できない可能性のある外字をメッセージとして送り出すこと自体に問題はありますが、少なくとも Windows to Windows などの同一環境間（*）では、日本語メールに丸付き数字などが含まれていても ISO-2022-JP のほうが文字化けの実害が少なかったです。
別環境であっても、本文全体が文字化けするよりは環境依存文字だけは化けてもいいから ISO-2022-JP で送ってくれたほうが全体的な被害が少ない――といわれることがあったのも記憶しています。
（*）同系 OS でもバージョンによって文字規格の実装に差がありましたから、文字化けを起こすケースもありましたけど。

現在、丸付き数字は JIS X 0213 や Unicode で定義されていますし、これらの文字規格を取り入れたシステムが増えていますから、本文が Content-Type: text/plain; charset=UTF-8 で指定されていても文字化けを起こす環境ははるかに少なくなっていると思います。
しかし、いわゆる「環境依存文字」だった丸付き数字には上述ような歴史的経緯があり、各メールクライアントも（実用面で後方互換的に）処理を工面していたことが、いまも尾を引いている側面はあるんじゃないでしょうか？

ちなみに、上記の事例を手持ちの Outlook Express 6.0 や Sylpheed 3.1.2 で試しても、Thunderbird と同じように件名・本文とも ISO-2022-JP でエンコーディングされたソースが生成されました。
そして、このソースのテキストメールを受信した Thunderbird 、Outlook Express 、Sylpheed のどれも、文字化けを起こさず表示できました（Windows XP SP3 の環境）。

以上のようなことから、丸付き数字だけを含む事例ひとつでは、件名と本文の文字コードが異なってもいいことの正当性と文字化けの関係を示す例としては、いささか無理があるんじゃないかと感じました。
どうせなら、つくりが漢数字の「七」になっている「叱」の異体字（

丸付き数字の場合は、バグとわかっていてあえてそうしている可能性は高いとは思います。（バグはバグですが。）
では括弧付き数字ではどうでしょうか。



ちょうど、それぞれ主張の通りのエンコードになりました。
Mewは、件名と本文でそれぞれ適切な文字コードを選択しています（「間違いだらけの…」に書いてある通り）が、
Thunderbirdは、件名と本文に同じ文字コードを選択しています。
Thunderbirdは、文字コード的には問題ありませんが、MIMEの「最小の適切な文字コードを charset に指定するという規則」には反しています。

リプライのついたあとに申し訳ありません。
前便の最後の部分が欠落していました。（プレビューでは問題なかったのですが...。）

尻切れなのがうっとうしいので、切れてしまった部分の前段を含めて欠落部分を載せておきます。

========================================================
どうせなら、つくりが漢数字の「七」になっている「叱」の異体字（*実コード*）など、純然たる Unicode 文字を件名や本文に含む場合の挙動を例示していただくほうが、日本語固有の特殊な歴史的背景を持つ「環境依存文字」がらみのあいまいさがない分、ご趣旨をより明確に示せるのではないかと思いました。

以上、余談の要素が多くて申し訳ないですが、「環境依存文字」にはいろいろ苦い思い出があるので......。
話をかき回してしまったなら、すみません。
========================================================

以上、失礼いたしました。

そうでした、確かに解釈が間違っていました。
と言うか、そもそもヘッダ部とパートについてのcharsetがごちゃ混ぜでした。ごめんなさい。
MADさんが書かれたことを踏まえて改めてrfc2047を読みましたがMADさんが書かれている通りです。（これはrfc2047を全部読まなくても8.の例だけ見ても解ります）

Subject:やTo:などに閉じて正しくエンコードしているメールを表示できないのはThunderbirdのバグですね。
もしかしたら送信時にiso-2022-jpで表現できない文字（マル数字とか）が使用されたときに自動的にutf-8でエンコードしないのもバグなんでしょう。
こういうヘッダの処理にバグが有って、おそらくThunderbirdでの添付ファイルに関する問題もrfc2047が正しく実装されていないことが原因ではないかと思います。


MewはすばらしいMUAです。昔、いくつかの問題にぶつかったときも「Mewは出来ます」「正しく処理を行うのはMewだけ」と豪語してました。だいたいみんなMewを基準にしていたのではないでしょうか。
忙しくて開発止まってるのかと思ってましたが最近もバージョンアップしていますね。