ただのテキストの文章をメールで送るのは、文字コード等の設定や使えない文字に気を付ければ良いわけでしたが、バイナリはもっと慎重に考えてください。
ワープロソフトとか表計算ソフトというものに、インターネット標準(STD)は存在しません。
相手が扱えないデータを送っても無駄です。先に確認をとってください。
そもそも、受信者側がバイナリデータが扱えない事もあります。例えば、携帯電話です。
インターネットメールでは、バイナリデータをそのまま送信出来ません。理由は2つです。
元のファイル -> テキスト変換して添付する -> 送信 元のファイル <- 取り出してバイナリに戻す <- 受信
色々な方式があり、マシンやソフトによって対応がまちまちです。
対応してないソフトの場合、わけのわからん文字がズラズラ並びますが、目で見ればどの方式なのか見当が付きます。自分でツールを使って元に戻してください。
最近はbase64を勧めているケースを多く見かけますが、受信者がどれを扱えるかわかりませんから、先に聞いておきましょう。
マシンやソフトによってバイナリデータを送受信する手続きは様々ですし、表示のされ方も様々です。このページで雰囲気を掴みましょう。
実際には様々なバリエーションがあり、元に戻すのに失敗するケースも少なくありません。
[12] トラブル対処法を参考にしたり、ツールを沢山用意して、頭をひねってください。
略してuuとかuueということもある様です。
インターネットメールでは昔から使われています。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= "xxx"」で、区切りを示します。
本文の「--xxx」がそれぞれの部分を分割し、「--xxx--」で終了します。
使う文字は
「ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/」
です。最後に「=」が1つか2つ付く場合もあります。
この例ではrenraku.gzというファイル名が付いていますが、もともとデータを送受信する方法ですから、ファイル名が付いていないこともあります。
「name=」にファイル名を付けているのは古い形式なので禁止されています。現在は「Content-Disposition:」の「filename=」の方に付ける事になっています。
先頭の方に「This is a multi-part message in MIME format.」みたいな文章が付いている場合がありますが、本文であるにも関わらず表示されない場合があります。「---xxx」で区切っていないからです。受信者への挨拶等は「Content-Type: text/plain」のところに書き込まれます。
+」と「-」だけなので区別が付くでしょう。
様々な理由により、ファイル名には沢山の制限があります。
結論から書くと、ASCIIのみを使い、なるべく短くするのが無難です。そうでないと、色々なトラブルが起きます。
だいたい、次のような感じでしょうか。
△ やあ元気.JPG△ HEY YOU.JPG△ HEYYOU.JPEG△ HEY.YOU.JPG△ HEYYOUHELLO.JPG○ HEYYOU.JPG○ heyyou.jpg○ HeyYou.JPG理由は沢山ありますが、分類すると次のようになります。これらを全部クリアしないと、日本語ファイル名や長いファイル名は安心出来ません。
必ずしも日本語ファイル名が扱えるとは限りません。
英語版DOS、英語版MacOS、英語版Windows等に日本語化キットのようなものを追加して日本語メールを使っている人もいます。こういう場合は日本語文章の読み書きは出来ても、ファイル名では使えない事があります。UNIX系も似た傾向があります。
文字数制限も様々です。
UNIXはかなり長い文字数が使える事が多いのですが、MacOSは31字までです。DOSやWindows3.1以前は「8文字」+「点」+「3文字」までです。大抵、日本語の1文字はASCIIの2文字分と数えます。
大文字/小文字の区別も様々です。
「abc.txt」と「ABC.TXT」と「AbC.tXt」があった場合、UNIX系は別のファイルとして扱います。
DOS、MacOS、OS/2、Windows等は同じものとして扱います。
日本語メールは読み書き出来ても、日本語ファイル名は使えないメールソフトがあります。
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節あたりに記載されています。
パソコン通信内部とかイントラネットの場合、簡単にバイナリデータを送受信出来るものがあるらしいです。しかし実は独自形式の事が多く、インターネットとの間では失敗するかもしれません。
それぞれの管理者に問い合わせてください。