ただのテキストの文章をメールで送るのは、文字コード等の設定や使えない文字に気を付ければ良いわけでしたが、バイナリはもっと慎重に考えてください。
ワープロソフトとか表計算ソフトというものに、インターネット標準(STD)は存在しません。
相手が扱えないデータを送っても無駄です。先に確認をとってください。
そもそも、受信者側がバイナリデータが扱えない事もあります。携帯電話にワープロ文書を送っても無駄でしょう。
インターネットメールでは、バイナリデータをそのまま送信出来ません。理由は2つです。
元のファイル → テキスト変換して添付する → 送信
元のファイル ← 取り出してバイナリに戻す ← 受信
色々な方式があり、マシンやソフトによって対応がまちまちです。
対応してないソフトの場合、わけのわからん文字がズラズラ並びますが、目で見ればどの方式なのか見当が付きます。自分でツールを使って元に戻してください。
最近はbase64が浸透してきましたが、受信者が扱えるかどうかわからない場合は、先に聞いておきましょう。
マシンやソフトによってバイナリデータを送受信する手続きは様々ですし、表示のされ方も様々です。このページで雰囲気を掴みましょう。
実際には様々なバリエーションがあり、元に戻すのに失敗するケースも少なくありません。
[12] トラブル対処法を参考にしたり、ツールを沢山用意して、頭をひねってください。
インターネットメールでは昔から使われています。uuencode/uudecodeというツールで変換します。メールの文中に変換した文字列をくっつけます。
「begin 3桁数字 ファイル名」で始まって「end」で終わるのが目印です。
行頭の文字がだいたい揃っているのが特徴です。一般的には「M」です。
この例だと、元に戻すとrenraku.gzというファイルが出てきます。3桁数字はUNIXでのファイル属性を示すものなので、他のマシンではあまり関係ないでしょう。
使う文字は
`!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
ですが、「`」の代わりに「 」つまりスペースを使う場合もあります。希に亜流のuuencodeがあって、別の文字を使っている場合もあります。たとえば、下で紹介しているxxencodeもuuencodeの亜流と言えます。
送受信ともにMacOSである場合はBinHex形式が好まれていますが、他のコンピュータでは滅多に使いません。
「:」で始まって、「:」で終わります。
(This file must be converted with BinHex 4.0)
というのが目印です。
使う文字は
!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
です。
この状態ではファイル名が見えないので、実際に元に戻してみないと判りませんね。これを扱うときは、MacOSのファイル形式の知識が必要かも知れません。
最近のメールソフトの「ファイルの添付」という様な機能は、MIMEのbase64を使っている場合が増えてきました。メールソフト上では表示されないことがありますが、実は次のような謎の文字列がくっついています。
あらゆる場合を想定して考えられたため、他の方式と比べると、ちょっと難しいですね。
まず、ヘッダの「Content-Type: multipart/mixed」でメールが複数の部分に分かれてることを示し、「boundary="何かの文字列"」で、区切りを示します。
本文の「--何かの文字列」がそれぞれの部分を分割し、「--何かの文字列--」で終了します。
分割した部分が、それぞれ「ヘッダ+空行+本文」という形式になっています。
(ヘッダが省略されて「空行+本文」になっている場合もあります)
使う文字は
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
です。最後に「=」が1つか2つ付く場合もあります。
この例ではrenraku.gzというファイル名が付いていますが、もともとデータを送受信する方法ですから、ファイル名が付いていないこともあります。
name=パラメータにファイル名を付けているのは古い形式であり、現在は禁止されています。現在はContent-Disposition:フィールドのfilename=パラメータの方に付ける事になっています。互換性を考えてか、両方付けているケースを多くみかけます。
本文の先頭に「This is a multi-part message in MIME format.」みたいな注意書きが付いている場合がありますが、MIME対応ソフトは表示しないのが普通です。「--何かの文字列」で区切っていないからです。受信者への挨拶等は「Content-Type: text/plain」のところに書き込まれます。
+」「-」で、行頭はだいたい「h」なので区別が付くでしょう。
様々な理由により、ファイル名には沢山の制限があります。
結論から書くと、ASCIIのみを使い、記号を避けて、なるべく短くするのが無難です。そうでないと、色々なトラブルが起きます。
だいたい、次のような感じでしょうか。
ファイル名によっては受信者が扱えない △ やあ元気.JPG日本語のファイル名が扱えない場合があります。 △ HEY YOU.JPGスペース混じりのファイル名が扱えない場合があります。 △ HEYYOU.JPEG3字を越える拡張子が扱えない場合があります。 △ HEY.YOU.JPG拡張子が2つ以上あると扱えない場合があります。 △ HEYYOUHELLO.JPG長いファイル名が扱えない場合があります。 ○ HEYYOU.JPGこういう感じが無難ですな。 ○ heyyou.jpgこういう感じが無難ですな。 ○ HeyYou.JPG無難ですが大文字/小文字を区別しないものもある
ASCIIのみなら大丈夫かと思いきや、駄目な文字もあります。
DOS系の「\」、Mac系の「:」、UNIX系の「/」は、ディレクトリ(フォルダ)の区切りとして使う文字なので、ファイル名に使えません。UNIXは「/」以外は使えますが、扱いが面倒になるので記号によっては避けられる傾向があります。
ASCIIなのにファイル名に使えない文字 DOS系 (DOS, OS/2, Windows等) \/:,;*?"<>|Mac系 :UNIX系 /
これらを全部クリアしないと、日本語ファイル名や長いファイル名は安心出来ません。理由は沢山ありますが、分類すると次のようになります。
必ずしも日本語ファイル名が扱えるとは限りません。
英語版DOS、英語版MacOS、英語版Windows等に日本語化キットのようなものを追加して日本語メールを使っている人もいます。こういう場合は日本語文章の読み書きは出来ても、ファイル名では使えない事があります。UNIX系も似た傾向があります。
文字数制限も様々です。
UNIXはかなり長い文字数が使える事が多いのですが、Windows95以降やMac OS Xは255字までです。MacOS9以前は31字までです。DOSやWindows3.1以前は「8文字」+「ピリオド」+「3文字」までです。
大抵、日本語の1文字はASCIIの2文字分と数えます。
大文字/小文字の区別も様々です。
「abc.txt」と「ABC.TXT」と「AbC.tXt」があった場合、UNIX系は別のファイルとして扱います。
DOS、MacOS9以前、OS/2、Windows等は同じものとして扱います。Mac OS Xは場合によって同じと扱うときと、別と扱うときがあります。
日本語メールは読み書き出来ても、日本語ファイル名は使えないメールソフトがあります。
uuencodeは、かなり昔に日本国外で考えられました。ファイル名は「begin」で始まる行で示すわけですが、ここに日本語を使う事を当時考えていた筈はありません。だから、かなり心配です。
BinHexも、かなり昔に日本国外で考えられました。日本語ファイル名自体もエンコードされていますが、ちゃんとデコード出来るかどうかは、場合によります。日本語版BinHexソフトでも、実はマニュアルとかメニューが日本語になっているだけであり、日本語ファイル名は扱えないものもあります。
MIMEのbase64の場合、昔はContent-Type:フィールドのname=パラメータでファイル名を示していましたが、これは元々間違いです。現在はContent-Disposition:フィールドのfilename=パラメータで示す事になっています。
どちらで扱うかはソフトによって様々なので、トラブルの元になります。また、日本語ファイル名や長いファイル名を扱う方法は後から考えられたので、やはりトラブルの元になります。
無事に日本語ファイル名のままで取り出すことが出来ても、まだ難関があります。
そのファイルを開くアプリケーションの日本語対応が不十分だと、うまく開けない可能性があります。
送信するデータの大きさを考えるとき、「何ページ分」「何枚分」「たてよこ何cm」という考え方は妥当ではありません。
データサイズが「何バイト」「何キロバイト」なのかが重要です。
また、uuencode, BinHex, Base64等に変換したとき、元のサイズの4/3以上に膨れ上がる事も知っておいてください。
データサイズが大きいと、バイナリ → テキスト変換した後の行数が長く長くなっているので問題が発生するかもしれません。
では、どの程度のサイズが限度なのかというと、実は断言出来ません。それぞれのメールサーバによって、まちまちの値に設定されているようですし、送受信するマシンやソフトに限界がある場合もあります。
大きなデータを送らなければならない場合、予め圧縮しておくと、サイズが小さくなります。
元のデータ → データを圧縮 → テキスト変換して添付する → 送信
元のデータ ← データを伸長 ← 取り出してバイナリに戻す ← 受信
あと、ファイルをまとめて保管しておく事をアーカイブ(archive)といい、その為のソフトをアーカイバ(archiver)といいます。これを使うと複数のファイルを一度に扱えて便利かも知れません。
複数のファイル → アーカイブ → テキスト変換して添付する → 送信
複数のファイル ← 展開をする ← 取り出してバイナリに戻す ← 受信
圧縮方式やアーカイブ方式は色々あって、受信者がどれを扱えるかわからないので、先に確認してください。
大抵の圧縮やアーカイブのソフトは、ファイルが壊れていないかどうかチェックする情報を付けます。壊れていたら、伸長や展開をしたときに「壊れているよ」というエラー表示をするでしょう。バイナリデータの送受信がうまくいかない場合、どの段階に問題があったのか探るヒントになるかもしれません。
どうしても日本語ファイル名で送りたい場合、日本語対応のアーカイバを使うという方法があります。アーカイブ後のファイル名をASCIIのアルファベットにしておけばいいのです。ただし、受信者も日本語対応版を用意していなければなりません。lha, StuffIt, Compact Pro等は日本語対応版があります。zip, tar, compress, gzip, bzip2等は、難しいかもしれません。
「事実上の標準ソフト」という言葉を良く見かけますが、それがどの程度なのか怪しいです。
一つのソフトが全てのコンピュータで動くわけではないですから、標準ソフトを作ることは不可能でしょう。RFC等の文書も事実上の標準であり、更にその一部がインターネット標準(STD)となっていますが、「形式」を提案してるだけであって、ソフトを選定してるわけではありません。
テキストとかバイナリに関わらず、何らかの理由でデータを変換することをエンコード (encode)といい、元に戻すことをデコード (decode)といいます。
ネチケットガイドライン (RFC1855)では、50キロバイトよりも大きいファイルは送るべきでないとされています。
RFC2821では、(ヘッダ等を含めて)少なくとも64キロオクテットのメッセージを送受信出来なければならないとされています。
アーカイブを元に戻すことは、展開、抽出、解除、リストア等、様々な呼ばれ方をします。
アーカイバの中には、圧縮/伸長の機能も同時に持っているものが多くあります。だから、アーカイブ/展開と圧縮/伸長という言葉が混同されて使われていることがあります。
更に、圧縮/圧縮解除とか冷凍/解凍とか凍結/解凍という言葉も使われています。
圧縮形式には色々ありますが、古い形式よりは新しい方式の方がちょっとだけ圧縮率が高い傾向があります。でもまあ、似たりよったりかもしれません。どんなデータを圧縮するかによっても、一長一短です。
複数のファイルを扱う場合、それぞれ圧縮してからアーカイブする(LZH、ZIP等)よりも、アーカイブしてから圧縮する(tarとgzipの組合せ等)の方が圧縮率が高い傾向があります。
一部の画像ファイル(gif、jpeg、png)や動画ファイル(mpeg)等は、圧縮してもあまり小さくなりません。最初から圧縮された形式だからです。
uuencodeやBinHexはコンピュータによっては問題があるので、MIMEのbase64を使おうという話は、RFC2045の6.8節あたりに記載されています。
パソコン通信内部とかイントラネットの場合、簡単にバイナリデータを送受信出来るものがあるらしいです。しかし実は独自形式の事が多く、インターネットとの間では失敗するかもしれません。
それぞれの管理者に問い合わせてください。