Ver 24.4.0（24.5.0）

Subject: =?ISO-2022-JP?B?/*省略*/?=[改行]
=?ISO-2022-JP?B?/*省略*/?=[半角スペース][半角スペースxN][改行]
=?ISO-2022-JP?B?/*省略*/?=[改行]

みたいになっていると、末尾に半角スペースが入ってる行（上記だと２行目）が
デコードされずに、

「デコードされた文字列=?ISO-2022-JP?B?/*省略*/デコードされた文字列」

と表示されてるようなんですが、これは仕様（厳格）なんでしょうか？


自分なりに色々と調べてみたんですが、全てデコードさせる方法が見つからず
書き込ませてもらいました。
自明の現象で対処方法があるのならお教えいただけると助かります。
よろしくおねがいします。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:28.0) Gecko/20100101 Firefox/28.0

　　
＊質問・投稿する前に、サポートサイトやヘルプ、このフォーラム内を検索・閲覧して
　該当項目、同類・類似事例がないか、確認してみましょう。
　また、広くインターネット上でも、同類・類似事例がないか、調べてみましょう。
＊質問・投稿する前に フォーラムの利用について をしっかり読んで、その内容を理解
　した上で、それに沿って投稿しましょう。
＊ご自分の利用環境と正確な OS の種類ぐらいは書き添えましょう。
＊質問した後やアドバイスをもらった後は、放置せずに、結果や経緯を必ず書くように
　しましょう。ここは、ユーザ同士で、各種情報・事例を、シェアする場です。　
　
　

当方でも再現します。
但し、スレッドペイン上で起きており、メッセージペイン上部のヘッダ表示箇所では、正常です。
[環境：OS:Windows 7 Professional SP1 + Thunderbird 24.5.0 日本語版]

現状では、Thunderbird の仕様（バグもあるのかも？）かと思われます。
RFC の規定のどこかに、なんらかの決まり事が明記されているのかも知れませんが、調べていま
せんので、自信なしで、不明です。
ごめんなさい。


同様のケースではありませんが、[TAB] が末尾に付加されている問題を扱ったバグがありました。
Bug 733810 – If last line of folded Subject: header is Tab char only line, following header is shown as subject text at thread pane

RFC 2047 のメタバグなんかもあるようです。
Bug 673092 – (RFC2047) [meta] Make Thunderbird RFC 2047 compliant


全て正常にデコードさせるには、ヘッダを編集して、修正する方法があります。
　＃一旦、デスクトップなどに保存して、編集後に元に戻す。
　＃アドオンを利用して、編集する方法もあります。


もし、提示されたようなメッセージを、常時受信されているのならば、差出人にレポートしてあ
げたほうがいいように感じます。
その理由は、どんなメールクライアントでも正常に表示できるとは限らないと思われるからです。
Subject ヘッダに、余計なコードを継ぎ足すようなふるまいは、修正してもらったほうがよろし
かと感じます。


【お願い＆大きなお世話】
投稿者名は、誰が見ても、まとまだと思えるものにしましょうよ。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:32.0) Gecko/20100101 Firefox/32.0

[半角スペース] と、ちゃんと書いているにも関わらず、二行目、三行目の先頭に[半角スペース]がない、ということは、
Subject: =?ISO-2022-JP?B?/*省略(一行目のデータ)*/?=[改行]
[半角スペースまたはHtab]=?ISO-2022-JP?B?/*省略(ニ行目のデータ)*/?=[半角スペース][半角スペースxN][改行]
[半角スペースまたはHtab]=?ISO-2022-JP?B?/*省略(三行目のデータ)*/?=[改行]
にはなっていなくて、
Subject: =?ISO-2022-JP?B?/*省略(一行目のデータ)*/?=[改行]
=?ISO-2022-JP?B?/*省略(ニ行目のデータ)*/?=[半角スペース][半角スペースxN][改行]
=?ISO-2022-JP?B?/*省略(三行目のデータ)*/?=[改行]
になっている、ということでしょうか？

それでしたら、Tbは、仕様どおりに、正しい解釈をしています。
この場合の「二行目」「三行目」は、Subject:行の継続行にはなり得ません。
「二行目」「三行目」、は、Subject:とは独立した、=で始まって?があって": "もない、不正な形式をした、単独のメッセージヘッダー、になります。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19

返事が遅れてしまいすみません。


すみません、二、三行目の先頭にはスペースがあります。本当は
>Subject: =?ISO-2022-JP?B?/*省略*/?=[改行]
> =?ISO-2022-JP?B?/*省略*/?=[半角スペース][半角スペースxN][改行]
> =?ISO-2022-JP?B?/*省略*/?=[改行]
と、書いたつもり（WADAさんが提示した先頭に[半角スペースまたはHtab]がある方）でした。
末尾のスペースは強調しないと解りづらいと思ってやったんですが、
行先頭のスペースは自動でHTMLエンティティ化してくれるもんだと
勝手に思い込んでました。実際は削除されてたようで・・・誤解を
与えるような書き込みになってたのに気付かずにいてすみません。


さらに調べてみたところ、正確には
Subjectが三行以上で、二行目末尾に半角スペースが二文字以上あると
その二行目はデコードされない（二行目限定で起きる）ようです。
上記条件に当てはまっていても一行目末尾と二行目先頭に半角スペースを
数文字追加してやると正常にデコードされたりと、これ以上は
デバッガでトレースした方がよさそうな雰囲気だったので調べるのを
やめましたが、かなり（RFCを読んでないので断言できませんが）バグ臭い
変な挙動です。

受信したメールだけでなくテキストエディタで上記Subjectに加工した
emlファイルを取り込んでも再現されます。

再現しました。

「あいうえおかきくけこさしすせそアイウエオカキクケコサシスセソ１２３４５６７８９ＡＢＣＤＥＦＧ」というSubject:のメールを作り、
サブジェクトの行を２倍して、２倍の長さのサブジェクトを作り、２つ目の「Subject:」を[SP]にして継続行に変え、
最初と最後の行以外の行末を、[改行] ⇒ [SP][SP][改行] に変える、という操作をしてみました。

Subject:ヘッダーをデコードしてMsgDBHdrに保持するデータは、以下のようになっていました。
デコード前のsubject。
デコードした後のsubject。ヘッダーペインの表示、フィルターなどに使われる。

デコード前に既に、二行目で、エンコードされた文字列のままだが、後ろの「?=」を除去、が見られます。
ヘッダーの処理では、「Subject: =?ISO-2022-JP?B?...?= =?utf-8?B?...?= =?windows-1252?Q?...?= =?koir-8?B?...?=」といった、
エンコードのcharsetが異なるものやエンコードの方式が異なるものに対する処理を容易にするために、
より広い範囲の一つのcharset、QPではなくBase64、に統一しようとします。
[SP][SP][改行] を [SP]X[改行] (Xはアルファベット)にすると問題は起こらないですし、一行目でも三行目以降でも問題が起こらないようですから、
二つ目のアトムの時に、その統一しようとする処理で、スペースがあると、行末に向かって非スペース文字を探して、見つからないのでエラーになる、というようなことかもしれません。
なんらかのQuirksによる行末のスペースの除去とかの影響で、二行目(二つ目のアトム)の処理においてはエラーが起こる、ということかもしれません。

色々とありがとうございます。
前段部分での下処理に結構面倒な事をやってたんですね・・・
もっと安直に考えてました。

とりあえず、ここ数日メールチェック出来てない状態（この件もあって）で、
これ以上時間を割けないので問題無い旧版探してダウングレードで急場を
凌げないか試してみたいと思います。

一応お知らせして置きます。
Thunderbird 10esrでも確認してみたのですが、問題が出ます。

先頭15文字くらいは正しくデコードされますし、壊れるパターンは明確ですし(その後ろが =?ISO-2022-JP?B?GyRCJS...のまま)、ヘッダーペインでは正しく表示されますし、「転送」ならば、実際のSubject:ヘッダーから持ってこられるので、正しいサブジェクトを作ります。
「返信」では化けた状態になりますが、「転送」で作られるサブジェクトをコピー＆ペーストすれば、容易に逃げられます。
問題が起こっても、空のメールフォルダ「FolderX」にメールを移動し、FolderXというファイル(FolderX.msfではない方)をテキストエディターで編集して、行末のスペースを除去し、「FolderX」において「フォルダーの修復」をすれば、正しくデコードされます。

このバグのために「旧版にダウングレードで急場を凌ぐ」というのは、避けておいた方がいいでしょう。

こちらも再現しました。
だと、デコード前に、既に、"?="の消失が起こります。

しかし、以下では、問題が起こりません。

Subject:[SP]abc[改行][SP]pqr[SP]=?UTF-8?B?5pel5pys6Kqe?=[SP][SP][改行]
だと、「abc pqr =?UTF-8?B?...」と、継続行を示す空白を挟んで継続して処理しているが、
Subject:[SP]abc[SP][改行][SP]pqr[SP]=?UTF-8?B?5pel5pys6Kqe?=[SP][SP][改行]
だと、abc[SP][改行][SP]で、一度処理が閉じられ、pqr[SP]=?UTF-8?B?...から処理を始めるのでＯＫ、
Subject:[SP]abc[改行][SP][SP]pqr[SP]=?UTF-8?B?5pel5pys6Kqe?=[SP][SP][改行]
だと、abc[改行][SP][SP]で、一度処理が閉じられ、pqr[SP]=?UTF-8?B?...から処理を始めるのでＯＫ、
というようなことなんでしょう。
RFC2042エンコードされた”encoded-word"の後ろにスペースがちょっとあるだけで破綻するロジックって、どうなってるんでしょうかね。

ま、このあたりは、不正なヘッダーの時でもなんとか表示するように、行末のスペースの除去とか、継続用のスペースの除去とか、Subject:内のHtabの除去とか、base64エンコードデータの後ろに"="が一個余計に入っていた時に除去とか、各種のQuirks、一種の「余計なこと」、が、たくさん入っているところだから、完璧に全てのRFCに準拠しているとは言い切れないヘッダーの時に、多少の不具合があっても仕方が無い部分。
どうせ、メールのRFCには無頓着なWebアプリのプログラマーによって書かれたコードが作り出したヘッダーでしょうから、送り先に連絡して直してもらい、直るまでは、スクリプトでメッセージのソースの余計なスペースを除去、というのが、妥当でしょう。

最近入り込んだ不具合かと思ってましたが違うんですね・・・
そこまでさかのぼっても駄目とは・・・orz
わざわざすみませんでした。助かります。

問題のメールはメルマガの類なのでそれほど重要でもないし、
色々調べて疲れたのもあり、もうこのまま放置でもいいかなと
思うようになってきました（苦笑）。



実際の所どういった理由かは解らないので想像でしかないですが、受け取った
メールはRFCに則って（考慮して）72とか80文字で区切るようにしてあるが、
なぜか固定長になってて一行72とか80文字未満ならスペースで埋めるという
余計な事もしており、それが仇になった雰囲気。
逆に字数制限無視（998文字以内ならという判断？）して複数行に分けない
無頓着というか横着な方が正常に読めてるという、ヘタな親切が
悲しい結末をまねいてるような、そんな風に見えました（苦笑）。