g740564
)
1998 年 4 月 28 日
(6 月 2 日・25 日 加筆訂正)
重要度: ★★☆ (後日でいいので必ず読んでください)
なお、RMAIL から MH への移行方法を下に示しましたので、参考にしてください。
一般に、電子メールでは、 各行の右端で改行を入力すべきであるとされています。
ところが、現実には段落末まで改行を入れないメールがあるため、 RMAIL では、メールを受け取ったときに、改行から改行までが 127(= 27-1) 文字を超えると、 127 文字目の直後で強制的に改行を入力してしまいます。
これは、英文ではそれほど大きな問題はありません。 (単語の途中で改行されるという不都合はありますが…) ところが、RMAIL は漢字圏のことをまったく考慮していないので、 日本語のメールを受け取ったときに問題が生じます。 日本語の文字(いわゆる全角文字)は 1 文字で英文の文字 (いわゆる半角文字)2 文字ぶんとして扱われるので、 *1 ある全角文字が 127 文字目(全角文字換算では 64 文字目の前半)と 128 文字目(同、後半)にまたがっていると、 RMAIL はその中間に改行を入れようとします。そうすると、 二つに割られた全角文字の右半分が次の文字の左半分と結び付いて、 まったく別の全角文字に化けてしまいます。 さらに、その文字の残った右半分がその次の文字の左半分と… というふうに連鎖反応を起こして、 その行は読めなくなってしまいます。
*1: 厳密には必ずしも正しくないのですが、 ここではとりあえずそういうものだとお考えください。
コンピュータ内部での日本語の記録方法には、 主なものとして次の 3 種類があります。
電子メールの送受信には JUNET 方式を用いることが推奨されていますが、Windows などのメールソフトの一部では、特に設定しない限りメールをシフト JIS 方式で送るようになっていることがあります。 また、ECC 内部でやり取りされているメールは JUNET 方式が主ですが、中には EUC 方式のものもあります。
では、そういったメールを受け取ったらどうなるでしょうか。
RMAIL ではすべてのメールを一つのファイル(~/RMAIL
)に保存しますので、3
種類の方式で記録された文章が一つのファイルに混在することになります。
この中で、 JUNET 方式と EUC 方式が一つのファイルに混在していることには、ほとんど問題はありません。 JUNET 方式とシフト JIS 方式の混在も、 それほど大きな問題ではありません。
しかし、EUC 方式とシフト JIS 方式を一つのファイル中で混在させることは、 原則としてできません。 そのため、EUC 方式のメールを既に受け取ったあとでシフト JIS のメールを受け取ると、 その新着メールは文字化けを起こしてしまいます。 場合によっては、Mule がデータ構造の分析を誤り、 今までは読めていた EUC 方式のメールまで読めなくなってしまいます。
RMAIL では、すべてのメールを一つのファイル(~/RMAIL
)に保存します。人によっては数百通のメールをためていることもあるので、このファイルは 3〜4
メガバイト(1 メガバイトは日本語で約 52 万字)
以上になることもあります。
これだけでは特に問題はないのですが、Mule
でこのファイルを開いてから C-x C-s
で保存すると、もうひとつ、ほぼ同じ大きさのファイル
(~/RMAIL~
)を作ります。*2
このため、本来必要なディスク容量の 2
倍を占拠してしまいます。
ECC では、学生ひとりあたりのディスク容量制限は 15 メガバイトとなっているので、RMAIL が原因で容量制限を超え、 ログイン不能になる例がときどきあります。
*2: このように、ファイル名の末尾に「~
」がついたファイルはバックアップファイルと呼ばれ、
Mule でファイルを保存したときに、古いファイルの名前のあとに
「~
」をつけて残しておいたものです。
これは、誤って古いデータを消してしまったときに復旧できるようにするためのもので、通常は必要ないものです。
(危険度 ○●○ : 少々の危険は伴いますが、 原則としてご自分で行ってください。なお、文字化けやディスク容量制限などの問題を抱えている場合、 また途中でうまく行かなくなった場合は、絶対にご自分で直そうとせず、 相談員に相談してください。)
~/RMAIL
を、
MH でも読み込める形式のデータに変換します。
Mule から M-x unrmail を入力し、
「RMAIL ファイル名」には~/RMAIL
を、
「メールボックスファイル名」には適当な名前(仮に
~/mailbox.dat
としておきましょう)
を指定します。そうすると、~/RMAIL
に記録されているメールが、この
~/mailbox.dat
に書き出されます。
文字化けの影響で、「Bad format in RMAIL file」
と表示される場合、また、ディスクの容量制限オーバーで
~/mailbox.dat
に書き込めない場合は、
下の注を参照してください。
この他に、kterm から b2m
というコマンドを使用する方法もありますが、
このコマンドは「Bad format in RMAIL file」
のエラーが発生すると黙って
(エラーメッセージを出さずに)作業を打ち切るので、
使用はあまりお勧めしません。
Kterm から「inc -file ~/mailbox.dat
」
として、~/mailbox.dat
を
MH に読み込ませます。
すべてのメールが MH 形式に変換され、正常に読めていることを確認してから、 不要になったファイルを処理します。
なお、今まで MH と RMAIL を併用していた人の場合、
MH で今まで受け取ったメールの後ろに、
RMAIL から移行したメールが保存されることになります。
それで不便な場合は、Kterm から
「sortm -verbose
」と入力すると、
メールを発信時刻順に並べなおすことができます。
詳しくは Kterm から「man sortm
」
と入力して調べてください。
*** EOOH ***
」という行が正しく読めず、
「Bad format in RMAIL file」と表示される場合は、
途中まで書き出された古い ~/mailbox.dat
を削除してから、適当な新規ファイル上で
してそれを(auto-save-mode nil)
(insert-file "~/RMAIL")
(query-replace "\^_\^L\n" "\^_\^L\n1,,\n*** EOOH ***\n")
~/RMAIL
以外のファイル名で保存し、
そのファイルに対して M-x unrmail します。
コンピュータのディスクの中は、cluster と呼ばれる小さな部屋に区切られています。 (さらに小さい sector という単位もありますが、これは 「部屋の中の畳一枚」のようなものだと思って下さい。)ひとつのファイルの大きさがこの部屋より大きいときは、 そのファイルを複数の部屋に分けて収納します。 しかし、ファイルの大きさがこの部屋より小さいときでも、 複数のファイルで相部屋ということはしません。 従って、小さなファイルがたくさんあるときには、 ファイルの数だけ部屋が必要になり、本来必要な容量よりたくさんのディスクを消費してしまいます。 これが、cluster gap 問題です。
MH ではメール 1 通あたりひとつのファイルを使うので、 ひとつひとつの部屋が大きいディスクを使う場合 (たとえば、Windows 上で Mule を動かす場合) にはディスクを浪費することがあります。
しかし、ECC の環境ではひとつひとつの部屋がじゅうぶん小さいので、特に心配する必要はありません。
駒場 ECC には mh-e (引用者注: Mule 上から MH を使うことをさす)の他に RMAIL と呼ばれるメールリーダがある。 RMAIL は、(略)文字化けメールや不幸の手紙に弱く、 機能にも限界がある。(66 ページ)不幸の手紙の中には RMAIL などで読むとメールリーダを故障させるように特殊な文字を埋め込んである悪質なものもあるので、 受け取ったらシステム管理者に知らせよう。 (70 ページ)
wwwadmin@sodan.komaba.ecc.u-tokyo.ac.jp