Entwicklertools · Base64-Encoder und -Decoder
Warum E-Mail-Anhänge Base64 sind: MIME, 7-Bit-Transport und 76-Spaltenzeilen
· Hintergrund
base64 Kodierung
E-Mails wurden für 7-Bit-ASCII-Text erstellt und Anhänge mussten hindurchpassen. In diesem Beitrag wird nachgezeichnet, wie MIME Base64 übernommen hat, warum Zeilen mit 76 Zeichen umbrochen werden und was das für Größe und Debugging bedeutet.
Der über ein altes Relay eingegangene Anhang ist beschädigt – das 8-Bit-Problem, zu dessen Lösung MIME erfunden wurde
E-Mail wurde in den 1970er und 1980er Jahren nur für 7-Bit-ASCII-Text entwickelt. SMTP, das Protokoll, das E-Mails überträgt, erwartet, dass jede Zeile höchstens 998 Zeichen von 7-Bit-ASCII enthält (Zeichen 0-127). Das Senden einer Binärdatei wie PDF oder eines Bildes direkt über SMTP würde fehlschlagen: Die Bytes 128-255 würden beschädigt oder von alten Mailservern und Relays abgelehnt. Anhänge müssen kodiert werden. MIME (Multipurpose Internet Mail Extensions, RFC 2045) löste dieses Problem durch die Definition von Content-Transfer-Encoding-Headerwerten, einschließlich Base64, das jede Bytesequenz als 7-Bit-ASCII-Text darstellt.
MIME bietet mehrere Optionen für die Content-Transfer-Codierung: 7 Bit (keine Codierung, nur für sicheres ASCII), 8 Bit (für Server, die 8-Bit-Bytes unterstützen, nicht universell), quoted-printable (codiert nur nicht sichere Bytes, sodass ASCII lesbar bleibt) und base64 (codiert alles, maximiert die Kompatibilität). Base64 wurde für binäre Anhänge ausgewählt, weil es einfach und standardisiert ist und Sicherheit auf jedem Mailsystem garantiert, egal wie alt oder streng 7-bit-only. Der Kompromiss ist die Größe: Base64 ist etwa ein Drittel größer als die ursprünglichen Bytes.
Das Transportproblem, das Base64 löst – die Darstellung beliebiger Bytes mit druckbaren Zeichen
Ein 3 KB PDF wird ungefähr zu 4 KB Base64-Text. Die Beschränkung auf 76-Zeichenzeilen stammt aus RFC 2045.
SMTP erlaubt Zeilen mit bis zu 998 Zeichen, aber ältere Mailsysteme und einige Spamfilter lehnen lange Zeilen ab. RFC 2045 gibt an, dass MIME Base64-Zeilen nicht länger als 76 Zeichen (plus ein CRLF-Zeilenende) sein dürfen, damit ein Mailserver den Transport niemals unterbricht. Die Grenze ist nicht magisch; Es handelt sich um einen historischen Kompromiss zwischen Lesbarkeit (76 Zeichen passen auf die meisten Terminals der 1980er Jahre), Kompatibilität mit alten Systemen und der Vermeidung der Erkennung als Spam- oder Virenmuster.
Die in diesem Tool sichtbaren Ausgabeoptionen – kanonisches Auffüllen und optionaler 76-Zeichenumbruch
Moderne Mailsysteme unterstützen normalerweise längere Zeilen, aber die Kodierung in 76-Zeichenzeilen stellt sicher, dass der Anhang auch den ältesten Empfänger erreicht. Nachdem RFC 2045 MIME Base64 definiert hatte, fügten RFC 4288 (Medientypen) und RFC 2183 (Content-Disposition) standardisierte Möglichkeiten zur Kennzeichnung von Anhängen hinzu. Eine Nachricht mit einem PDF-Anhang enthält einen Content-Transfer-Encoding: base64-Header, einen Content-Type: application/pdf-Header und die PDF Bytes, die als Base64 mit 76-Zeichenzeilen codiert sind. Ein Mail-Reader dekodiert die Zeilen, indem er die Zeilenumbrüche (CRLF-Zeichen) entfernt und dann Base64 dekodiert, um die ursprünglichen Bytes wiederherzustellen.
Das Dekodieren eines MIME Base64-Anhangs erfordert das Ignorieren von Leerzeichen. Der RFC sagt: Decoder müssen beim Decodieren Zeilenumbrüche (CR- und LF-Zeichen) überspringen. Aus diesem Grund ist ein Base64-Decoder praktisch, der Leerzeichen akzeptiert. Die meisten echten MIME-Mails haben Zeilenumbrüche. Einige Decoder sind streng und lehnen Leerzeichen ab (geeignet für Kontexte wie JWT, in denen keine Zeilenumbrüche vorhanden sein sollten), während andere nachsichtig sind und Leerzeichen überspringen (geeignet für MIME).
Die 76-Zeichenoption in der Praxis – wie der Encoder Zeilenumbrüche einfügt und Decoder ignoriert
Das Base64-Encoder- und Decoder-Tool kann beides verarbeiten: Es akzeptiert einen mehrzeiligen eingefügten Anhang und ignoriert die Zeilenumbrüche während der Dekodierung. Die Auswirkungen auf die Größe sind vorhersehbar. RFC 2045 Base64 Wrapping fügt ein CRLF (2 Bytes) pro 76 Zeichen der Ausgabe hinzu. Für eine 10 KB-Datei beträgt Base64 ungefähr 13.3 KB, plus CRLF alle 76 Zeichen: insgesamt etwa 13.5 KB. Der Overhead beträgt etwa ein Drittel mehr Bytes.
E-Mail-Größenbeschränkungen werden normalerweise für die codierte Größe angegeben, nicht für die ursprüngliche Dateigröße; Ein Mailserver mit einem 25 MB-Limit bedeutet 25 MB der verschlüsselten Nachricht, nicht 25 MB der Anhänge. Zur Berechnung der ursprünglichen Dateigröße muss durch 1.33 dividiert werden (genauer gesagt durch 4 dividiert durch 3). Die Quoted-Printable-Codierung ist eine Alternative, die druckbares ASCII unverändert lässt und nur die Bytes 128-255 und einige Sonderzeichen codiert.
Arbeitsbeispiel: Lesen einer Rohnachrichtenquelle – Finden des Base64-Teils und Dekodieren eines kleinen Textanhangs
Eine Textdatei, die hauptsächlich aus ASCII besteht, bleibt lesbar, wenn Sie die Rohnachrichtenquelle öffnen. Base64 verschleiert alles, sogar einfachen ASCII-Text. Quoted-printable wird selten für Binärdateien verwendet (für PDF wäre es sehr ineffizient), wird aber manchmal für Text verwendet. Ein E-Mail-Reader wählt die Kodierung basierend auf dem Anhangstyp; Ein Browser fragt den Benutzer normalerweise nicht, welche Codierung angewendet werden soll.
Der Base64-Text einer E-Mail-Nachricht besteht nur aus den Bytes selbst, nicht aus einer separaten Datei. Wenn Sie in einem E-Mail-Reader einen Anhang sehen, hat der Reader bereits Base64 dekodiert und zeigt die Originaldatei an.
Die Größenkosten in der Praxis – etwa ein Drittel mehr Bytes, und warum für die codierte Größe Grenzwerte für die E-Mail-Größe angegeben werden
Wenn Sie die Rohnachrichtenquelle anzeigen (eine Option in den meisten E-Mail-Clients), sehen Sie die MIME-Header und den Base64-codierten Text. Das Base64-Encoder- und Decoder-Tool kann Ihnen dabei helfen, ein Fragment einer Nachrichtenquelle manuell zu dekodieren. Kopieren Sie den Base64-Teil, entfernen Sie Zeilenumbrüche und fügen Sie ihn in das Tool ein.
Mehrere Anhänge in einer MIME-Nachricht verwenden eine mehrteilige Grenze. Jeder Teil hat seine eigenen Header (Content-Type, Content-Transfer-Encoding) und seinen eigenen Text. Eine alternative Klartextversion der Nachricht wird als ein Teil angezeigt, und jeder Anhang wird als ein anderer Teil angezeigt. Die Grenzzeichenfolge trennt die Teile; Es ist so gewählt, dass es im Inhalt keines Teils erscheint. Ein E-Mail-Reader rekonstruiert die Nachricht, indem er die Grenzen analysiert und jeden Teil entsprechend seinem Content-Transfer-Encoding-Header dekodiert.
Was dies nicht abdeckt – Header mit codierten Wörtern, S/MIME und die 8BITMIME-Erweiterung im Detail
RFC 2045 Die Base64-Kodierung ist heute nicht universell. Einige Mailsysteme unterstützen den 8-Bit-Transport und erfordern kein Base64 mehr. Einige Systeme verwenden andere Codierungsnamen oder fügen benutzerdefinierte Header hinzu. Aber Base64 mit 76-Zeichenzeilen bleibt die kompatibelste Wahl für Anhänge, die jedes Mailsystem überall erreichen müssen. Wenn Sie eine Datei mit einem E-Mail-Client anhängen, wählt der Client normalerweise automatisch Base64 für Binärdateien, kümmert sich um den Zeilenumbruch und fügt die MIME-Header hinzu.
Das Verständnis des Mechanismus hilft Ihnen beim Debuggen, wenn ein Anhang beschädigt zu sein scheint oder wenn Sie manuell mit einer Nachrichtenquelle arbeiten. Das Erstellen oder Parsen einer ausgehenden E-Mail-Nachricht erfordert ein Verständnis der MIME-Struktur. Eine Bibliothek sollte die Codierung, den Zeilenumbruch und die Header übernehmen; Normalerweise erstellen Sie MIME nicht manuell. Wenn Sie jedoch eine Rohnachrichtenquelle analysieren (ein Übermittlungsproblem beheben oder Anhänge programmgesteuert extrahieren), können Sie mit dem Wissen, dass Content-Transfer-Encoding: base64 bedeutet, dass der folgende Text mit 76-Zeichen umschlossen ist, base64 den richtigen Decoder anwenden.
Fazit: Base64 ist die Kompatibilitätsebene von E-Mails – wie Sie mit dem Base64-Encoder und -Decoder einen kleinen Textteil aus einer Rohnachricht lokal lesen können
Das Base64 selbst ist Standard-RFC 4648; Die Wrapping- und MIME-Header sind spezifisch für E-Mails. E-Mail-Anhänge sind Base64, da E-Mails für einfachen Text erstellt wurden und Base64 die einfachste und universellste Kompatibilitätsebene zum Senden von Binärdaten über ein Nur-Text-Protokoll ist. Die Zeilenbeschränkung auf 76 ist ein historisches Artefakt der Terminals und langsamen Netzwerke der 1980er Jahre, gilt aber weiterhin als Standard für die Kompatibilität.
Das Verständnis dieser Geschichte erklärt, warum MIME existiert, warum es mehrere Kodierungsoptionen gibt und warum Base64 die Standardeinstellung für Anhänge bleibt, obwohl moderne Mailsysteme Binärdateien direkt unterstützen könnten. Mit dem Base64-Encoder und -Decoder können Sie manuell mit MIME-Körpern arbeiten, um die Codierung zu überprüfen oder zu debuggen.