メール送信プログラムを組んでるとき、文字コードの指定に問題なく、ほとんどの文字が化けてないのに、ある部分だけ小規模に化けている場合。
対処法としては、
１．一見問題なさそうな文字コード変換、気付かず２重にコード変換を行っていたなんてこともあるので、ソースを見直す。
２．メール送信仕様の確認。実は送信時は、こんな規定があります。
以下 「インターネットメッセージフォーマット」(この標準は、”電子メール” のフレームワークにおいてコンピュータ利用者間で送信されるテキストメッセージの文法を規定する。現在の慣例を反映し、他の RFC で規定された付加的な変更を取り入れることで、この標準は RFC 822(“Standard for the Format of ARPA Internet Text Messages”)に取って代わるものである。)
ここから抜粋引用 –→
送信データ１行の長さの制限
この仕様が 1 行の文字数に課す制限は二つある。CRLF を除いて、各行は 998 文字を超えてはならならず(MUST)、78 文字を超えるべきではない(SHOULD)。
998 文字の制限は、インターネットメッセージフォーマットのメッセージを送受信したり保存したりする実装の多くが 998 文字を超える行を扱えないという単純な理由によるものである。堅牢性のために受信側実装は自己判断でもっと長い 1 行を正常に扱うだろう。しかしながら([RFC2821] における転送の要求事項に適合しながらも)、CRLF を含めて 1 行が 1000 文字を超えるメッセージを受け付けない実装は数多く存在するため、実装がそのようなメッセージを生成しないことは重要である。
より保守的な推奨事項である 78 文字の制限は、78 文字を超える表示を切り捨てたり、悲惨なラップをしたりする可能性のある多くのユーザーインターフェイス実装に適合するためのものである(本当はそのような実装はこの仕様の目的に(そして実際に情報を失ってしまうなら [RFC2821] の目的にも)適合しない)。この制限はメッセージに課されるものだが、堅牢性のために任意の長い行(もちろん長くとも 998 文字以下の行)を扱う実装に課される義務でもある。
←—ここまで抜粋引用
要するに、送信では、１行（改行無しの文字列）の長さの規定しているのでそれ以下で送信するようにと言うことです。長い場合は無条件に自動改行が入る為、運悪くその位置がマルチバイトだった場合、文字化けが起こり得る解釈
この「インターネットメッセージフォーマット」に関して
この文書の位置付け ：
この文書はインターネットコミュニティのためのインターネット標準トラックプロトコルを規定しており、改良に向けての議論と提案とを求めている。このプロトコルの標準化の状態と状況は “Internet Official Protocol Standards” (STD 1)を参照してほしい。この文書の配布に制限はない。
著作権通知 ：
Copyright (C) The Internet Society (2001). All Rights Reserved.
