電子メールのサイズが添付ファイルのサイズよりも3分の1大きいのはなぜですか。
私のメールにデータを添付するとき、私はThunderbirdが私が添付したファイルよりはるかに大きい結果のEメールの合計サイズを計算することに気づきました。
これが最近の例です。13MBの画像と3.6MBの画像の合計2つの画像は、合計で約17MBになります。 4行のテキストがありました。 Thunderbirdが私に、合計サイズ22MBのEメールを本当に送信したいのかと尋ねました。
その違いはどこから来ているのでしょうか。 5MBのテキストは少し聞こえるようです。
あなたのデータは17 MiBでした。 MiBには1024 KiBがあります。 KiBには1024 Bがあります。 1バイトに8ビットあります。つまり142,606,336ビットです。
Base 64エンコーディングは、6ビットごとに別々のバイトとしてエンコードします。したがって、約23,767,722バイトが必要です。 1024で2回割ると、22.67 MiBになります。それで、22 MiBが由来します。
電子メールはかなり古い技術であり、8ビットのクリーンパイプを想定していません。
電子メールが大きいのはなぜですか。
なぜなら、データは4バイトの印刷可能ASCII文字のグループとして最大3バイトのグループをエンコードするbase64でエンコードされているからです。通常、これらの印刷可能文字のグループは行に分割されます。
その結果、エンコードされたデータは元のデータのサイズのちょうど1/3倍を超えます。
なぜbase64が使われているのですか？
電子メールは長い歴史があり、もともとテキストを運ぶように設計されていました。 ASCII印刷可能文字を表すbyte値だけが、世界中のさまざまな電子メールシステムを確実に通過できます。
そのため、MIMEは他のデータをASCII textとしてエンコードするための2つの方式を分割しました - 「quoted-printable」はほとんどASCII text用に設計されています。
SMTPプロトコルには、これらの制限を試すための拡張機能があります。まず、1994年の8BITMIMEは、より高いオクテット値を許可していましたが、残念ながら行の長さと行末に関連する制限を削除していなかったため、任意のバイナリデータには適していませんでした。そして1995年にはBINARYMIMEによって、任意のバイナリデータを含むメッセージの転送が可能になりました。
ただし、これらの規格では広く採用されていません。 1つの問題は、メールチェーンの1つのホップがそれらをサポートしていても、次のホップがサポートしていないとどうなるでしょうか。メールサーバーはそのままではメールを送信できません。配信不能として拒否してバウンスするか（ユーザーには受け入れられないでしょう）、または変換します（メールサーバーにかなりの追加コードが必要です）。 。マルチパートタイプでコンテンツ転送エンコーディングを使用しないことに関するMIMEルールでは、変換は特に面倒です。