Outlook Express 6で受信すると件名が「インシデント 47 手動通知」と正しく表示されるメールをThnderbird3.1.7で受信させると、「インシデント 47 手動通�」と表示されます。

メールヘッダーを確認すると、下記のようにSubjectは記述されています。

Subject: =?UTF-8?B?44Kk44Oz44K344OH44Oz44OIIDQ3IOaJi+WLlemAmuef?=
=?UTF-8?B?pQ==?=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

下記のような件名をセットしてTBで受信してみましたが、これらは問題なく表示されました。

「インシデント 47手動通知」
「インシデント47手動通知」
「インシデント4手動通知」
「インシデント手動通知」

インシデントと手動通知の間に4つの半角スペースを入れると再現して「インシデント 手動通�」と表示されました。
「インシデント 手動通知」

この挙動はメールを投げているアプリ側の問題なのでしょうか。
Tb側の問題になりますでしょうか。

最後に2文字足らないと思います。
正しくBエンコードすると、「=?UTF-8?B?pQ==?=」ではなく「=?UTF-8?B?pQ0K?=」となるはず。


なぜ Outlook Express 6 で「知」と表示できるのかわかりませんが、送信側のエンコード処理の問題だと思います。

※質問するときは、フォーラムの利用について [投稿する前にお読みください] に目を通し、OS の種類や Thunderbird のバージョンといった使用環境についての最低限の情報を書き添えるか、投稿用テンプレート の利用をお勧めします。

え～っと、とくに詳しく知っているわけではないのですが......。

当方の Thunderbird 3.1.7 + WindowsXP SP3 で簡単に送受信を試してみました。
件名を
「インシデント 47 手動通知」（「～[space]47[spase]～」）とした場合も、
「インシデント 手動通知」（～[space]x4 ～）とした場合も、
うちではご質問のような問題は再現しませんでした。

「インシデント 47 手動通知」の場合、Thunderbird で送受信した Subject フィールドは次のようになっていました。

UTF-8 の文字コードで全体をひっくるめて B エンコーディングされ、途中の改行はありません。
「インシデント 47 手動通知」程度の文字数の場合、RFC 的には複数行に分割する必要はとくになかったと記憶しています。

一方、問題が起こっているメッセージの Subject では、

のようになっていますが、これはクセものだと思います。
全体をひっくるめて B エンコーディングしているのは Thunderbird と同様ですが、途中に変則的な改行があります。
たしか RFC 的には、複数行に分割するときのルールがあったはずなんですが、このエンコードの結果はそれから外れているように思います。最後の一文字である「知」をエンコードした際の文字列の途中で強制的に改行されているようですし、改行規則もなんか変というか...。

で、この Subject を、正常に表示されているメッセージのソースに上書きして Thunderbird に表示させてみたところ、ご質問のような「インシデント 47 手動通」となり「知」がデコードされませんでした。

試しに、同様の手順で手持ちのメールクライアントに書き込んで試してみました。
　・ Sylpheed 3.1.0 (Build 1114)
　・ QMAIL 3.0.9.0442
ともに、スレッドペインでは「インシデント 47 手動通知」と表示されましたが、メッセージペインのヘッダフィールドでは最後の一文字が欠落した「インシデント 47 手動通」の表示になりました。
　（このへんの挙動の差は調べてないのでよくわかりません。）

比較として、Sylpheed から UTF-8 で送信した件名「インシデント 47 手動通知」のメッセージの Subject フィールドは次のようになっていて、これだと Thunderbird でも正常に「インシデント 47 手動通知」とデコードできました。

非 ASCII 文字のみ B エンコーディングされ、途中に改行があります。ただし改行規則は正常のようで、「=?UTF-8?B?55+l?=」をデコードすれば「知」になります。
　　｜ どこかで 非 ASCII 文字のみエンコードするといった話を聞いた覚えがあるので、
　　｜ こういう形式が望ましいのかもしれませんが、記憶なので自信はないです（苦笑）。

一方、「=?UTF-8?B?pQ==?=」をデコードしても「知」にはなりません。「知」の途中で改行されて一部分しかデータがないからで、「知」をエンコードしたデータの一部は「インシデント 47 手動通」の末尾にくっついているので、それが文字化けのように見えるのだと思います。


ぼくもまったく同感です。
結果から推測すると、Outlook Express 6 ではエンコードされた複数行を合体させてからデコードしているのに対し、Thunderbird などではデコードした結果を合体させているのではないでしょうか？
実際のところ、こういうエンコーディングで投げてきたのは何というメールクライアント / メールシステムなのか、ちょっと興味があります。

記憶に頼った曖昧な話で申し訳ありませんが、いちおう検証報告を兼ねて...。
（このあたりの規格や文字コードの扱いに詳しい方からのフォローを期待したいところです。）

緑の狸さん、アドバイスありがとうございます。Tbで「=?UTF-8?B?pQ0K?=」としてみましたが、Tb上での件名が「インシデント 47 手動通 =?UTF-8?B?pQ0K==?=」と表示されてしまいました。

下記のサイトを見つけて、Subjectにセットされた値をデコードしてみたら、双方とも正しく「インシデント 47 手動通知」と表示されました。

http://user1.matsumoto.ne.jp/~goma/js/base64.html

元の内容は下記ですが、



改行を外して下記の値をデコードしてみました。


またアドバイスを頂きました「0K」を追加してみました。


結果、双方とも「インシデント 47 手動通知」とデコードされました。
混乱中です　・・・　

偶然的通行人さん、お時間をとって検証してくださって、どうもありがとうございます。

この問題は、あるミドルウェアの通知機能なのですが、立場上明らかにできない背景がございまして、ご理解頂けたらと思います。:o

改行は76バイト目でされる仕様と耳にしているのですが、それより短くても良いみたいです。ただ、76バイト以内で改行させるには、それ相応の理由があるのだと思ってます。たとえば、ダブルバイトのデータの途中で改行が入ってしまうのを避けるためなど。



なんか、そんな感じですね。「知」をBASE64で変換すると「55+l」であることを未確認でしたが、僕の方でも確認できました。改行時のハンドリングに根本原因があるかどうか、確認してみたいと思います。

日本語の文字コードがQエンコードによる処理で泣き別れにならないように操作してから76バイト以下で改行が必要です。
ミドルウェアの通知機能のエンコード処理を修正する必要があると思います。Outlook Expressが表示できるのは日本語を含むQエンコードの処理を送信も受信も正しく行っていないからです。（偶然的通行人さん指摘の通り）
SylpheedとQMAIL3は正しくやっているからでしょう。受信はOutlook Expressのバグにも対応させているかもしれません。

＃確認したのは５年も前なんですけど．．．
Outlook Expressは直ってないみたいですが、大抵はOutlook Expressで送信する人の相手はOutlook Expressで受信するので大ごとにならないんでしょうかね。

間違い

QエンコードではなくてBエンコードですね。

失礼しました。改行コード（CR+LF）まで含めていました。
元は「インシデント 47 手動通知」＋「CR」をエンコードしているようですね。

偶然的通行人さんが書かれているように、マルチバイト文字の途中で分割してしまっているようです。

e3 82 a4 e3 83 b3 e3 82 b7 e3 83 87 e3 83 b3
e3 83 88 20 34 37 20 e6 89 8b e5 8b 95 e9 80
9a e7 9f a5 0d
↓
44Kk 44Oz 44K3 44OH 44Oz
44OI IDQ3 IOaJ i+WL lemA
muef pQ==

Kiyo4_kさん、緑の狸さん、どうもありがとうございます。
ミドルウェア側の改行処理が不適切ということで、それの修正ということで進めてみます。
どうもありがとうございました。助かりました　:D