Entwicklertools · Base64-Encoder und -Decoder
Eine kurze Geschichte von Base64: von uuencode und PEM bis zum heutigen Alphabet
· Hintergrund
base64 Kodierung
Das Alphabet von Base64 ist ein Fossilienbestand der Transportprobleme der 1980er Jahre. Dieser Beitrag folgt der Linie von uuencode über Privacy-Enhanced Mail bis hin zu MIME und RFC 4648 und erläutert jede Designauswahl.
Warum das Alphabet nicht einfach 0–63 in einer offensichtlichen Reihenfolge ist – die Frage, die vier Jahrzehnte zurückreicht
Base64 schien als Standard nicht vollständig ausgereift zu sein. Das Alphabet (A-Z, a-z, 0-9, +, /) ist ein Fossilienbestand jahrzehntelanger Codierungsexperimente, die alle das gleiche Problem zu lösen versuchen: wie Binärdaten als Text dargestellt werden können, der E-Mails, USENET und Unix-Tools der 1970er und 1980er Jahre überdauert. Die Geschichte umfasst UUencode unter Unix und Privacy-Enhanced Mail (RFC 1421) in 1993, MIME (RFC 2045) in 1996 und schließlich RFC 4648 in 2006, wobei alle Varianten konsolidiert werden.
Das Verständnis dieses Verlaufs erklärt, warum bestimmte Zeichen im Alphabet vorkommen und warum der RFC den Implementierern bestimmte Auswahlmöglichkeiten überließ. uuencode, kurz für Unix-to-Unix-Encode, war das erste Tool, das das 7-Bit-Transportproblem unter Unix löste. Es wurde in 1980 erstellt und kodierte jeweils 3 Bytes (24 Bits) in 4 Zeichen aus einem Alphabet mit 64 Zeichen. Das Uuencode-Alphabet war ASCII 32 (Leerzeichen) bis ASCII 95 (Unterstrich und andere Satzzeichen) und wurde ausgewählt, weil diese Zeichen auf jedem Terminal gedruckt werden können. Das Repository zeigt das derzeit implementierte Alphabet, enthält jedoch keine archivierten Beweise darüber, wer diese Reihenfolge ausgewählt hat oder warum jedes Zeichen gewonnen hat. Die Überschrift wird deshalb eingeengt: Die vorliegende Anlage kann genau eingesehen werden, während Motive und Datierungen primäre historische Dokumente erfordern, die hier nicht aufgeführt sind.
Warum das Alphabet historisch aussieht – eine Grenze, die dieses Repository nicht dokumentiert
Leerzeichen als Kodierungszeichen sind jedoch problematisch: Texteditoren und Mailsysteme kürzen nachgestellte Leerzeichen und verfälschen so die Ausgabe. Das Alphabet war nicht ideal, funktionierte aber gut genug für die Dateiübertragung von Unix zu Unix. Privacy-Enhanced Mail (RFC 1421, 1992) war ein früher Versuch, verschlüsselte E-Mails zu standardisieren. Es enthielt eine eigene Base64-Kodierung (RFC 1341 für MIME, deren Spezifikation vor RFC 1421 lag, deren Einführung jedoch verzögert war).
RFC 1421 Base64 verwendete das Alphabet A-Z, a-z, 0-9, +, / (das moderne Base64-Alphabet) und brach Zeilen mit 64 Zeichen um. Dieses Alphabet vermied Leerzeichen und andere problematische Zeichen; Jedes Zeichen ist eindeutig druckbar und nicht mit Steuercodes oder nationalen Zeichensatzvarianten verwechselt. Die Zeilenlänge von 64 Zeichen entsprach der Breite der Papierterminals der 1980er Jahre und war ein praktischer Kompromiss für die Lesbarkeit. Uuencode gehört zur umgebenden Geschichte, dennoch liest oder schreibt das Tool sein Alphabet weder. Es als austauschbares Base64 zu behandeln wäre ein Formatfehler. Der nützliche Vergleich beschränkt sich hier auf das gemeinsame Problem der Darstellung von Bytes durch druckbare Zeichen.
Frühere Kodierungen als Kontext, nicht als Implementierungsbeweis
RFC 1421 wurde für verschlüsselte E-Mails nicht weit verbreitet, aber sein Base64-Alphabet überlebte. MIME (Multipurpose Internet Mail Extensions, RFC 2045, 1996) hat das RFC 1421 Base64-Alphabet übernommen, aber den Zeilenumbruch von 64 in 76 Zeichen geändert. Der Grund war nicht technischer, sondern historischer Natur: PEM-Blöcke (Privacy-Enhanced Mail) bestanden aus 64 Zeichen, und MIME wählte einen etwas anderen Grenzwert, um Verwechslungen mit PEM beim automatisierten Parsen zu vermeiden.
MIME Base64 wurde zum Standard für E-Mail-Anhänge und ist heute die am weitesten verbreitete Base64-Variante. RFC 2045 definierte auch andere Content-Transfer-Encoding-Werte (7bit, 8bit, quoted-printable) und gab Mail-Systemen Optionen basierend auf dem Inhaltstyp. Durch die Auswahl des Alphabets werden Zeichen vermieden, die sich zwischen ASCII und EBCDIC (der IBM-Mainframe-Zeichenkodierung) unterscheiden. Die Zeichen A-Z, a-z, 0-9, + und / sind in beiden Kodierungen gleich. Blöcke im PEM-Stil sind daran zu erkennen, dass Etiketten das verpackte codierte Material umgeben. ToolAcre kann den extrahierten Base64-Körper verarbeiten, nachdem diese Beschriftungen entfernt wurden. Es kann nicht festgestellt werden, welche Archivspezifikation eine bestimmte Konvention zuerst verwendet hat, und dieser Artikel behauptet nicht, dass der Quellbaum diese Frage beantwortet.
Rüstung im PEM-Stil als modernes beobachtbares Format, ohne Anspruch auf eine Ursprungsgeschichte
Zeichen wie offene Klammern und schließende Klammern unterscheiden sich zwischen ASCII und EBCDIC und wurden daher ausgeschlossen. Dies war in den 1980er und frühen 1990er Jahren wichtig, als die Datenübertragung vom Mainframe zum Unix üblich war. Das Alphabet vermeidet außerdem Backslash, einfache Anführungszeichen und doppelte Anführungszeichen, die in C-Strings und der Shell-Syntax eine besondere Bedeutung haben. Eine Base64-Zeichenfolge kann in ein C-Programm oder Shell-Skript eingebettet werden, ohne dass fast jedes Zeichen maskiert werden muss.
RFC 3548 (2006) konsolidierte Base64-, Base32- und Base16-Kodierungen. Es wurde darauf hingewiesen, dass MIME, PEM und andere Anwendungen alle ähnliche Konzepte verwendeten, jedoch unterschiedliche Auffüllregeln und Alphabete verwendeten. RFC 4648 (2006, veröffentlicht zusammen mit RFC 3548) ist der aktuelle Standard und definiert fünf Codierungsfamilien mit jeweils Testvektoren. Der RFC notiert auch den Verlauf: welche Dokumente welche Kodierungen definiert haben, was sich zwischen den Versionen geändert hat und warum die Entscheidungen getroffen wurden. Die 76-Zeichenumbruchoption des Encoders und die Leerraumentfernung des Decoders machen MIME-förmige Beispiele testbar. Diese Implementierungsfakten beweisen nicht die vollständige Geschichte der Mail-Standards. Sie zeigen das moderne Kompatibilitätsverhalten, das Leser direkt im Panel und in Tests nachbilden können.
Umbruch im MIME-Stil als Encoder-Option, ohne den Standardverlauf zu rekonstruieren
Die meisten Entwickler stoßen in RFC nur auf base64 und base64url 4648; Der Verlauf wird für diejenigen dokumentiert, die die älteren Varianten implementieren müssen. Base64url (RFC 4648 Abschnitt 5) ersetzt Plus durch Bindestrich und Schrägstrich durch Unterstrich, um URL-reservierte Zeichen zu vermeiden. Eine Base64-Zeichenfolge, die + und / enthält, muss in einer URL (%2B und %2F) prozentcodiert sein; base64url vermeidet das.
JWT (JSON Web Token) verwendet base64url ohne Auffüllung. Einige Anwendungen verwenden base64url mit Auffüllung. Der RFC definiert beide Varianten; Es liegt an der Anwendung, welche ausgewählt wird. Diese Abweichung ist der Grund, warum ein JWT-Decoder und ein E-Mail-Base64-Decoder unterschiedliche Ausgaben für dieselbe Eingabezeichenfolge erzeugen können (einer erwartet base64url, der andere erwartet base64). Das Alphabet, die Auffüllregeln und der Zeilenumbruch sind allesamt aus praktischen Zwängen realer Systeme entstanden. Portabilität wird am besten als Einschränkung für Transportalphabete und nicht als verifizierte Biografie jedes Symbols betrachtet. Buchstaben und Ziffern bleiben in gängigen Textsystemen optisch vertraut, während die endgültige Zeichensetzung im URL-sicheren Modus unterschiedlich ist. Die genaue historische Auswahlbegründung wird ohne primäre Beweise weggelassen.
Portabilität als Designbeschränkung, nicht als verifizierte Darstellung der individuellen Charakterauswahl
Der 64-Zeichensatz wurde aus Gründen der Darstellbarkeit über verschiedene Kodierungen hinweg ausgewählt; das Alphabet wurde durch RFC 1341 und 1421 und MIME festgelegt; die Auffüllregel stammt aus der 3-Byte-Ausrichtung; und der Zeilenumbruch kam von E-Mail-Transportbeschränkungen. Eine Implementierung, die diesen Verlauf ignoriert, kann eine neue Codierung erfinden oder einen Randfall vergessen. Mit den RFC-Testvektoren 4648 (foobar erzeugt Zm9vYmFy) kann überprüft werden, ob eine Implementierung den Standard einhält.
Es gibt moderne Alternativen wie Base85 (in manchen Kontexten verwendet), aber Base64 bleibt aufgrund der historischen Dynamik und weil es gut genug ist, dominant. Base64 ist nicht die kompakteste Kodierung (Base85 und Base91 sind dichter), aber sie ist einfach, universell und bewährt. Was eindeutig angegeben werden kann, ist das aktuelle Alphabetpaar: Standard endet mit Plus und Schrägstrich; URL-sicher ersetzt Bindestrich und Unterstrich. Polsterung und Umhüllung sind separate Optionen. Die Tests decken beide Modi und fehlende Auffüllungen ab und liefern reproduzierbare Beweise für das aktuelle Verhalten und nicht für eine abgeleitete Chronologie.
Was das Repository über die aktuellen Standard- und URL-sicheren Alphabete beweist
Der prozentuale Größen-Overhead von 33 ist für die meisten Anwendungen akzeptabel. Das Alphabet ist über alle Implementierungen hinweg stabil. Der RFC macht deutlich, dass Abweichungen in der Regel absichtlich erfolgen (z. B. das Weglassen von Auffüllungen oder die Behandlung von Leerzeichen) und nicht auf versehentlichen Missverständnissen beruhen.
Das Verständnis des Base64-Verlaufs erklärt, warum es so aussieht, wie es aussieht. Die Plus- und Schrägstrichzeichen wurden bewusst gewählt, um Mehrdeutigkeiten bei unterschiedlichen Zeichenkodierungen zu vermeiden. Die Auffüllregel stammt aus der 3-Byte-Gruppierung. Base85 und Ascii85 verwenden unterschiedliche Gruppengrößen und Alphabete und liegen außerhalb der Implementierung. Ihre Erwähnung macht diese Seite nicht zu einem Konverter für sie. Für den Vergleich ihrer Dichte oder ihres Verlaufs wären Quellen und Testvektoren erforderlich, die über die für dieses Modul überprüften Base64-Dateien hinausgehen.
Fazit: Jedes Zeichen wurde aus einem bestimmten Grund ausgewählt – wie der Base64-Encoder und -Decoder das resultierende Standardalphabet implementiert
Der Zeilenumbruch stammt aus einer E-Mail. Jede Entscheidung wurde getroffen, um ein reales Problem mit realen Systemen zu lösen. Heutzutage wird Base64 hauptsächlich in Kontexten (JWT, APIs, Daten-URIs) verwendet, in denen der Verlauf keine Rolle spielt, das Alphabet und die Auffüllregeln jedoch von MIME und PEM über RFC 4648 geerbt werden.
Das einmalige Lesen des RFC und das Codieren einer Testzeichenfolge im Base64-Encoder- und Decoder-Tool verbindet den aktuellen Standard mit seinen historischen Wurzeln. Das resultierende Standardalphabet ist immer dann sichtbar, wenn die Eingabe die Indizes zweiundsechzig oder dreiundsechzig erreicht. Verwenden Sie ein Beispiel, das diese Positionen erzeugt, schalten Sie den URL-sicheren Modus um und vergleichen Sie nur die geänderte Interpunktion. Dieses Experiment demonstriert das heutige Format, ohne sich auf eine nicht unterstützte Geschichte über seine Erfindung zu verlassen.