いろいろ
Seize the day.

■ [comp] OE の MIME メールデコードの謎の続き

前回のエントリ [2005-11-27] の続きです．

えー，またまた，大変申し訳ありません．前回のエントリで思わず脊髄反射で「OE が悪いんじゃね?」とか書いてしまいましたが(激ぉ，OE は悪くありませんでした(ぉ．重ね重ね大変失礼しました．orz

• http://www.kagami.org/diary/2005-11-28-1.html

しかし POP で取って来た場合になぜ大丈夫なのかはこれでは説明がつかない，とされている．
…いや，説明つくんじゃないかな．Mew が改行を LF にしてファイル保存しているからじゃない?

Mew の保存ファイルはあくまで Mew のファイル形式であって，それが RFC822/RFC2045 準拠だとは誰も言ってないから，改行が CRLF じゃないからと言って非難できない (なんかいろいろ議論があって Mew では改行は LF に統一することになったらしい)

あああー，そうか，そうですね．そうでした orz．Mew が LF にしちゃってるのか．UNIX だもんな．完全にぼけてました．OE もまさか LF なメールを読まされるとは思ってなかったわけだから，非難はできませんね．OE よ，悪かった．許してくれ．

sleep 3

とでも書いときましょか．うわあ，だせえ．

ちなみに SoW 連係用スクリプト oe.pl では，このダサダサな手法を使ってました．しかも当初 [041207] はまさに 3 秒にしてましたが，どうも不安定なので，経験上 7 秒くらいにしています [051008]．
ついでに 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 ファイルと互換らしいです．

• http://www5d.biglobe.ne.jp/~rugeye/html/tips_den8+oe.html

mht ファイルは RFC 2557 で定義されている MHTML (MIME HTML) のことです．MIME 準拠らしいです．

• http://www.ietf.org/rfc/rfc2557.txt

- 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.

eml ファイルの拡張子を mht にすると IE で開ける．でも添付ファイルは見えなくなるみたいだ．