OE の MIME メールデコードの謎の続き
前回のエントリ [2005-11-27] の続きです．
えー，またまた，大変申し訳ありません．前回のエントリで思わず脊髄反射で「OE が悪いんじゃね?」とか書いてしまいましたが(激ぉ，OE は悪くありませんでした(ぉ．重ね重ね大変失礼しました．orz
しかし POP で取って来た場合になぜ大丈夫なのかはこれでは説明がつかない，とされている．
…いや，説明つくんじゃないかな．Mew が改行を LF にしてファイル保存しているからじゃない?
あああー，そうか，そうですね．そうでした orz．Mew が LF にしちゃってるのか．UNIX だもんな．完全にぼけてました．OE もまさか LF なメールを読まされるとは思ってなかったわけだから，非難はできませんね．OE よ，悪かった．許してくれ．
Mew の保存ファイルはあくまで Mew のファイル形式であって，それが RFC822/RFC2045 準拠だとは誰も言ってないから，改行が CRLF じゃないからと言って非難できない (なんかいろいろ議論があって Mew では改行は LF に統一することになったらしい)
ちなみに SoW 連係用スクリプト oe.pl では，このダサダサな手法を使ってました．しかも当初 [041207] はまさに 3 秒にしてましたが，どうも不安定なので，経験上 7 秒くらいにしています [051008]．
sleep 3
とでも書いときましょか．うわあ，だせえ．
ついでに oe.pl 自体にも，CR 付加機能を実装しときました (こちら)．これで SoW 経由の場合も正しく Excel ファイルが開けるはずです．
つーわけで多分これが本当のまとめ．…うへえ，さすがにもうこれで打ち止めでいいよな．
- 送付時，Mozilla/5.0 は添付データと boundary の間に空行を入れない．つまり添付データと boundary の間には CRLF があるのみ．
- 受信時，Mew は各行に対し CRLF→LF にしてメールを保存する (つまりファイル保存形式自体は RFC 準拠ではない)．
- これを OE に渡すと，MIME 解析ルーチンが boundary 直前の 2 バイトを CRLF だと思い込んで添付データを切り出す．この結果，添付データの最後の 1 バイトが切り落とされ，base64 的にデータサイズ不整合となる．
- OE の base64 デコーダは，データサイズ不整合の場合，整合するようにデータを切り上げてデコードするので，結果としてデコードされた添付ファイルの末尾 3 バイトが消える．
- Excel の場合，末尾 3 バイトが消えると開けなくなることが多い．
- 解決策としては，Mew が取り除いた CR を補ってから OE に渡すのがよい．
eml ファイルの拡張子を mht にすると IE で開ける．でも添付ファイルは見えなくなるみたいだ．
- The MIME standard [MIME2] requires that e-mailed documents of
"Content-Type: Text/ MUST be in canonical form before a Content-
Transfer-Encoding is applied, i.e. that line breaks are encoded as
CRLFs, not as bare CRs or bare LFs or something else. This is in
contrast to [HTTP] where section 3.6.1 allows other
representations of line breaks.
