Content-Type: text/plain; charset=”iso-2022-jp” Content-Transfer-Encoding: 7bit 文字化けしたメールは；

Content-Type: multipart/mixed; boundary=”===============4244929076788084327==” –===============4244929076788084327==　（本文の部分） Content-Type: text/plain; charset=”iso-2022-jp” –===============4244929076788084327==　（フッターの部分） MIME-Version: 1.0 Content-Type: text/plain; charset=”iso-2022-jp” Content-Transfer-Encoding: 7bit –===============4244929076788084327==–

となる。つまり、メールの本文の部分と、Mailman が付けるフッターの部分２つにわけて送信されている。なおかつ本文の最後にフッターが挿入されていて、さらにフッターがあるのだ。 本文のエンコードでContent-Transfer-Encoding: 7bitが抜けている。メールは本来7 bitなので無くても良いはずだが。Apple のMail.app はUTF-8 を使っている。これでMailman に送付したとき、どこがiso-2022-jpに変換するのだろ？Mail.app で標準テキストというのはいわゆるplaine text なんだろうか？もう一つのはリッチテキストだ。HTML形式は送付できないのだろうか？リッチテキスト＝HTMLらしい。ワードでのリッチテキストと違うのか？ 受信者がパソコンだと、大抵のメールソフトには文字エンコーディングを選択できるので、たいてい読むことができるが、受信者のほとんど全部が携帯で受信している。携帯で変換ができるかどうかわからない。本文の部分が添付書類になってしまったりする。 同じ事を毎週行うのだが、めったにこのようなことは生じない。操作方法は同じだという。 原因は、コピペしたとき、画面には出てこない何かのコードをたまたま含んでしまったためではないかと推測した。そのコードは「正解と解説」の部分にあったので、これを削除した場合は問題なく送付したのだ。 違うかな？　再現性があまりないので、追求するのは止めた。自分のPCだったらやってみるが、人のPCで何回もやるのは時間の無駄だ。 そこで、ワードを使うのは止め、エクセルからテキスト・エディタにコピペして、エディタからメールへコピペすることを勧めた。単純なテキスト・エディタだと、Microsoftがエクセルやワードに埋め込んであるコードを全部取り除いてくれるからな。]]>