インターネット上の電子メール (いわゆる e-mail) では、送れる情報は 「テキスト」だけで、「バイナリ」は送れないとされています。 ここでいう「テキスト」と「バイナリ」の意味について、説明します。

電子メールでバイナリデータを送れない理由と、その回避法

最初、電子メールは、ASCII コードで書かれたテキスト、 言い換えれば、英語で書かれた文書をやりとりする目的で開発されました。 ASCII コードで書かれたテキストとはすなわち、 ASCII コードで印字可能文字にあたる数 (32〜126) と、 少数の制御コード (改行など) からできているデータです。

しかし、バイナリデータは 0〜255 の範囲の数をすべて使いますので、 0〜31 と 127〜255 の数についてはうまく送れない可能性があります。 可能性がある、と今書きましたが、これは、 インターネットを構成するコンピュータには様々なものがあり、 その上で動いているメール送配プログラムにも様々なものがあるので、 どうなるか見当がつかない、ということです。

また、現在のメールシステムは、ASCII コードだけではなくて漢字や 非英語アルファベットなども扱うことができるように拡張されています。 このとき、拡張のやり方が、従来からあるシステムに乗せるだけで、 総入れ替えしなくても済むような設計になっています。このために、 日本語は ISO-2022-JP というコード体系を用いることになっています。 メール送信プログラムは、そのプログラムが走っているコンピュータの 漢字コードを ISO-2022-JP に変換して送信し、受信プログラムは、 受け取った ISO-2022-JP コードを、 受信プログラムが走っているコンピュータが用いている漢字コードに変換して 表示する、といったことを行います。 このおかげで、ASCII コードしか受け付けないメール送配プログラムを 途中で経由しても漢字データが正しく伝わり、また、 異なる漢字コード (たとえば、シフト JIS と EUC) を用いるコンピュータの間で正しく漢字データをやりとりすることができるのです。

しかし、バイナリデータを送りたい場合は、この仕組みがじゃまになります。 たとえば、EUC を使うコンピュータから ShiftJIS を使うコンピュータに、 A1 A2 [16 進数] というバイナリデータを送ったとします。すると、 A1 A2 は「、」という文字に解釈できるので、受け側では「、」の ShiftJIS コードである 81 41 [16 進数] というふうに受け取ってしまいます。

漢字コードが正しく伝わる、といっても、 すべての文字についてうまく変換してくれるわけではありません。 半角カタカナは全く使えませんし、 JIS コード 222E (シフト JIS コード 81AC、 区点コード 00214) 以降の記号や罫線は使わない方がいいでしょう。 文字化けする可能性があります。 また、半角の円記号はバックスラッシュに化ける可能性があります。 通常の漢字は OK です。

英国の会計士になる方法

ここで、「なぜ、文字データを文字コードで送るんだ。 文字の形のデータを送れば、文字化けなんて起こりようがないじゃないか」 と考える人がいるかも知れません。しかし、その方法は、

• データ量が膨大になる。文字コードを使うと、 1 文字のデータを送るのに 1 バイトか 2 バイトで済む。 文字の形のデータを送るとなると、そうはいかない。 たとえば、文字の形を 16×16 ドットで表すとすると、 1 文字につき 32 バイトものデータが必要になる。
• 検索が効かなくなる。コンピュータで文書を扱う最大の利点は、 一瞬にして検索をかけることができることです。 それは、文字コードを使っているからこそ可能なのであり、 もし、文字の形のデータを使ったら、検索を行うにも 文字の形のパターン認識を行わなければならなくなる。 それはプログラマ (特に、プロのプログラマではなくて、 日曜プログラマ) にとっても大変だし、コンピュータにとっても 負担が大きい (たぶん、実用的---つまり、 DOS 的---な速度と信頼性が出るのは遠い将来のことでしょう)。 特に、日曜プログラマへの負担が大きいということは、 フリーソフトが減る、 という問題が生じることを意味します。

という欠点があります。

さらに、もし仮にうまく送れたとしても、 受け手側がそれをどのような形で見ることになるかを考えてみましょう。 メール受信プログラムは通常、受け取ったメールを ASCII コードや ISO-2022-JP コードであると解釈して文字で表示します。 バイナリデータをこのような方法で表示することに、 どんな意味があるでしょうか。たいていの場合、 表示された文字は、 わけのわからない文字の羅列になっていることでしょう。

このほかにも、電子メールでバイナリデータが送れない原因があります。 電子メールは「行」という単位で処理が行われます。「行」とは、 改行コードの次の文字から、次に現れる改行コードまでの間のことです (これが「行」になることはおわかりですね)。電子メールでは、 「行」があまり長いと不都合 (しっぽが切り捨てられるなど) が生じる恐れがあるので、だいたい 70 文字 (漢字なら 35 文字) ごとに改行コードを入れてやる必要があります。 これは、インターネットを構成する様々なコンピュータの上の 様々なメール送配プログラムの中には、 メールを「行」単位で処理し、「行」のための記憶容量が 80 文字分程度しか確保されていないようなプログラムが 存在する可能性があるからです。 文字データを送りたいときは、このことはさほど不便なことではありません。 手紙の文章の文の途中で改行されていたからといって、 別の意味にはならないからです。 しかし、バイナリデータを送るとなると、話は別です。 バイナリデータの途中に勝手に改行コード (というか、 バイナリには「改行コード」という概念がないので、 テキストとして解釈したときに「改行コード」になるような数、のこと) を入れてしまうと、もとのデータとは全く違ったものになってしまいます。

そこで、ある一定の方法に従ってバイナリデータを、 電子メールで許容できるようなテキストに変換するプログラムが 必要になります。 「電子メールで許容できるようなテキスト」というのは、 ASCII コードで表現できる範囲の文字 (ASCII コードで 20〜7E [16 進数]) であり、行の長さが 70 文字程度以下である、というこです。

そのようなプログラムについて、具体的に説明しましょう。たとえば 「X」という文字は 50 という数を表す、というふうな共通の「決めごと」を つくり、それに基づいて動くプログラムを 上記のコンピュータ A とコンピュータ B の両方で作っておきます。 そして、コンピュータ A の側で送りたいバイナリデータがあった場合に、 データをそのプログラムで処理してやるとテキストに変換され、 それをメールで送り、 コンピュータ B の側でバイナリに戻してやるという手順を踏むと、 バイナリデータをメールで送ることができるのです。

実際には、文字の種類は 256 (1 バイトで表現できる種類) よりも少ないので、 たんに「X」に 50 を対応させるというのよりももっと複雑な「決めごと」が 必要になります。そのような「決めごと」の例は、すでに 「7. バイナリファイルとはなにか --- テキスト以外のファイルのことである」 で紹介しましたね。

さて、その「決めごと」ですが、 メールをやりとりするコンピュータの間では同じ「決めごと」を使う必要があります。 理想的には、世界中で同じ「決めごと」を使うことに決めればいいですね。 実際には、歴史的な経緯から、 広く用いられている何種類かの「決めごと」が存在します。 それには、ish、uuencode/uudecode、base64 があります。 これらの変換を行うプログラムについては、 たとえばベクターなどに あります (あとで紹介します)。

ish

ish は、パソコン通信の世界で古くから用いられてきたツールです。 作成するテキストに漢字を含むようにすることができ、 これによって、変換の効率を上げることができます。 また、エラー訂正などの付加機能もあります。 パソコン通信の世界では現在でも広く使われていますが、 インターネット上の電子メールで使われることは、まずないでしょう。

uuencode/uudecode

これは、UNIX の世界 (つまり、結局のところインターネットの世界) で古くから用いられてきました (UNIX には、 このプログラムが標準で入っている)。 現在でも、ftpmail などで利用されています。 一部のメールプログラムの「添付書類」には、 これに則ってテキスト化する、という内部動作をしているものがあるようです。

base64

これは、新しい方法です。最大の特徴は、変換したテキストファイルに、 アルファベットと数字と「+」「/」の 64 文字しか使わないことでしょう。 これは、世界中のどんなコンピュータでも動くようにとの配慮からです。 つまり、ASCII コードにさえ依存していません。

一部メールプログラムの「添付書類」機能について

ところで、一部のメールプログラムには「添付書類」などの機能があって、 それを用いると簡単にバイナリデータを送ることができます。 そのメールプログラムは、「添付」されたファイルを内部で「なんらかの方法で」 自動的にテキストに変換して、メール本体に「なんらかの方法で」つなぎ合わせて いるのです。 受け取り側は、つなぎ合わされたメールを分離し、バイナリに戻す、 ということを自動的に行っています。

しかし、これはあまりおすすめできません。 なぜなら、上に「なんらかの方法で」と 2 回書きましたが、 その「なんらかの方法」が、そのメールプログラム独自のもの (である可能性がある) なので、 同じメールプログラムを持たない人にとっては 送られてきたメールが意味不明になってしまうからです。

それに、メールは基本的にテキストしか送れないので、 メール本体につなぎ合わせるための「なんらかの方法」も、 テキストデータを識別子に用いていると考えられます (たとえば「---binary---」という文字の並びがあったら、 そこから先は添付書類の内容だという目印だよ、ということ)。 だから、もしメール本体の内容に、その識別子と同じ内容を偶然書いてしまったら、 メールプログラムの誤動作が起こることが予想されます。 たぶん、非常に低い確率でしょうが、もし起こってしまった場合、 (特にマックのソフトにありがちですが) 絶対に融通が利かなくて 修復のしようがない、ということになってしまいます。

ただ最近、「MIME」という、 メールでバイナリデータを送るときの 「なんらかの方法」の「決めごと」があります。 しかし、これは登場して間もない「決めごと」なので、 対応していないプログラムがけっこうあります。

とくに、市販のメールソフトの独自の「決めごと」 に従ってバイナリデータを送るとか、 フリー (無料) であったとしても特定の OS でしか動かないような メールソフトの独自の「決めごと」に従ってバイナリデータを送る、 といったことはマナーが悪いと思います。ぼくのところにも、研究室の同僚から 「わけのわからん記号ばっかりのメールを受け取ったんだけど」といった 相談がたまに持ち込まれますが、 こういったメールを送ると相手が困るかもしれないということが、 一日も早く、広く知れ渡ってもらいたいものだと思います。

もし変な記号の羅列のメールを受け取ったら

もし、変な記号の羅列のメールを受け取ったら、 差出人から何かコメントがないかどうか見てみましょう。 もし、「この記号の羅列は・・・だよ」という説明が書いてあれば、 それに従えばいいですね。ここでは、そんな説明が書いていない 場合の話です。

まず差出人に「こんなヘンテコリンなメールが来たぞ」ということを 知らせましょう。たぶん、差出人は、 自分の送ったメールが受取人の側では変な記号の羅列になってしまっている、 ということを知りません。

次に、その変な記号の羅列を解読することを試みます。 まず、その記号の羅列を見て、 ほとんどの行について、1 行の文字数が等しいということを 確認してください。もし、そうでないなら、ちょっとここではお手上げです。

次に、その記号の羅列を見て、

• アルファベット、数字、「+」「/」しか出てこない場合→base64
• 行がすべて「M」で始まっている場合→uuencode/uudecode
• 最初の 3 行が同じ内容の場合→ish

次に、base64 や uuencode/uudecode の場合には、 「変な記号の羅列」の先頭部分に ファイル名らしきものが書いてあると思いますので、 そのファイル名をつけてやって下さい。

あとは、そのバイナリファイルが何か、という問題ですが、 Windows/DOS なら、拡張子で分かります (つまり、 ファイル名のおしりがどうなってるか、ってこと)。 「.JPG」や「.JPEG」なら JPEG 形式の画像、 「.GIF」なら GIF 形式の画像、 「.MAG」なら MAG 形式の画像、 「.TIF」なら TIFF 形式の画像、 「.DOC」ならワード文書、 「.LZH」なら LHA で圧縮した書庫、 「.ZIP」なら PKZIP で圧縮した書庫、 「.TAR.GZ」や「.TGZ」なら tar と gnu-zip で圧縮した書庫、 といった具合です。 ここから先は、 それぞれの形式を理解できるプログラムを各自で用意するしかありません (でも、ワード文書を送っておいて、 読み手に対して「ワードを買え!」なんてのは感心できませんね)。

問題は Macintosh ですが、こちらは、ファイルの「種類」の 情報が失われたら手も足も出ません。どうすればいいんでしょうねえ? ぼくもこれで困ったことがあるんですが、こういうときって Macintosh って融通が利かないですね。「ダメなもんはダメ」って、 どこかの議員さんみたいなところがあって (別にその議員さんを けなすつもりはありません)。 身の回りの達人にでも聞いてください。

「データの形式っていったい何なの？」に戻る

久保田智広ホームページに戻る