Base64 erklart: 6-Bit-Gruppierung, ~33% Grossenzunahme, Auffullzeichen und base64url vs. Standard
Was Base64 ist - und was es nicht ist
Base64 ist ein Binar-zu-Text-Kodierungsschema. Es wandelt beliebige Binardaten in eine Zeichenkette aus druckbaren ASCII-Zeichen um und macht diese Daten sicher fur die Einbettung in Kontexten, die fur menschenlesbaren Text konzipiert wurden. Base64 ist keine Komprimierung - es macht Daten grosser. Es ist auch keine Verschlusselung - jeder, der die kodierte Zeichenkette hat, kann die ursprunglichen Bytes trivial wiederherstellen. Der Name kommt daher, dass es ein Alphabet von genau 64 Zeichen verwendet, da 2^6 = 64 es jedem Zeichen ermoglicht, genau 6 Bit der Eingabe darzustellen.
Base64 wurde nicht als eigenstandiger Standard erfunden; es entstand aus der Notwendigkeit, binare E-Mail-Anhange uber SMTP-Infrastruktur zu senden, die nur zuverlassig 7-Bit-ASCII ubertrug. RFC 2045 (1996), das MIME definiert, standardisierte die Kodierung fur E-Mail. Ein Jahrzehnt spater konsolidierte RFC 4648 (2006) Base64 und seine Varianten - einschliesslich Base32 und Base64url - in einem einzigen Referenzdokument. RFC 4648 ist nach wie vor die massgebliche Spezifikation, die heute von jedem neuen Protokoll verwendet wird, das eine Binar-zu-Text-Kodierung benotigt.
Die 6-Bit-Gruppierung: wie drei Eingabebytes zu vier Zeichen werden
Der Kern von Base64 ist eine einfache Bit-Umpackoperation. Binardaten kommen in Gruppen von 8-Bit-Bytes an; Base64 gruppiert diese Bits in 6-Bit-Stucke um, von denen jedes einem Zeichen im 64-Zeichen-Alphabet zugeordnet wird. Da das kleinste gemeinsame Vielfache von 6 und 8 gleich 24 ist, ist die naturliche Verarbeitungseinheit 3 Bytes = 24 Bit -> 4 Zeichen. Nehmen wir Man als konkretes Beispiel: Die drei Bytes sind 0x4D, 0x61, 0x6E, was die Bitfolge 01001101 01100001 01101110 ergibt. Umgruppiert in vier 6-Bit-Werte: 010011 (19 -> T), 010110 (22 -> W), 000101 (5 -> F), 101110 (46 -> u). Das kodierte Ergebnis ist TWFu.
Dieses 3-zu-4-Byte-Verhaltnis ist die direkte Ursache der Grossenzunahme. Fur je 3 Eingabebytes ist die Ausgabe immer 4 Zeichen, unabhangig von den tatsachlichen Bytewerten. Fur n Eingabebytes betragt die kodierte Ausgabe ceil(n / 3) x 4 Zeichen, was bedeutet, dass die Ausgabe immer 33% grosser als die Eingabe ist (genau 4/3-mal grosser). Eine 1-KB-Datei wird auf etwa 1,37 KB kodiert; ein 1-MB-Bild wird auf etwa 1,37 MB kodiert.
Das Alphabet: A-Z, a-z, 0-9, +, /
Das Standard-Base64-Alphabet bildet 6-Bit-Werte 0-63 in dieser Reihenfolge auf druckbare ASCII-Zeichen ab: Werte 0-25 auf Grossbuchstaben A-Z, Werte 26-51 auf Kleinbuchstaben a-z, Werte 52-61 auf Ziffern 0-9, Wert 62 auf +, und Wert 63 auf /. Diese Reihenfolge platziert Buchstaben vor Ziffern - umgekehrt zur ASCII-Zahlenreihenfolge - aus historischen Grunden der MIME-Kompatibilitat. Die Wahl von + und / fur die letzten beiden Werte hat jahrzehntelang Interoperabilitatsprobleme verursacht, da beide Zeichen in URLs besondere Bedeutung haben.
Ein haufiges Missverstandnis ist, dass Base64 zeichensatzunabhangig ist. Das ist nicht der Fall: Das Alphabet ist festes ASCII. Ein Decoder, der auf ein Zeichen ausserhalb des 65-Zeichen-Satzes (64 Datenzeichen plus = fur Auffullung) trifft, muss die Eingabe entweder ablehnen oder uberspringen, je nach Spezifikationskontext. RFC 4648 empfiehlt, Nicht-Alphabet-Zeichen im strikten Modus abzulehnen. Das Gleichheitszeichen = ist ein Markierer, kein Datenzeichen - es markiert die Auffullung und sollte niemals ausser am Ende einer kodierten Zeichenkette erscheinen.
Auffullung: warum Gleichheitszeichen existieren und wann sie weggelassen werden konnen
Da die Kodierung jeweils 3 Bytes verarbeitet, hinterlassen Eingaben, deren Lange nicht durch 3 teilbar ist, am Ende eine unvollstandige Gruppe. Die Auffullung lost dieses Problem: Sie erzwingt, dass die kodierte Ausgabe immer ein Vielfaches von 4 Zeichen ist, wodurch die ursprungliche Byteanzahl allein aus der Ausgabelange berechnet werden kann. Wenn die Eingabe 1 Restbyte hat, werden 2 Auffullzeichen == angehangt. Wenn die Eingabe 2 Restbytes hat, wird 1 Auffullzeichen = angehangt.
Auffullung ist optional in Kontexten, in denen die Gesamtlange auf andere Weise bekannt ist. RFC 7515, die JSON-Web-Signatur-Spezifikation, verlangt explizit, dass Implementierungen die =-Auffullung beim Kodieren von JWT-Komponenten weglassen, da die Punkte zwischen den drei Teilen eines JWT die Segmente bereits begrenzen. Base64url-kodierte Werte in JWTs enden daher nie mit =. Das Wiederherstellen der Auffullung ist einfach: =-Zeichen anhangen, bis die Zeichenkettenlange ein Vielfaches von 4 ist.
Base64url: die URL-sichere Variante in JWTs und OAuth-Tokens
Die Zeichen + und / des Standard-Base64 sind in URL-Kontexten problematisch. Ein + in einem Query-String wird als Leerzeichen unter der application/x-www-form-urlencoded-Kodierung interpretiert. Ein / ist ein Pfadsegment-Trenner. Base64url, definiert in RFC 4648 Abschnitt 5, ersetzt + durch - und / durch _. Diese beiden Zeichen sind in URLs ohne Prozent-Kodierung sicher. Die Auffullung = wird in Base64url-Kontexten ebenfalls typischerweise weggelassen.
Base64url wird uberall dort verwendet, wo eine kompakte, URL-sichere Bindardarstellung benotigt wird: Die Header- und Payload-Abschnitte eines JWT sind Base64url-kodiertes JSON; OAuth-2.0-Autorisierungscodes sind oft Base64url-kodierte Zufallsbytes; PKCE (RFC 7636) Code-Verifier und -Challenges verwenden Base64url. Das Datenvergrosserungsverhaltnis ist identisch mit Standard-Base64 - genau 4/3 - da sich nur das Alphabet unterscheidet, nicht der Bit-Gruppierungsalgorithmus.
Praktische Auswirkungen auf die Grosse und die Wahl zwischen Base64 und Binar
Der Overhead von ~33% ist die wichtigste praktische Kosten von Base64. Fur Data-URIs - das direkte Einbetten von Bildern, Schriftarten oder SVGs in HTML oder CSS mit data:image/png;base64,... - besteht der Kompromiss darin, einen HTTP-Roundtrip zu eliminieren auf Kosten eines grosseren Dokuments. Dies ist vorteilhaft fur kleine Ressourcen (typischerweise unter 4-8 KB): Der eingesparte Roundtrip uberwiegt die Grossenzunahme, besonders bei Verbindungen mit hoher Latenz. Bei grosseren Ressourcen verschlechtert die Grossenzunahme die Leistung, da das grossere HTML-Dokument langer zum Parsen benotigt und nicht separat vom Seiteninhalt gecacht werden kann.
HTTP-Basisauthentifizierung kodiert Anmeldedaten als base64(Benutzername:Passwort) im Header Authorization: Basic .... Dies ist keine Sicherheitsmassnahme - Benutzername und Passwort sind durch Dekodierung trivial wiederherstellbar. Basisauthentifizierung erfordert HTTPS fur Sicherheit; die Base64-Kodierung existiert nur, weil die HTTP-Header-Spezifikation druckbares ASCII verlangt. Wenn ein Payload vertrauliche Informationen enthalt, ist Base64 kein Ersatz fur Verschlusselung. Verwenden Sie authentifizierte Verschlusselung (z.B. AES-GCM) oder JSON Web Encryption (JWE, RFC 7516) fur vertrauliche Daten.