開発者ツール · Base64 エンコーダーおよびデコーダー
電子メールの添付ファイルが Base64 である理由: MIME、7 ビットのトランスポート、および 76 列行
· 背景
base64 エンコード
電子メールは 7 ビットの ASCII テキスト用に構築されており、添付ファイルはそれに適合する必要がありました。この投稿では、MIME がどのように Base64 を採用したか、行が 76 文字で折り返される理由、およびそれがサイズとデバッグに何を意味するかを追跡します。
古いリレー経由で到着した添付ファイルが壊れています — MIME が解決するために発明された 8 ビットの問題
電子メールは、1970 年代と 1980 年代に 7 ビットの ASCII テキストのみを対象として設計されました。電子メールを伝送するプロトコルである SMTP は、各行が最大 7 ビット ASCII の 998 文字 (0 ～ 127 文字) であることを想定しています。 PDF などのバイナリ ファイルや画像を SMTP 経由で直接送信すると失敗します。バイト 128 ～ 255 は破損するか、古いメール サーバーやリレーによって拒否されます。添付ファイルにはエンコードが必要です。 MIME (MultiPurpose Internet Mail Extensions、RFC 2045) は、任意のバイト シーケンスを 7 ビット ASCII テキストとして表す、base64 を含む Content-Transfer-Encoding ヘッダー値を定義することでこの問題を解決しました。
MIME には、いくつかの Content-Transfer-Encoding の選択肢があります。7 ビット (エンコードなし、安全な ASCII のみ)、8 ビット (8 ビット バイトをサポートするサーバー用、ユニバーサルではない)、quoted-printable (非安全なバイトのみをエンコードし、ASCII 読み取り可能を維持)、base64 (すべてをエンコードし、互換性を最大化)。 Base64 がバイナリ添付ファイルに選択されたのは、Base64 がシンプルで標準化されており、古さや厳密に 7 ビットのみであっても、あらゆるメール システムでの安全性が保証されるためです。トレードオフはサイズです。Base64 は元のバイトより約 3 分の 1 大きくなります。
Base64 が解決するトランスポート問題 — 印刷可能な文字で任意のバイトを表現する
A 3 KB PDF は、Base64 テキストのほぼ 4 KB になります。 76 文字行制限は、RFC 2045 に基づいています。
SMTP では 998 文字までの行を許可しますが、古いメール システムや一部のスパム フィルターでは長い行が拒否されます。 RFC 2045 では、MIME Base64 行が 76 文字 (および CRLF 行末尾) を超えてはいけないことを指定しているため、メール サーバーがトランスポートを中断することはありません。限界は魔法ではありません。これは、可読性 (76 文字は 1980 年代のほとんどの端末に適合します)、古いシステムとの互換性、スパムまたはウイルス パターンとしての検出の回避の間の歴史的な妥協点です。
このツールで表示される出力選択肢 - 正規のパディングとオプションの 76 文字の折り返し
最新のメール システムは通常、より長い行をサポートしていますが、76 文字行にエンコードすることで、添付ファイルが最も古い受信者にも確実に届くようになります。 RFC 2045 で MIME Base64 が定義された後、RFC 4288 (メディア タイプ) および RFC 2183 (Content-Disposition) で添付ファイルにラベルを付ける標準化された方法が追加されました。 PDF 添付ファイルを持つメッセージには、Content-Transfer-Encoding:base64 ヘッダー、Content-Type: application/pdf ヘッダー、および 76 文字行を含む Base64 としてエンコードされた PDF バイトが含まれます。メール リーダーは、改行 (CRLF 文字) を削除して行をデコードし、Base64 をデコードして元のバイトを復元します。
MIME Base64 添付ファイルをデコードするには、空白を無視する必要があります。 RFC には、デコーダはデコード中に改行 (CR および LF 文字) をスキップしなければならないと記載されています。これが、空白を受け入れる Base64 デコーダが実用的な理由です。実際の MIME メールのほとんどには改行が含まれます。一部のデコーダは厳密で空白を拒否します (改行が存在すべきではない JWT のようなコンテキストに適しています)。一方、他のデコーダは寛容で空白をスキップします (MIME に適しています)。
76 文字オプションの実際 - エンコーダーが改行を挿入し、デコーダーが改行を無視する方法
Base64 エンコーダおよびデコーダ ツールは両方を処理できます。複数行に貼り付けられた添付ファイルを受け入れ、デコード中に改行を無視します。サイズへの影響は予測可能です。 RFC 2045 Base64 ラッピングでは、出力の 76 文字ごとに 1 つの CRLF (2 バイト) が追加されます。 10 KB ファイルの場合、Base64 はおよそ 13.3 KB に、76 文字ごとの CRLF が加わり、合計で約 13.5 KB になります。オーバーヘッドは約 3 分の 1 バイト増加します。
電子メールのサイズ制限は、通常、元のファイルのサイズではなく、エンコードされたサイズに対して示されます。 25 MB 制限のあるメール サーバーは、添付ファイルの 25 MB ではなく、エンコードされたメッセージの 25 MB を意味します。元のファイル サイズを計算するには、1.33 (より正確には、4 を 3 で割ったもの) で割る必要があります。 Quoted-printable エンコーディングは、印刷可能な ASCII を変更せずに、128 ～ 255 バイトといくつかの特殊文字のみをエンコードする代替手段です。
作業例: 生のメッセージ ソースの読み取り — Base64 部分を見つけて小さなテキスト添付ファイルをデコードする
生のメッセージ ソースを開いた場合、大部分が ASCII で構成されるテキスト ファイルは引き続き読み取り可能です。 Base64 は、プレーンな ASCII テキストも含めてすべてを難読化します。 Quoted-printable はバイナリ・ファイルにはほとんど使用されません (PDF の場合は非常に非効率的です) が、テキストには時々使用されます。メール リーダーは、添付ファイルの種類に基づいてエンコードを選択します。通常、ブラウザはユーザーにどのエンコーディングを適用するかを尋ねません。
電子メール メッセージの Base64 本文は単なるバイトそのものであり、別個のファイルではありません。メール リーダーで添付ファイルが表示されると、リーダーは既に Base64 をデコードしており、元のファイルが表示されています。
実際のサイズコスト - およそ 3 分の 1 バイト増加、およびエンコードされたサイズに対してメール サイズ制限が規定されている理由
生のメッセージ ソース (ほとんどのメール クライアントのオプション) を表示すると、MIME ヘッダーと Base64 でエンコードされた本文が表示されます。 Base64 エンコーダおよびデコーダ ツールは、メッセージ ソースのフラグメントを手動でデコードするのに役立ちます。 Base64 部分をコピーし、改行を削除してツールに貼り付けます。
MIME メッセージ内の複数の添付ファイルはマルチパート境界を使用します。各部分には独自のヘッダー (Content-Type、Content-Transfer-Encoding) と本文があります。メッセージのプレーンテキストの代替バージョンが 1 つの部分として表示され、各添付ファイルは別の部分として表示されます。境界文字列はパーツを区切ります。どの部分のコンテンツにも表示されないように選択されています。メール リーダーは、境界を解析し、Content-Transfer-Encoding ヘッダーに従って各部分をデコードすることによってメッセージを再構築します。
これでカバーされないもの — エンコードされた単語ヘッダー、S/MIME、および 8BITMIME 拡張機能の詳細
RFC 2045 Base64 エンコードは現在では普遍的ではありません。一部のメール システムは 8 ビットのトランスポートをサポートしており、base64 は必要ありません。一部のシステムでは、異なるエンコーディング名を使用したり、カスタム ヘッダーを追加したりしています。ただし、76 文字行を含む Base64 は、メール システムのどこにでも送信する必要がある添付ファイルにとって、依然として最も互換性のある選択肢です。メール クライアントを使用してファイルを添付すると、クライアントは通常、バイナリ ファイルに対して Base64 を自動的に選択し、行の折り返しを処理し、MIME ヘッダーを追加します。
このメカニズムを理解すると、添付ファイルが破損していると思われる場合や、メッセージ ソースを手動で操作している場合のデバッグに役立ちます。送信電子メール メッセージを作成または解析するには、MIME 構造を理解する必要があります。ライブラリはエンコード、行の折り返し、ヘッダーを処理する必要があります。通常、MIME を手動で構築することはありません。ただし、生のメッセージ ソースを解析している場合 (配信の問題のデバッグ、またはプログラムによる添付ファイルの抽出)、Content-Transfer-Encoding: Base64 が次の本文が 76 文字でラップされた Base64 であることを知っていると、適切なデコーダーを適用できます。
要点: Base64 は電子メールの互換性レイヤーです — Base64 エンコーダーとデコーダーを使用して生のメッセージから小さなテキスト部分をローカルで読み取る方法
Base64 自体は標準 RFC 4648 です。ラッピングと MIME ヘッダーは電子メールに固有です。電子メールの添付ファイルは Base64 です。これは、電子メールがプレーン テキスト用に構築されており、base64 がテキストのみのプロトコルを通じてバイナリ データを送信するための最も単純で最も汎用的な互換性レイヤーであるためです。 76 文字行制限は、1980 年代の端末と低速ネットワークの歴史的な産物ですが、互換性のための標準として存続しています。
この歴史を理解すると、なぜ MIME が存在するのか、なぜ複数のエンコード オプションがあるのか、そして最新のメール システムがバイナリを直接サポートできるにもかかわらず、なぜ Base64 が添付ファイルのデフォルトのままなのかが説明されます。 Base64 エンコーダとデコーダを使用すると、MIME 本文を手動で操作してエンコードを検証またはデバッグできます。