なぜbase64が必要なのですか（別名バイナリファイルをメールで送信できないのはなぜですか）

私はBase64エンコーディングを読んでいて、ウィキペディアでこれを見つけました：

Base64エンコードスキームは、テキストデータを処理するように設計されたメディアで保存および転送する必要があるバイナリデータをエンコードする必要がある場合によく使用されます。

...そして、与えられた例は、バイナリファイルを電子メールで送信しています。

base64が必要な理由を理解しようとしています。バイナリデータは大量のバイトであるため、テキストデータであるASCIIに直接変換できませんか？なぜbase64が必要なのですか？または、電子メールにASCIIの制御文字に問題がありますか？

これに関するウィキペディアの良い記事があります。

ARPAnetで使用されているNCPの初期の反復は、バイトストリームよりもビットストリームに似ていたか、または便利なバイトサイズをネゴシエートしようとしました。8ビットバイトは、かなり後になって標準化されました。また、さまざまなマシンで機能するファイル転送プロトコルを作成しようとする試みもいくつかありました（メールは当初FTP コマンドの機能であり、主にMAILandMLFLコマンドとして使用され、その後MTPに分割され、後でSMTPになりました）。これらのマシンは、多くの場合、ASCIIとEBCDICの異なる文字エンコーディング、または異なるバイトサイズ（8ビットバイトと6ビットvs ...

したがって、メール転送機能は、比較的短いメッセージをプレーンテキストで転送するために最初に定義されました。具体的には、「NVT-ASCII」。たとえば、RFC 772は次のように述べています。

メールの表明と保管

メールは、送信ホストのストレージデバイスから受信ホストのストレージデバイスに転送されます。2つのシステムのデータストレージ表現が異なるため、メールに対して特定の変換を実行する必要がある場合があります。たとえば、NVT-ASCIIには、システムごとに異なるデータストレージ表現があります。PDP-10は通常、NVT-ASCIIを5つの7ビットASCII文字として36ビットワードで左揃えで保存します。360'sはNVT-ASCIIを32ビットワードの4つの8ビットEBCDICコードとして保存します。Multicsは、NVT-ASCIIを36ビットワードの4つの9ビット文字として保存します。

簡単にするために、すべてのデータはMTPでNVT-ASCIIとして表される必要があります。これは、送信ホストと受信ホストが類似しているかどうかに関係なく、テキストを送信するときに文字を標準NVT-ASCII表現に変換する必要があることを意味します。送信者は、データを内部の文字表現から標準の8ビットNVT-ASCII表現に変換します（TELNET仕様を参照）。受信者は、データを標準形式から独自の内部形式に変換します。この標準に従って、テキストの行の終わりを示すためにシーケンスを使用する必要があります。

8ビットが回線上で送信されていたとしても、それを保存する必要がないため、8ビット目はしばしば破棄またはマングルされます。実際、一部のプロトコルでは、8ビット目をゼロに設定する必要がありました。たとえば、以下に引用する最初のSMTP RFCなどです。言い換えれば、ソフトウェアは8ビットクリーンではありませんでした。

データ転送

TCP接続は、8ビットバイトの送信をサポートしています。SMTPデータは7ビットASCII文字です。各文字は、高位ビットがゼロにクリアされた8ビットバイトとして送信されます。

これは、8ビットのISO-8859-＃文字エンコードが広く普及した後も、長期間持続しました。一部のサーバーは既に8ビットクリーンでしたが、他の多くのサーバーはクリーンではなかったため、8ビットデータを盲目的に送信するとメッセージが破損していました。

後に、「拡張SMTP」が公開され、メールサーバーがサポートするSMTP拡張を宣言できるようになりました。それらの1つは8BITMIME、受信サーバーが8ビットデータを安全に受け入れることができることを示していました。MIMEメッセージ部分には「Content-Transfer-Encoding：8bit」を含めることができます。これは、それらが何らかの方法でエンコードされていないことを示します。

ただし、SMTPプロトコルは行ベースのままであり、998オクテットの行制限があり、.「メッセージの終わり」インジケータとして行（0D 0A 2E 0D 0A）を使用しています。これは、ほとんどのバイナリファイルを変更せずに送信できたとしても、このオクテットシーケンスを含むファイルが転送されたメッセージの終わりとして解釈され、残りのファイルがSMTPコマンドとして解釈され、損害を引き起こす可能性があることを意味します。同様に、998オクテットより長い「ライン」は、受信サーバーによって切断される可能性があります。

2000年に、「BINARYMIME」ESMTP拡張がRFC 3030として公開され、SMTP経由で生のバイナリデータを転送できるようになりました。メッセージは、ターミネーターとして長さゼロのチャンクを使用して、事前に指定された長さのチャンクで転送されるようになり、Base64および同様のエンコードは必要なくなりました。残念ながら、この拡張機能をサポートするSMTPサーバーはほとんどありません。たとえば、PostfixもExim4もCHUNKINGEHLOへの応答でアドバタイズしません。BINARYMIMEを利用するには、メッセージパス内のすべてのサーバーでサポートされている必要があります。これは、1つまたは2つ以上の場合があります。

こちらもご覧ください：

• RFC 765：ファイル転送プロトコル
• RFC 772：メール転送プロトコル
• RFC 821：簡易メール転送プロトコル
• ウィキペディア：8ビットクリーン
• ウィキペディア：8BITMIME

一部の古い電子メールシステムとソフトウェアは8ビットクリーンではなく、8番目のビットは制御文字として使用されていました。これはバイナリファイルを台無しにするのに十分であったため、Base64（または他のエンコードスキーム）が必要でした。