コンテンツ転送エンコード7ビットまたは8ビット
メールコンテンツを送信する際、「コンテンツ転送エンコーディング」ヘッダーを設定する必要があります。受け取ったメールのヘッダーを多数観察しました。 「7bit」を使用しているメールと「8bit」を使用しているメールがあります。
これら2つの違いは何ですか？どちらがお勧めですか？これらのヘッダーを設定するために、メール本文に特別なエンコードが必要ですか？
少し読みにくい場合がありますが、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文字が含まれる可能性があります。8番目（最上位）ビットを使用して、標準US-ASCII 7ビット文字以外の特殊文字を示すことができます」 7bitと同様に、1000文字の行制限がまだあります。
8bitは、7bitと同様に、実際にバイトがワイヤに書き込まれたり、ワイヤから読み取られたりするときに、バイトの変換を行いません。これは、どのバイトも最上位ビットが「1」に設定されないことを保証していないことを意味します。
これは7bitからのステップアップのように思えます。コンテンツの自由度が高まるからです。ただし、RFC 1341には次の情報が含まれています。
このドキュメントの公開時点では、メール本文にエンコードされていない8ビットまたはバイナリデータを含めることが正当な標準化されたインターネットトランスポートはありません。したがって、「8ビット」または「バイナリ」のContent-Transfer-Encodingがインターネット上で実際に合法である状況はありません。
RFC 1341は20年以上前に発表されました。それ以来、 8bit MIME Extensions in RFC 6152 を取得しました。ただし、それでも行の制限が適用される場合があります。
この拡張は、SMTPサーバーが行の長さを制限する可能性を排除しないことに注意してください。サーバーはこの拡張を自由に実装できますが、それでも1000オクテット以上の回線長制限を設定します。
バイナリエンコーディング
binaryは8bitと同じですが、行の長さの制限がない点が異なります。引き続き任意の文字を含めることができ、余分なエンコードはありません。 8bitと同様に、RFC 1341は、それが実際には正当なエンコード転送エンコードではないと述べています。 RFC 30BINARYMIMEでこれを拡張しました。
Quoted Printable
8BITMIME拡張の前に、SMTPで7bitにできないコンテンツを送信する方法が必要でした。 HTMLファイル（1000文字を超える行がある場合があります）および国際文字を含むファイルは、この良い例です。 quoted-printableエンコーディング（RFC 1341のセクション5.1で定義）は、これを処理するように設計されています。次の2つのことを行います。
- 7ビット文字のみで表現できるように、非US-ASCII文字をエスケープする方法を定義します。 （短いバージョン：等号と2つの7ビット文字として表示されます。）
- 行が76文字以下であり、改行が特殊文字を使用して表されることを定義します（特殊文字はエスケープされます）。
Quoted Printableは、エスケープと短い行のため、7bitまたは8bitよりも人間が読むのがはるかに困難ですが、可能なコンテンツの範囲がはるかに広くなっています。
Base64エンコーディング
データの大部分が非テキスト（例：画像ファイル）である場合、多くのオプションはありません。 7bitはテーブルから外れています。 8bitおよびbinaryは、MIME拡張RFCの前はサポートされていませんでした。 quoted-printableは機能しますが、実際には非効率的です（各バイトは3文字で表されます）。
base64は、このタイプのデータに適したソリューションです。 3つの未加工バイトを4つのUS-ASCII文字としてエンコードしますが、これは比較的効率的です。 RFC 1341は、base64- encodedデータの行の長さをSMTPメッセージ内に収まるように76文字にさらに制限していますが、固定長で任意の文字を分割または連結するだけの場合は、比較的簡単に管理できます。
大きな欠点は、base64でエンコードされたデータは、たとえその下にある「プレーン」テキストであっても、人間にはほとんど読めないことです。