Base64-Kodierung erklärt: Funktionsweise, Einsatzgebiete und verbreitete Irrtümer

Warum es Base64 gibt

Alle Computerdaten sind letztlich Bytes. Viele Kanäle können jedoch nur Text sicher transportieren: E-Mail-Texte, HTTP-Header, JSON-Dokumente und URLs. Schickt man rohe Bildbytes oder Chiffretext durch diese Kanäle, können Steuerzeichen und Zeilenumbrüche die Daten beschädigen, oder ein Zwischensystem schreibt sie um.

Base64 löst das Problem, indem es beliebige Bytefolgen auf ein Alphabet aus 64 Zeichen abbildet: Groß- und Kleinbuchstaben, Ziffern sowie + und /. Diese Zeichen gelten fast überall als sicher, sodass Binärdaten unbeschadet durch reine Textkanäle gelangen. Das Format ist in RFC 4648 standardisiert.

Aus drei Bytes werden vier Zeichen

Die Grundidee ist einfach. Die Eingabe wird in Blöcken zu drei Bytes (24 Bit) gelesen, und diese 24 Bit werden in vier Gruppen zu je sechs Bit aufgeteilt. Mit sechs Bit lassen sich 64 Werte von 0 bis 63 darstellen, daher entspricht jede Gruppe einem Zeichen: 0–25 sind A–Z, 26–51 sind a–z, 52–61 sind 0–9, 62 ist + und 63 ist /.

Nehmen wir das Wort Man. Seine Bytes sind 77, 97 und 110. Teilt man diese 24 Bit in Sechsergruppen, ergeben sich 19, 22, 5 und 46, was TWFu entspricht. Nicht-englischer Text funktioniert genauso, sobald er in Bytes umgewandelt ist: Das koreanische Zeichen 한 belegt in UTF-8 drei Bytes (ED 95 9C) und wird daher zu genau vier Zeichen, 7ZWc.

Man   → TWFu
Hi    → SGk=
한    → 7ZWc
안녕  → 7JWI64WV

Da drei Bytes immer zu vier Zeichen werden, ist die Base64-Ausgabe etwa 33 % größer als die Eingabe. Aus einer Datei mit 1.000 Bytes werden 1.336 Zeichen. Deshalb macht das Einbetten großer Bilder als Data-URI eine Seite spürbar schwerer.

Was das abschließende = bedeutet

Ist die Eingabelänge kein Vielfaches von drei, enthält der letzte Block nur ein oder zwei Bytes. Die fehlenden Bits werden mit Nullen aufgefüllt, und ein oder zwei =-Zeichen werden angehängt, damit die Ausgabelänge ein Vielfaches von vier bleibt. Ein übriges Byte ergibt ==, zwei übrige Bytes ergeben ein einzelnes =. Deshalb wird Hi (zwei Bytes) zu SGk=.

Das Padding ist nur ein Hinweis, der dem Decoder hilft, die genaue Länge wiederherzustellen; es enthält keine Daten. Manche Systeme lassen es weg, und strenge Decoder lehnen die Zeichenkette dann mit einem Fehler wegen ungültiger Länge ab. Hängt man =-Zeichen an, bis die Länge ein Vielfaches von vier ist, ist das Problem meist behoben.

Base64URL für Links und Dateinamen

Die Zeichen + und / haben in URLs eine besondere Bedeutung: + kann als Leerzeichen gelesen werden, und / trennt Pfadsegmente. Die Variante Base64URL ersetzt daher + durch - und / durch _. Dieselben zwei Bytes FB FF werden in Standard-Base64 zu +/8= und in Base64URL zu -_8=.

Alle drei Teile eines JSON Web Token sind Base64URL-kodiert, meist ohne Padding. Dekodiert man den mittleren Teil eines JWT, kann man Angaben wie Benutzer-ID und Ablaufzeit im Klartext lesen. Das führt direkt zum wichtigsten Punkt über Base64.

Der große Irrtum: Base64 ist keine Verschlüsselung

Base64-Ausgaben sehen zufällig aus und werden daher oft mit Verschlüsselung verwechselt. Es gibt aber keinen Schlüssel: Jeder kann die Kodierung mit denselben öffentlichen Regeln sofort rückgängig machen. Passwörter oder API-Schlüssel als Base64 zu speichern oder zu senden, bietet nicht mehr Schutz als Klartext.

HTTP-Basic-Authentifizierung ist ein gutes Beispiel. Benutzername und Passwort werden mit einem Doppelpunkt verbunden und Base64-kodiert, doch das ist nur ein Übertragungsformat; den eigentlichen Schutz bietet HTTPS. Wenn Sie Daten verbergen müssen, verwenden Sie eine Verschlüsselung wie AES. Wenn Sie Manipulationen erkennen müssen, verwenden Sie einen Hash oder eine Signatur.

Wo Ihnen Base64 in der Praxis begegnet

Wer weiß, wo Base64 eingesetzt wird, erkennt unbekannte Zeichenketten schneller.

• E-Mail-Anhänge: MIME kodiert binäre Anhänge als Base64 im Nachrichtentext.
• Data-URIs: Kleine Icons lassen sich als data:image/png;base64,... in CSS oder HTML einbetten. Beschränken Sie das auf Bilder von wenigen Kilobyte.
• JWT und OAuth: Header und Payload von Token verwenden Base64URL.
• API-Nutzdaten: JSON kann keine Rohbytes aufnehmen, daher werden Dateien und Signaturen als Base64-Zeichenketten gesendet.
• Zertifikate und Schlüssel: Der Inhalt einer PEM-Datei, die mit -----BEGIN CERTIFICATE----- beginnt, ist Base64.

Fehlersuche, wenn sich eine Zeichenkette nicht dekodieren lässt

Die meisten Dekodierfehler haben nur wenige Ursachen. Prüfen Sie zuerst auf Zeilenumbrüche oder Leerzeichen; E-Mails und PEM-Dateien brechen oft alle 76 Zeichen um. Zweitens: Wenn Sie - oder _ sehen, handelt es sich um Base64URL, das entsprechend dekodiert werden muss. Drittens: Ist die Länge kein Vielfaches von vier, fehlt das Padding.

Gelingt die Dekodierung, der Text erscheint aber verstümmelt, liegt das an der ursprünglichen Zeichenkodierung. Umlaute wie ä, ö und ü ergeben zum Beispiel in UTF-8 und ISO-8859-1 unterschiedliche Bytes, daher müssen Sie das Ergebnis mit demselben Zeichensatz interpretieren, der beim Kodieren verwendet wurde. Das Base64-Werkzeug von AIBIZAP arbeitet mit UTF-8, sodass Umlaute, Japanisch, Koreanisch und Emoji korrekt hin- und zurückkonvertiert werden.