読むのは少し難しいかもしれませんが、RFC 1341 の「Content-Transfer-Encoding」セクションにすべての詳細が記載されています。

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

状況は悪化の一途をたどっています。私の要約は次のとおりです。

背景

SMTP は定義 (RFC 821) により、メールを 7 ビットの 1000 文字の行に制限します。つまり、パイプを通じて送信するバイトのいずれにおいても、最上位 (「最上位」) ビットが「1」に設定されることはありません。

送信したいコンテンツは、本質的にこの制限に従わないことがよくあります。画像ファイルや Unicode 文字を含むテキスト ファイルを考えてみましょう。これらのファイルのバイトでは、8 番目のビットが「1」に設定されていることがよくあります。SMTP ではこれが許可されていないため、「転送エンコーディング」を使用して、不一致をどのように回避したかを説明する必要があります。

ヘッダーの値はContent-Transfer-Encoding、この問題を解決するために選択したルールを表します。

7ビットエンコーディング

7bitこれは単に「私のデータは US-ASCII 文字のみで構成されており、各文字に下位 7 ビットのみを使用します」という意味です。基本的に、コンテンツ内のすべてのバイトがすでに SMTP の制限に準拠していることが保証されるため、特別な処理は必要ありません。そのまま読み取ることができます。

を選択した場合7bit、コンテンツ内のすべての行の長さが 1000 文字未満であることに同意することになります。

コンテンツがこれらのルールに従っている限り、7bitこれは最良の転送エンコーディングです。余分な作業は必要なく、パイプから出てくるバイトを読み書きするだけです。また、7bitコンテンツを目視して理解するのも簡単です。ここでの考え方は、単に「平易な英語のテキスト」で書いているだけなら問題ないということです。しかし、2005年には真実ではなかったそしてそれは今日では真実ではない。

8ビットエンコーディング

8bitは、「データには拡張 ASCII 文字が含まれる場合があります。標準の US-ASCII 7 ビット文字以外の特殊文字を示すために、8 番目 (最高) のビットが使用される場合があります。」という意味です。 と同様に7bit、1000 文字の行制限は依然として存在します。

8bitは、 と同様に、7bitワイヤへの書き込みまたはワイヤからの読み取り時にバイトの変換を実際に行うわけではありません。つまり、どのバイトでも最上位ビットが「1」に設定されないことが保証されるわけではないということです。

7bitこれは、コンテンツの自由度が増すため、 よりも一歩進んだように思えます。ただし、RFC 1341 には次のような情報が含まれています。

この文書の発行時点では、エンコードされていない 8 ビットまたはバイナリ データをメール本文に含めることが正当である標準化されたインターネット トランスポートは存在しません。したがって、インターネット上で「8 ビット」または「バイナリ」のコンテンツ転送エンコーディングが実際に合法となる状況は存在しません。

RFC 1341は20年以上前に発表されました。それ以来、私たちは8ビットMIME拡張でRFC 6152ただし、その場合でも行制限が適用される場合があります。

この拡張機能は、SMTP サーバーが行の長さを制限する可能性を排除するものではないことに注意してください。サーバーはこの拡張機能を自由に実装できますが、それでも行の長さの制限は 1000 オクテット未満に設定されません。

バイナリエンコード

binaryは と同じですが8bit、行の長さの制限はありません。 必要な文字を何でも含めることができ、追加のエンコードはありません。 と同様に8bit、RFC 1341 では、これは実際には正当なエンコード転送エンコードではないと規定されています。RFC 3030これを で拡張しましたBINARYMIME。

引用印刷可能

拡張機能が導入される前は8BITMIME、SMTP 経由で送信できないコンテンツを送信する方法が必要でした7bit。HTML ファイル (1000 文字を超える行が含まれる場合があります) や国際文字を含むファイルは、この良い例です。エンコーディングquoted-printable(RFC 1341 のセクション 5.1 で定義) は、これを処理するために設計されています。エンコーディングは次の 2 つのことを行います。

• US-ASCII 以外の文字をエスケープして、7 ビット文字のみで表現する方法を定義します。(短縮版: 等号と 2 つの 7 ビット文字として表示されます。)
• 行の長さが 76 文字以下であること、および改行が特殊文字 (その後エスケープされる) を使用して表されることを定義します。

Quoted Printable は、エスケープと短い行のため、7bitやよりも人間が読み取るのが非常に困難です8bitが、サポートできるコンテンツの範囲ははるかに広くなります。

Base64 エンコーディング

データの大部分がテキスト以外の場合 (例: 画像ファイル)、選択肢はあまりありません。 は使用できません。また、7bitMIME8bit拡張binaryRFC 以前はサポートされていませんでした。quoted-printableは機能しますが、非常に非効率的です (すべてのバイトが 3 文字で表されます)。

base64は、このタイプのデータに適したソリューションです。3 つの生のバイトを 4 つの US-ASCII 文字としてエンコードするため、比較的効率的です。RFC 1341 では、base64エンコードされたデータの行の長さが SMTP メッセージに収まるように 76 文字までに制限されていますが、任意の文字を固定長で分割または連結するだけであれば、比較的簡単に管理できます。

大きな欠点は、base64エンコードされたデータは、たとえその中身が単なる「プレーン」テキストであっても、人間にはほとんど読み取れないことです。