メールコンテンツを送信する際には、「ContentTransferEncoding」ヘッダーを設定する必要があります。私は受け取った電子メールの多くのヘッダーを観察しました。「7bit」を使用しているメールもあれば、「8bit」を使用しているメールもあります。

これら2つの違いは何ですか？どちらがお勧めですか？これらのヘッダーを設定するためにメール本文に必要な特別なエンコードはありますか？

読むのは少し密度が高いかもしれませんが、RFC1341の「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文字が含まれている可能性があります。8番目（最高）のビットを使用して、標準のUS-ASCII7ビット文字以外の特殊文字を示している可能性があります。」と同様に7bit、1000文字の行制限があります。

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

これ7bitは、コンテンツの自由度を高めるため、からのステップアップのようです。ただし、RFC1341には次のヒントが含まれています。

このドキュメントの発行時点では、エンコードされていない8ビットまたはバイナリデータをメール本文に含めることが正当な標準化されたインターネットトランスポートはありません。したがって、「8ビット」または「バイナリ」のContent-Transfer-Encodingが実際にインターネット上で合法であるという状況はありません。

RFC1341は20年以上前に発表されました。それ以来、RFC6152で8ビットのMIME拡張機能を取得しています。ただし、それでも、回線制限が適用される場合があります。

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

バイナリエンコーディング

binary8bit行の長さの制限がないことを除いて、はと同じです。必要な文字を含めることができ、余分なエンコーディングはありません。同様に8bit、RFC 1341は、それが実際には正当なエンコーディング転送エンコーディングではないと述べています。RFC 3030は、これをBINARYMIME。で拡張しました。

引用された印刷可能

8BITMIME拡張機能の前に、7bitSMTPを介して送信できないコンテンツを送信する方法が必要でした。HTMLファイル（1000文字を超える行がある場合があります）および国際文字を含むファイルは、この良い例です。quoted-printable（RFC 1341のセクション5.1で定義される）符号化はこれを処理するように設計されています。それは2つのことをします：

• US-ASCII以外の文字をエスケープして、7ビット文字でのみ表現できるようにする方法を定義します。（短いバージョン：等号と2つの7ビット文字として表示されます。）
• 行が76文字以下であり、改行が特殊文字を使用して表されることを定義します（その後エスケープされます）。

Quoted Printableは、エスケープと短い行のために、7bitまたはよりも人間が読むのがはるかに困難8bitですが、可能なコンテンツのはるかに広い範囲をサポートします。

Base64エンコーディング

データの大部分が非テキスト（例：画像ファイル）の場合、多くのオプションはありません。7bitテーブルから外れています。8bitそして、binaryMIME拡張RFCの前にサポートされていないでした。quoted-printable動作しますが、実際には非効率的です（すべてのバイトは3文字で表されます）。

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

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