長文メールでの本文文字化け - 秀丸メール情報交換会議室 - スレッド19952, 2004/09/27

長文メールでの本文文字化け

ＧＡＲＩ さん　04/09/27 17:05

鶴亀メール3.66を使用しています。

一行の文字長さが、１０００バイトを超えるようなメール
を受信した際、９８０バイト目あたりで余計な改行が入って
しまい、文字化けする可能性があるようです。

元の文：
…（省略）…まず第一に、仕事の上でも個人の成長の上でも、

受信後の文： v- 先頭から987byte目
…（省略）…まず第一に、仕事!
$N>e$G$b8D?M$N@.D9$N>e$G$b!"$h$jL@3

WinBiffでも同じように化けていたのですが、
関連するメールを開く＞Outlookでログを開く
を試してみると、正常に表示されました。
また、受信ログをデコードして開いても、同様の
文字化けになりました。

OSはWindowsXPです。

RE:19952 長文メールでの本文文字化け

秀まるお2 さん　04/09/27 17:28

　たぶんですけど、化けているのは送信経路上、つまり、メールサーバー上で余
計な改行が挿入されたせいだと思います。そういう例が過去に報告されてます。

　Outlook Expressで化けないのは、たぶんですけど、JISコードの途中に無理矢
理改行が入った場合の処理方法が違うせいだと思います。化けないといっても、
それはたまたまであって、場合によっては（２バイト漢字コードの途中に改行
コードが入ったりした場合は）化けると思います。

RE:19953 長文メールでの本文文字化け

ＧＡＲＩ さん　04/09/28 14:26

ありがとうございました。

社内経路のみの配送ですので、情報システム部門に聞いてみること
にします。参考までに、件のメールは鶴亀、WinBiffでは文字化け、
EdMax(Free)、Outlookでは正常に読めるようです。

RE:19966 長文メールでの本文文字化け

秀まるお2 さん　04/09/28 14:51

　Outlookはどうか分かりませんが、Outlook Expressでは、JISコード中に改行
が入ると、それは

　w)

　のような形で化けて表示されてしまうようです。

RE:19967 長文メールでの本文文字化け

ＧＡＲＩ さん　04/09/29 12:48

ご指摘のように、社内経路の設定で、９９０バイト目で
改行が入るようになっていたようです。

RFC2822 (RFC288 の更新版) では1行は 998文字までと
制定されているためだ、と指摘されてしまいました。

RE:19973 長文メールでの本文文字化け

ＧＡＲＩ さん　04/09/29 13:21

RFC2822見てみました。この辺はグレーぽいですね。

・送信する側のメールクライアントが、９９８を超えないようにする
のが正しいのか、
・経路上のサーバが、９９８超の行を途中改行する際に２バイトコードに対応する
のが正しいのか、
・受け取る側が、途中改行が２バイトコードの途中に入った場合でも正しくデコード
できるような仕組みがいる
のが正しいのか？？？

RE:19974 長文メールでの本文文字化け

秀まるお2 さん　04/09/29 13:57

　僕もRFCのことはよく分かりませんが、メール本文をbase64エンコードして送
信することで、少なくともサーバーによる改行問題は回避可能ではあります。

　鶴亀メールの場合は、メールを作成するウィンドウ上で、「設定・送信用の特
別設定...」とやって、そこの「メール本文をbase64エンコードして送信する」
をONにすればいいです。

> ・経路上のサーバが、９９８超の行を途中改行する際に２バイトコードに対応する
> のが正しいのか、

　998超の行に改行が入らないサーバーも存在します。
　そもそも、世の中みんなRFCに従ってる訳でもないし、RFCで厳格な規定がされ
てないケースは多いです。（特に多国語対応関係で）

RE:19975 長文メールでの本文文字化け

Koichiro さん　04/09/29 14:32

>> ・経路上のサーバが、９９８超の行を途中改行する際に２バイトコードに対応する
>> のが正しいのか、
>
>　998超の行に改行が入らないサーバーも存在します。

RFC2822の該当箇所は
「998bytes超の行をそのまま配送しないMTAもあるから送信者は要注意」
と読むべきで、
MTA側が999bytes目以降で改行を入れるべきか違う処理をすべきかまでは
規定していません。

また、マルチバイトコードの変わり目をMTA側で判別するのは
不可能に近いのではと思います。