[mew-dist 29368] Re: Qエンコードされた添付ファイルのデコードについて

[Kazu Yamamoto ( 山本和彦 )]

山本です。

> いろいろ調べてみた結果、Qエンコードされた文字列の行末が“=”で終わってない場合
> に、Mewが \0d \0a ではなく \0a でデコードしているため \0d が抜け落ちているのが
> 原因のようです。

僕が理解したことまとめておきます。

Windows の行末は CRLF です。

行末という構造を持つデータをテキスト、それ以外をバイナリと呼ぶことにし
ます。Excel のデータがテキストか、バイナリかはよく分かっていませんが、
おそらくバイナリだと思います。

バイナリ中の CRLF は、quoted-printable では =0A=0D と符号化しないといけ
ません。テキスト中の行末は、インターネット上の行末 CRLF に直し、つまり
Windows 上では結果的に無変換で、=0A=0D と符号化しないといけません。

いずれにせよ、=0A=0D と表現すべきデータを、Outlook は CRLF と表現します。
これが、インターネットを通じて配送されます。

このデータを復号化するとエラーになるのは UNIX です。UNIX では、行末は
LF ですので、CRLF を LF として保存します。=0A=0D と符号化してあれば
CRLF に戻せますが、そうではないので LF のままです。(Mew の構造上、
Window 上の Mew でも、同じ問題が起こるかもしれません。)

某掲示板では、Mew が悪いことになっていますが、間違っているのは Outlook
です。

対策としては、quoted-printable を復号する場合は、行末を CRLF として
mewencode に渡す。そして、復号化したデータを読み込む際に、CT: から判断
してテキストであれば CRLF を Emacs の内部コードである LF へ、バイナリな
らそのまま読み込む、という方法が考えれます。

これで救えるのは、あくまで Excel のデータがバイナリである場合だけです。
最近は Excel のデータも XML、つまりテキストだと思っていたんですが、どう
なんでしょうか？

この方法は、思いつきであって、実際にやってみると、これまでうまくいって
いたものを壊す可能性もあります。

--かず