2002.12.03

　Eudora5から Becky!2への移行

　メールクライアントソフト、正確には MUA(=Mail User Agent)と呼ぶのであるが、ここではメールソフトとしている。

　僕自身はとっくの昔に Becky!2を使い始めている。
　現在 Eudora 5.0までバージョンアップしているのだが、奥さんが使っている。
　Eudora5から Eudora5.1へのバージョンアップの案内が着た時点で、バージョンアップすべきかどうか考えたのだが、マイナーバージョンアップなのに有料な事、クニからオンザエッジに業務移管があった事、このまま使い続けていくと、別のソフトに乗り換えようが無くなってしまいそうな事、等いろいろ考えてバージョンアップするのを止め、使用も終了しようと思った。

　で、移行作業に移るのだが、まず、Eudoraを使用していて一番問題になるのは添付ファイルだ。
　Eudoraは、添付ファイルを Attachというフォルダにバイナリー化して保存する。
　この方法自体は Windowsでは珍しくもなく、メールソフトウェアのほとんどが添付ファイルを独立ファイルとして保存している。
　この方法の長所は、既にファイル化されているので、編集出来るという点だ。編集出来るという事は、受信した書類に何か追加して送信、ということが出来るという事。
　短所は、ファイル化する時に受信メール自身から添付ファイル部分を削除する場合が多いという事だ。添付ファイルの場合、元のデータはバイナリーデータと考えられるので、そのままでは通信出来ない。通信出来る形に変換してメールにくっつけて送信する。厳密にはすべてのファイルはバイナリーデータで、便宜上通信出来るデータをテキストデータと呼んでいる。つまり、細かくは説明しないが、通信出来るデータとは基本的にアルファベットや一部の記号のみで、その他のコードは通信出来ない。そこで、通信出来るデータに変換してやる作業が必要になってくるのだ。そしてその変換されたデータをメールにくっつけて送信し、受信側で元のデータに戻してやる作業をする事になる。この時、Eudoraは元に戻すと同時に、受信メールにくっついている変換されたデータを削除してしまうのだ。
　移行作業で問題になるのは、Eudoraでは「受信メールから添付ファイル部分が削除されている」という点なのだ。そして、その部分に、展開した添付ファイルへの絶対パスが書かれている。

　もう１つの問題点は、Eudoraは受信した文字コードに関係なく、すべて S-JISに変換してしまうという点だ。
　これは JISで受信しようが、EUCで受信しようが、すべて S-JISに変換して保存しているという事だ。Mac版 Eudoraではどうか知らないが、Windows版ではそうなっている。Windowsの場合は S-JISの方が扱いやすかったからだろう。
　メールにはその送信した時の文字コードが書かれている。ちなみに JISの場合は、「Content-Type: text/plain; charset="ISO-2022-JP"」という感じだ。これを信じて表示するように作られているメールソフトの場合、Eudoraのデータでは S-JISになっているので、日本語部分が文字化けする事になる。
　最近のメールソフトはそこら辺も賢くなっていて、Content-Typeの記述にかかわらず本文の文字コードを自動判定して表示してくれるソフトが多い。

　さて、実際の作業は大変だった。
　まず、いろいろ探してみた。

　等を参考にして、いろいろテストしてみたが、添付ファイルを元に戻してくれるような変換ツールは存在しない。
　ここまでは、いろいろテストをして、大変な作業だった。
　しかし、ラッキーな事があった。
　それは、JustSystemの Shurikenで Eudoraのメールが添付ファイル込みで取り込めるのだ。
　そしてそのメールボックスは普通のテキストで、メール個別に、「====================KeyABCabc0123456789XYZxyz-Mailer-MailBox-Delmit-Line-Do-Not-Edit-JustSystem====================」で、区切られている。
　メールファイルをテキストエディタで開いてみると、ちょっとゴミだのなんだのはあるが、そのままインポートしても大丈夫そうなデータばかり。
　おお！これなら使えそう！
　というわけで、Shurikenのメール移行ツールでフルオートでインポート＆Beckyにインポート出来るようになった。
　ばんざーい。
　ただ、ここで最後の難関というか、やっぱり全部がうまくいくわけではないのねというか、問題が１つだけ残った。
　それは、送信メール日付に +0900が付いていないという事だ。
　まあ、これははっきり言えば Eudoraは Fromは正しく設定されている。Eudoraの区切りは「From address date＆time」という unixでも標準のメール区切り文字列である。Shurikenではたぶんその区切りをチェックしてメールを分割し、そこにある日付と時刻を Date:に設定しているようだ。ただ、その日付には +0900というタイムゾーンは無いし、通常の Date:に設定される順番とも違うのだが、Shurikenはそのまま変換しているようだ。RFCでどこまで書かれているのかはわからないが、Eudoraの送信メールに Date:が無いのが問題なのである。
　Shuriken側の処理もわかる。Eudora From行（メール区切り）は正しく設定されているのだが、Date:行がないために、Dateを作らなければいけなくなり、Fromを使っているのだと。でも通常の Date:行と同じ並びにして欲しかったぞ。これも RFCでちゃんと規定されているかどうかわからないから、Shurikenの動作が正しいかどうかはわからない。
　最後に、Shurikenのメールボックスを区切り「====================KeyABCabc0123456789XYZxyz-Mailer-MailBox-Delmit-Line-Do-Not-Edit-JustSystem====================」で Becky!にインポートすればちゃんと添付ファイル付きのメールとしてインポート出来る。
　とりあえず、送信メール日付が日本の場合 +0900になっているので９時間のずれが生じる他は Shurikenの区切り文字列がちょっと汚いだけで、添付ファイルもすべて移行する事に成功した。 　但し、送信メールの添付ファイルは元々Eudora自身に保存されていないのでこれはどうやっても無理。もちろん、同じドライブ構成で同じディレクトリに同じファイルが存在していればうまくいくのだろうが。

　さーて。後は、昔のメールのほとんどの文字コードは JISになっているし、残りはアルファベットだけだから、この送信メールの Date:行だけを修正するようなエディタ用マクロを作るかな。プログラムだと文字コードの処理が面倒そうだからやめ。エディタで処理すると JIS以外がどうなるかわからない状態になるけど．．．えーい、面倒だから、どうせ JIS以外のメールは不必要なメールがほとんどだから良いや。