Beim Senden von E-Mail-Inhalten muss der Header "Content Transfer Encoding" festgelegt werden. Ich habe viele Header von E-Mails beobachtet, die ich erhalten habe. Einige E-Mails verwenden "7bit", andere "8bit".

Was ist der Unterschied zwischen diesen beiden? Welches wird empfohlen? Ist für den E-Mail-Text eine spezielle Codierung erforderlich, um diese Header festzulegen?

Das Lesen kann etwas dicht sein, aber der Abschnitt "Content-Transfer-Encoding" von RFC 1341 enthält alle Details:

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

Die Situation wird immer schlimmer. Hier ist meine Zusammenfassung:

Hintergrund

SMTP beschränkt Mail per Definition (RFC 821) auf Zeilen mit 1000 Zeichen zu je 7 Bit. Das bedeutet, dass für keines der Bytes, die Sie über die Pipe senden, das höchstwertige Bit ("höchste Ordnung") auf "1" gesetzt werden kann.

Der Inhalt, den wir senden möchten, wird dieser Einschränkung häufig nicht von Natur aus entsprechen. Stellen Sie sich eine Bilddatei oder eine Textdatei vor, die Unicode-Zeichen enthält: Für die Bytes dieser Dateien wird häufig das 8. Bit auf "1" gesetzt. SMTP erlaubt dies nicht, daher müssen Sie "Übertragungscodierung" verwenden, um zu beschreiben, wie Sie die Nichtübereinstimmung umgangen haben.

Die Werte für den Content-Transfer-EncodingHeader beschreiben die Regel, die Sie zur Lösung dieses Problems ausgewählt haben.

7Bit-Codierung

7bitbedeutet einfach "Meine Daten bestehen nur aus US-ASCII-Zeichen, die nur die unteren 7 Bits für jedes Zeichen verwenden." Grundsätzlich garantieren Sie, dass alle Bytes in Ihrem Inhalt bereits den Einschränkungen von SMTP entsprechen und daher keiner besonderen Behandlung bedürfen. Sie können es einfach so lesen, wie es ist.

Beachten Sie, dass Sie bei Ihrer Auswahl damit 7biteinverstanden sind, dass alle Zeilen in Ihrem Inhalt weniger als 1000 Zeichen lang sind.

Solange Ihr Inhalt diesen Regeln entspricht, 7bitist dies die beste Übertragungscodierung, da keine zusätzliche Arbeit erforderlich ist. Sie lesen / schreiben nur die Bytes, wenn sie aus der Pipe kommen. Es ist auch einfach, 7bitInhalte zu betrachten und zu verstehen. Die Idee hier ist, dass es Ihnen gut geht, wenn Sie nur in "einfachem englischen Text" schreiben. Aber das war 2005 nicht wahr und es ist heute nicht wahr.

8-Bit-Codierung

8bitbedeutet "Meine Daten können erweiterte ASCII-Zeichen enthalten; sie können das 8. (höchste) Bit verwenden, um Sonderzeichen außerhalb der Standard-US-ASCII-7-Bit-Zeichen anzugeben." Wie bei 7bitgibt es immer noch ein Zeilenlimit von 1000 Zeichen.

8bitGenauso wie 7bites tatsächlich keine Transformation der Bytes durchführt, wenn sie in den Draht geschrieben oder von diesem gelesen werden. Es bedeutet nur, dass Sie nicht garantieren, dass für keines der Bytes das höchste Bit auf "1" gesetzt ist.

Dies scheint ein Schritt nach oben zu sein 7bit, da Sie dadurch mehr Freiheit in Ihren Inhalten haben. RFC 1341 enthält jedoch diesen Leckerbissen:

Zum Zeitpunkt der Veröffentlichung dieses Dokuments gibt es keine standardisierten Internet-Transporte, für die es legitim ist, nicht codierte 8-Bit- oder Binärdaten in Mail-Körpern aufzunehmen. Somit gibt es keine Umstände, unter denen die "8-Bit" - oder "binäre" Inhaltsübertragungscodierung im Internet tatsächlich legal ist.

RFC 1341 kam vor über 20 Jahren heraus. Seitdem haben wir 8-Bit-MIME-Erweiterungen in RFC 6152 erhalten . Aber selbst dann können noch Zeilenbeschränkungen gelten:

Beachten Sie, dass diese Erweiterung NICHT die Möglichkeit ausschließt, dass ein SMTP-Server die Leitungslänge begrenzt. Server können diese Erweiterung frei implementieren, legen jedoch eine Zeilenlängenbeschränkung von nicht weniger als 1000 Oktetten fest.

Binäre Codierung

binaryist dasselbe wie 8bit, außer dass es keine Einschränkung der Zeilenlänge gibt. Sie können weiterhin beliebige Zeichen einfügen, und es gibt keine zusätzliche Codierung. Ähnlich wie in 8bitRFC 1341 heißt es, dass es sich nicht wirklich um eine legitime Codierung handelt. RFC 3030 erweiterte dies mit BINARYMIME.

Zitiert zum Ausdrucken

Vor der 8BITMIMEErweiterung musste es eine Möglichkeit geben, Inhalte zu senden, die nicht 7bitüber SMTP übertragen werden konnten. HTML-Dateien (die möglicherweise mehr als 1000 Zeichen enthalten) und Dateien mit internationalen Zeichen sind gute Beispiele dafür. Die quoted-printableCodierung (definiert in Abschnitt 5.1 von RFC 1341) ist dafür ausgelegt. Es macht zwei Dinge:

• Definiert, wie Nicht-US-ASCII-Zeichen maskiert werden sollen, damit sie nur in 7-Bit-Zeichen dargestellt werden können. (Kurzfassung: Sie werden als Gleichheitszeichen plus zwei 7-Bit-Zeichen angezeigt.)
• Definiert, dass Zeilen nicht größer als 76 Zeichen sein dürfen und dass Zeilenumbrüche mit Sonderzeichen dargestellt werden (die dann maskiert werden).

Zitiert Druckbar ist aufgrund der Flucht und der kurzen Zeilen für einen Menschen viel schwieriger zu lesen als 7bitoder 8bit, unterstützt jedoch ein viel breiteres Spektrum möglicher Inhalte.

Base64-Codierung

Wenn Ihre Daten größtenteils nicht aus Text bestehen (z. B. eine Bilddatei), haben Sie nicht viele Optionen. 7bitist vom Tisch. 8bitund binarywurden vor den MIME-Erweiterungs-RFCs nicht unterstützt. quoted-printablewürde funktionieren, ist aber wirklich ineffizient (jedes Byte wird durch 3 Zeichen dargestellt).

base64ist eine gute Lösung für diese Art von Daten. Es codiert 3 Rohbytes als 4 US-ASCII-Zeichen, was relativ effizient ist. RFC 1341 begrenzt die Zeilenlänge von base64-codierten Daten weiter auf 76 Zeichen, um in eine SMTP-Nachricht zu passen. Dies ist jedoch relativ einfach zu verwalten, wenn Sie nur beliebige Zeichen mit fester Länge teilen oder verketten.

Der große Nachteil ist, dass base64-kodierte Daten für Menschen so gut wie nicht lesbar sind, selbst wenn es sich nur um "einfachen" Text darunter handelt.