私は parsec と呼ばれる Haskell 解析ライブラリを学習しています。この目的のために、電子メール メッセージを解析する必要があります。仕様を調べたり、さまざまなクライアントからのさまざまなメッセージを比較したり、rfc を読んだりしています。
この演習で必要なのは、"From:" ヘッダーと実際のプレーン テキスト本文を抽出することだけです。現在、すべてのクライアントは、仕様に関して正気の、または少なくとも逸脱していないメッセージを生成しているようです。唯一の違いは見通しです（なぜか驚きません）。
したがって、標準的な方法は、myu の読みによると、境界シーケンスに次のように言わせることです。
Content-Type: multipart/alternative; boundary=047d7b2e4e3cdc627304eb094bfe
マルチパートボディのすべての部分は、この境界シーケンスによって区切られていますよね? 私が間違っている場合は、私を修正してください。パーサーがすべての可能なクライアントで動作することを望みます。
なのでよくあるパターンは
--boundary
headers
part
--boundary
headers
part
...
ここで、Outlook によって生成されたメッセージを見ると、別の図が表示されます。ある種のサブ境界を使用していますが、それが標準かどうかわかりませんか? これは見通しの変種です
Content-Type: multipart/related;
type="multipart/alternative";
boundary="----_=_NextPart_001_01CEE199.851D3871"
すると、本体はこのように区切られます
------_=_NextPart_001_01CEE199.851D3871
Content-Type: multipart/alternative;
boundary="----_=_NextPart_002_01CEE199.851D3871"
----_=_NextPart_002_01CEE199.851D3871
headers
body part
----_=_NextPart_002_01CEE199.851D3871
headers
body part
------_=_NextPart_001_01CEE199.851D3871
つまり、配列 001 の外側境界と、配列 002 の内側境界があります。では、これは何でしょう? これはある種の Microsoft 独自の MIME 仕様ですか、それとも私が見逃した rfc にありますか? これは解析がより複雑です。