Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
[10] バイナリデータの送受信 - インターネットメールの注意点
[go: Go Back, main page]

[10] バイナリデータの送受信


ただのテキストの文章をメールで送るのは、文字コード等の設定使えない文字に気を付ければ良いわけでしたが、バイナリもっと慎重に考えてください

ワープロソフトとか表計算ソフトというものに、インターネット標準(STD)は存在しません
相手が扱えないデータを送っても無駄です。先に確認をとってください


[10.1] どうやって送受信するのさ

インターネットメールでは、バイナリデータをそのまま送信出来ません。理由は2つです。

そこでバイナリテキストに変換してから送ります。

元のファイル -> テキスト変換して添付する -> 送信
元のファイル <- 取り出してバイナリに戻す <- 受信

色々な方式があり、マシンやソフトによって対応がまちまちです。

対応してないソフトの場合、わけのわからん文字がズラズラ並びますが、目で見ればどの方式なのか見当が付きます。自分でツールを使って元に戻してください。

最近はbase64を勧めているケースを多く見かけますが、受信者がどれを扱えるかわかりませんから、先に聞いておきましょう。


[10.2] 実際はこうなってます

マシンやソフトによってバイナリデータを送受信する手続きは様々ですし、表示のされ方も様々です。このページで雰囲気を掴みましょう。
実際には様々なバリエーションがあり、元に戻すのに失敗するケースも少なくありません。
[12] トラブル対処法を参考にしたり、ツールを沢山用意して、頭をひねってください。

[10.2.1] uuencode

略してuuとかuueということもある様です。
インターネットメールでは昔から使われています。uuencode/uudecodeというツールで変換します。メールの文中に変換した文字列をくっつけます。

[uuencode見本図]

begin 3桁数字 ファイル名」で始まって「end」で終わるのが目印です。
行頭の文字がだいたい揃っているのが特徴です。一般的には「M」です。
この例だと、元に戻すとrenraku.gzというファイルが出てきます。3桁数字はUNIXでのファイル属性を示すものなので、他のマシンではあまり関係ないでしょう。

使う文字は
`!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
ですが、「`」の代わりに「 」つまりスペースを使う場合もあります。希に亜流のuuencodeがあって、別の文字を使っている場合もあります。たとえば、下で紹介しているxxencodeもuuencodeの亜流と言えます。

[10.2.2] BinHex

送受信ともにMacOSである場合はBinHex形式が好まれていますが、他のコンピュータでは滅多に使いません。

[BinHex見本図]

(This file must be converted with BinHex 4.0) というのが目印です。 「:」で始まって、「:」で終わります。

使う文字は
!"#$%&'()*+,-012345689@ABCDEFGHIJKLMNPQRSTUVXYZ[`abcdefhijklmpqr
です。
この状態ではファイル名が見えないので、実際に元に戻してみないと判りませんね。これを扱うときは、MacOSのファイル形式の知識が必要かも知れません。

[10.2.3] MIME の base64

最近のメールソフトの「ファイルの添付」という様な機能は、MIMEのbase64を使っている場合が増えてきました。メールソフト上では表示されないことがありますが、実は次のような謎の文字列がくっついています。

[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」のところに書き込まれます。

[10.2.4] その他


[10.3] ファイルの名前は制限が多い

送信するファイル名に日本語やスペースを混ぜるのは止めたほうが無難です。
インターネットの決まりとしては、ファイル名の制限はあまりないのですが、受信側のコンピュータに制限があるかもしれません。
だから、元に戻すときに失敗するかもしれません。

△ やあ元気.JPG
日本語のファイル名が扱えないコンピュータがあります。MIMEではASCII以外のファイル名の扱いが難しく、失敗するケースが多いです。uuencodeやBinHexだとしても、扱えないソフトがあります。
△ HEY YOU.JPG
スペース混じりのファイル名が扱えないコンピュータがあります。
△ HeyYou.JPG
大文字と小文字の区別が付かないコンピュータがあります。
△ HEYYOU.JPEG
3字を越える拡張子が扱えないコンピュータがあります。
△ HEY.YOU.JPG
拡張子が2つ以上あると扱えないコンピュータがあります。
△ HEYYOUHELLO.JPG
長いファイル名が扱えないコンピュータがあります。
○ HEYYOU.JPG
こういう感じが無難ですな。

[10.4] 巨大なデータは注意しよう

送信するデータの大きさを考えるとき、「何ページ分」「何枚分」「たてよこ何cm」という考え方は妥当ではありません。
データサイズが「何バイト」「何キロバイトなのかが重要です。
また、uuencode, BinHex, Base64等で変換したとき、元のサイズの4/3以上に膨れ上がる事も知っておいてください。

データサイズが大きいと、バイナリ -> テキスト変換した後の行数が長く長くなっているので問題が発生するかもしれません。

では、どの程度のサイズが限度なのかというと、実は断言出来ません。それぞれのメールサーバによって、まちまちの値に設定されているようですし、送受信するマシンやソフトに限界がある場合もあります。


[10.5] 圧縮/伸長とアーカイブ/展開

大きなデータを送らなければならない場合、予め圧縮しておくと、サイズが小さくなります。

元のデータ -> データを圧縮 -> テキスト変換して添付する -> 送信
元のデータ <- データを伸長 <- 取り出してバイナリに戻す <- 受信

あと、ファイルをまとめて保管しておく事をアーカイブ(archive)といい、その為のソフトをアーカイバ(archiver)といいます。これを使うと複数のファイルを一度に扱えて便利かも知れません。

複数のファイル -> アーカイブ -> テキスト変換して添付する -> 送信
複数のファイル <- 展開をする <- 取り出してバイナリに戻す <- 受信

圧縮方式やアーカイブ方式は色々あって、受信者がどれを扱えるかわからないので、先に確認してください。

もし化けた場合、元に戻す段階でエラーが出て、送受信等の問題が判明することもあります。

どうしても日本語ファイル名で送りたい場合、日本語対応のアーカイバを使うという方法があります。アーカイブ後のファイル名をASCIIのアルファベットにしておけばいいのです。ただし、受信者も日本語対応版を用意していなければなりません。lha, StuffIt, Compact Pro等は日本語対応版があります。zip, tar, compress, gzip, bzip2等は、難しいかもしれません。


[9] へ戻る <------> [11] へ進む

[補足] (暇なら読んでね)

[*] 事実上の標準(defacto standard)ソフト

「事実上の標準ソフト」という言葉を良く見かけますが、それがどの程度なのか怪しいです。
一つのソフトが全てのコンピュータで動くわけではないですから、標準ソフトを作ることは不可能でしょう。RFC等の文書も事実上の標準であり、更にその一部がインターネット標準(STD)となっていますが、「形式」を提案してるだけであって、ソフトを選定してるわけではありません。

[*] エンコード/デコード

テキストとかバイナリに関わらず、何らかの理由でデータを変換することをエンコード (encode)といい、元に戻すことをデコード (decode)といいます。

[*] 日本語ファイル名の制限

MIMEでASCII以外のファイル名が使えないという話は、RFC2183の「2.3 The Filename Parameter」に出てきます。
なぜか日本語のファイル名を使えてしまうマシンやソフトが結構ありますが、それぞれ独自の方法を使っているので受信側で元に戻せないケースは非常に多いです。
実は、RFC2231にASCII以外のファイル名を使う方法が書かれていますが、これに対応したマシンやソフトはまだ少ないので、事実上使えないものだと思っておいた方がいいと思います。
これに関してはインターネットメイルに関することのページに詳しい説明があります。

[*] サイズの制限

ネチケットガイドライン (RFC1855)では、50キロバイトよりも大きいファイルは送るべきでないとされています。
RFC1123では、メーラソフトウェアは(ヘッダ等を含めて)少なくとも64キロバイトのメッセージを送受信出来なければならないとされています。

[*] 圧縮/伸長の別の呼び方

アーカイブを元に戻すことは、展開とか抽出とか解除とか色々な呼ばれ方をします。
アーカイバの中には、圧縮/伸長の機能も同時に持っているものが多くあります。だから、アーカイブ/展開と圧縮/伸長という言葉が混同されて使われていることがあります。
更に、圧縮/圧縮解除とか冷凍/解凍とか凍結/解凍という言葉も使われています。

[*] 圧縮の度合

一部の画像ファイル(gif、jpeg)や動画ファイル(mpeg)等は、圧縮してもあまり小さくなりません。最初から圧縮された形式だからです。

[*] base64を使う根拠

uuencodeやBinHexはコンピュータによっては問題があるので、MIMEのbase64を使おうという話は、RFC2045の6.8節あたりに記載されています。

[*] パソコン通信やイントラネット

パソコン通信内部とかイントラネットの場合、簡単にバイナリデータを送受信出来るものがあるらしいです。しかし実は独自形式の事が多く、インターネットとの間では失敗するかもしれません。
それぞれの管理者に問い合わせてください。


[9] へ戻る <------> [11] へ進む

五十音順さくいん / アルファベット順さくいん / 数字順さくいん
目次へ

インターネットメールの注意点 - [10] バイナリファイルの送受信