snnh-ymk さんが書きました:
具体的には、受信メールをリスト表示させる欄で、添付書類がついているものにアイコンが表示されなくなり、メール本文の下側にも添付書類欄がありません。
ですが、添付書類がついているメールは、そのメールを表示させて「転送」ボタンを押すと、
送信メールとして添付書類が表示され、そこから開くことができます。
(A) 普通、「メールの添付書類・メールの添付ファイル」と呼ぶものは、
multipart/mixed
text/html あるいは text/plain
あるいは multipart/relatedなりmultipart/alternativeである
「メールの本文」
一つまたは複数の、「添付」と呼ばれるパート
における、「一つまたは複数の添付と呼ばれるパート」を指します。
[注] multipart/mixedの形式そのものには「メール本文」というような概念は無くて、
各パートのContent-Disposition: inline or attachment を尊重しながら、順番通りに各パートを表示する、というだけですが、
先頭のパートを「メール本文」として返信などで引用する、というようなことが、広く、伝統的に行われていますから、
Thunderbirdにおいても「先頭のパートがメールの本文である」として処理がなされます。
従って、先頭のパートがtext/html(or text/plain)のデータとならないような場合には(例えば、application/pdf)、奇妙な現象になり得ますし、それに加えて、
multipartなのに一つのパートしかない、といったようなおかしなことがあると、不可思議な現象になり得ます。
(B) multipart/related
(B-1) multipart/relatedの下のパートは、text/htmlのパートと、そのHTMLで使う<img>用のデータのパートのみを含むことができて、
「メールの添付書類・メールの添付ファイル」と呼ぶものは、含むことはできません。
(B-2) しかし、このmultipart/relatedの下にPDFファイルなどを入れた不正な形式のメールを送ってくる、アホなプログラマーによるメール関連のアプリによって、
multipart/relatedの下に見えないファイルが作られてしまうことがあまりにも多発したために、
multipart/relatedの下の、使用されなかったパートを、あたかも「添付ファイル」のようにAttachhment Paneに表示して、完全に見えなくなるのを防ぎ、ファイルとして保存できる手段を提供しています。
(C) multipart/alternativeの下のパートは、意味内容は全く同じで形式だけが異なる複数バージョンのメールデータ、を含むためのもので、表示する時にはどれか一つのバージョンのみを使うのであり(text/htmlのパートかtext/plainのパートか)、本質的に「添付」というようなパートは存在することができません。
メールの構造は、
ヘッダー部分の複数の行
ヌル行
データ部分の複数の行
となっていて、
このメールが、Content-Type:text/htmlやContent-Type:text/plainのメールではなくて、Content-Type: multipart/xxx の場合には、
Content-Type: multipart/xxx; boundary="abcde" として、
各パートが、
--abcde
Content-Type: xxx/yyy と複数のヘッダー行
ヌル行
このパートの複数のデータ行
となっている行のブロックが複数個あって、
最後は
--abcde--
で終わる、
という構造になっています。
メールの表示は、そのメールのソースを使って表示されているわけで、この「メールの構造」がどうなっているかの説明なしに、あぁだこぅだ言っても、無意味です。
各パートのデータの行が、PDFとかImageだとかなり行数が多くて見にくいですし、tetx/htmlでもかなりの行になることが多いですから、
問題のメールを、PPPPP.emlに保存して、PPPPP.txtにリネームして、テキストエディターでPPPPP.txtを編集し、各パートの「このパートの複数のデータ行」を削除して、
メールの構造がどうなっているかを見るといいでしょう。
[追記]
snnh-ymk さんが書きました:
添付書類がついているメールは、そのメールを表示させて「転送」ボタンを押すと、
送信メールとして添付書類が表示され、そこから開くことができます。
メールを表示した段階では添付ファイルが表示されないにも関わらず、
転送で添付が表示され、しかもそれが「メールの本文として見える」というような現象になるのは、
以下のようなケースかな？
multipart/related
Content-Type: xxx/yyy (text/htmlでもtext/plainでもimageでもない)
multipart/relatedの最初のパートは「メールの本文(==text/plainかtext/htmlのパート)」を期待しているので、このxxx/yyyのパートは、multipart/relatedの下の使用されなかったパート、として処理されず、メールの表示の段階では「あたかも添付として表示する」が利かない。
この時に、xxx/yyyがtext/calenderのようなテキストタイプだと、「転送」では以下のような形でメールが作られ、「添付ファイル」が現われる。
multipart/mixed
Content-Type: text/plain
元のメールのメール本文のデータは無いから、
ヘッダーに関係するデータのみ
Content-Type: text/calender
インライン表示だと、text/calenderの中身(文字列)が表示されるから、
「ヘッダーに関係するデータのみ」に続くtext/calenderの部分は、あたかも「転送メールのメール本文」のように見える。
[追記おわり]
[quote="snnh-ymk"]具体的には、受信メールをリスト表示させる欄で、添付書類がついているものにアイコンが表示されなくなり、メール本文の下側にも添付書類欄がありません。
ですが、添付書類がついているメールは、そのメールを表示させて「転送」ボタンを押すと、
送信メールとして添付書類が表示され、そこから開くことができます。[/quote]
(A) 普通、「メールの添付書類・メールの添付ファイル」と呼ぶものは、
multipart/mixed
text/html あるいは text/plain
あるいは multipart/relatedなりmultipart/alternativeである
「メールの本文」
一つまたは複数の、「添付」と呼ばれるパート
における、「一つまたは複数の添付と呼ばれるパート」を指します。
[注] multipart/mixedの形式そのものには「メール本文」というような概念は無くて、
各パートのContent-Disposition: inline or attachment を尊重しながら、順番通りに各パートを表示する、というだけですが、
先頭のパートを「メール本文」として返信などで引用する、というようなことが、広く、伝統的に行われていますから、
Thunderbirdにおいても「先頭のパートがメールの本文である」として処理がなされます。
従って、先頭のパートがtext/html(or text/plain)のデータとならないような場合には(例えば、application/pdf)、奇妙な現象になり得ますし、それに加えて、
multipartなのに一つのパートしかない、といったようなおかしなことがあると、不可思議な現象になり得ます。
(B) multipart/related
(B-1) multipart/relatedの下のパートは、text/htmlのパートと、そのHTMLで使う<img>用のデータのパートのみを含むことができて、
「メールの添付書類・メールの添付ファイル」と呼ぶものは、含むことはできません。
(B-2) しかし、このmultipart/relatedの下にPDFファイルなどを入れた不正な形式のメールを送ってくる、アホなプログラマーによるメール関連のアプリによって、
multipart/relatedの下に見えないファイルが作られてしまうことがあまりにも多発したために、
multipart/relatedの下の、使用されなかったパートを、あたかも「添付ファイル」のようにAttachhment Paneに表示して、完全に見えなくなるのを防ぎ、ファイルとして保存できる手段を提供しています。
(C) multipart/alternativeの下のパートは、意味内容は全く同じで形式だけが異なる複数バージョンのメールデータ、を含むためのもので、表示する時にはどれか一つのバージョンのみを使うのであり(text/htmlのパートかtext/plainのパートか)、本質的に「添付」というようなパートは存在することができません。
メールの構造は、
ヘッダー部分の複数の行
ヌル行
データ部分の複数の行
となっていて、
このメールが、Content-Type:text/htmlやContent-Type:text/plainのメールではなくて、Content-Type: multipart/xxx の場合には、
Content-Type: multipart/xxx; boundary="abcde" として、
各パートが、
--abcde
Content-Type: xxx/yyy と複数のヘッダー行
ヌル行
このパートの複数のデータ行
となっている行のブロックが複数個あって、
最後は
--abcde--
で終わる、
という構造になっています。
メールの表示は、そのメールのソースを使って表示されているわけで、この「メールの構造」がどうなっているかの説明なしに、あぁだこぅだ言っても、無意味です。
各パートのデータの行が、PDFとかImageだとかなり行数が多くて見にくいですし、tetx/htmlでもかなりの行になることが多いですから、
問題のメールを、PPPPP.emlに保存して、PPPPP.txtにリネームして、テキストエディターでPPPPP.txtを編集し、各パートの「このパートの複数のデータ行」を削除して、
メールの構造がどうなっているかを見るといいでしょう。
[追記]
[quote="snnh-ymk"]添付書類がついているメールは、そのメールを表示させて「転送」ボタンを押すと、
送信メールとして添付書類が表示され、そこから開くことができます。[/quote]
メールを表示した段階では添付ファイルが表示されないにも関わらず、
転送で添付が表示され、しかもそれが「メールの本文として見える」というような現象になるのは、
以下のようなケースかな？
multipart/related
Content-Type: xxx/yyy (text/htmlでもtext/plainでもimageでもない)
multipart/relatedの最初のパートは「メールの本文(==text/plainかtext/htmlのパート)」を期待しているので、このxxx/yyyのパートは、multipart/relatedの下の使用されなかったパート、として処理されず、メールの表示の段階では「あたかも添付として表示する」が利かない。
この時に、xxx/yyyがtext/calenderのようなテキストタイプだと、「転送」では以下のような形でメールが作られ、「添付ファイル」が現われる。
multipart/mixed
Content-Type: text/plain
元のメールのメール本文のデータは無いから、
ヘッダーに関係するデータのみ
Content-Type: text/calender
インライン表示だと、text/calenderの中身(文字列)が表示されるから、
「ヘッダーに関係するデータのみ」に続くtext/calenderの部分は、あたかも「転送メールのメール本文」のように見える。
[追記おわり]
ログイン
ユーザー登録
FAQ
検索
