Base64
7 Tools
Was ist Kodierung?
Kodierung ist der Prozess, Daten von einer Darstellung in eine andere zu konvertieren. In der Webentwicklung wird Kodierung verwendet, um Daten sicher durch Kanäle zu übertragen, die für einen begrenzten Zeichensatz ausgelegt sind. Ein typischer Fall ist die Übertragung von Binärdaten über ein textbasiertes Protokoll oder die Einbettung von Sonderzeichen in eine URL. Das Verstehen dieser Unterschiede verhindert schwer zu findende Fehler und Sicherheitslücken.
Zeichenkodierung definiert, wie Textzeichen auf Bytes abgebildet werden. Base64-Kodierung wandelt Binärdaten in ASCII-Text um. URL-Kodierung macht beliebigen Text für die Verwendung in URLs sicher. Jede dieser Kodierungsformen löst ein spezifisches Problem: Zeichenkodierung regelt die Textdarstellung, Base64 ermöglicht den Transport von Binärdaten über textbasierte Kanäle, und URL-Kodierung stellt sicher, dass Webadressen korrekt interpretiert werden.
Geschichte der Zeichenkodierung
Zeichenkodierung ist die Abbildung von Zeichen auf ihre binären Darstellungen. Die Entwicklung von ASCII zu Unicode spiegelt die Globalisierung des Webs wider:
7-Bit-Amerikanischer Standardcode. 128 Zeichen: englische Buchstaben, Ziffern, Satzzeichen und Steuercodes.
Erweiterter ASCII für westeuropäische Sprachen. Fügte 128 Zeichen hinzu. Nicht geeignet für nicht-lateinische Schriften.
Universeller Zeichensatz, der alle Schriftsysteme der Welt abdeckt. Definiert Codepunkte für über 149.000 Zeichen.
Variable-Breite-Kodierung von Unicode mit 1–4 Bytes pro Zeichen. ASCII-kompatibel. Die dominante Kodierung im Web.
Variable-Breite-Kodierung mit 2 oder 4 Bytes pro Zeichen. Intern von Windows, Java und JavaScript-Strings verwendet.
Feste Breitenkodierung: immer 4 Bytes pro Zeichen. Im Web selten zu sehen.
Warum UTF-8 gewann
UTF-8 wurde dominant, weil es rückwärtskompatibel mit ASCII ist, selbstsynchronisierend und platzsparend für lateinischen Text. Jedes ASCII-Dokument ist ein gültiges UTF-8-Dokument. Diese Eigenschaften machten die Migration von älteren Systemen nahezu nahtlos, da bestehende ASCII-Inhalte ohne jede Konvertierung weiterhin gültig blieben. Über 98 % aller Webseiten nutzen heute UTF-8 als Zeichenkodierung.
Base64-Kodierung
Base64 wandelt Binärdaten in eine Textdarstellung um, die nur 64 druckbare ASCII-Zeichen verwendet: A–Z, a–z, 0–9, + und /. Dies ist notwendig, wenn Binärdaten durch rein textbasierte Kanäle übertragen werden müssen. E-Mail-Anhänge, Daten-URIs, JWT-Tokens und HTTP-Basic-Auth verwenden alle Base64. Ohne Base64 würden Binärdaten wie Bilder oder PDF-Dateien beim Transport über Protokolle, die nur 7-Bit-ASCII unterstützen, beschädigt werden.
Wie es funktioniert
Base64 gruppiert Eingabebytes in 3-Byte-Blöcke (24 Bit) und kodiert jeden Block als 4 Base64-Zeichen (je 6 Bit). Bei nicht durch 3 teilbaren Eingaben werden =-Auffüllzeichen hinzugefügt. Konkret: 3 Eingabebytes erzeugen exakt 4 Ausgabezeichen, was einer Größenzunahme von 33 % entspricht. Das Base64-Alphabet wurde so gewählt, dass es in allen gängigen Textprotokollen sicher übertragen werden kann, ohne Steuerzeichen oder Sonderzeichen zu enthalten, die zu Fehlinterpretationen führen könnten.
| Eingabe | Hex-Bytes | Base64 |
|---|---|---|
| "Man" | 77 61 6E | TWFu |
| "Ma" | 4D 61 | TWE= |
| "M" | 4D | TQ== |
Die =-Auffüllzeichen am Ende zeigen an, wie viele Bytes für die Vervollständigung der letzten 3-Byte-Gruppe fehlten. Ein = bedeutet, dass ein Byte an Auffüllung benötigt wurde; == bedeutet, dass zwei Bytes fehlten. Standard-Base64 erzeugt immer Ausgaben, deren Länge ein Vielfaches von 4 ist. Manche Implementierungen wie Base64url für JWTs lassen die Auffüllung weg, da die Länge aus dem Kontext abgeleitet werden kann.
URL-Kodierung
URLs können nur einen begrenzten Satz sicherer ASCII-Zeichen enthalten. Alle anderen Zeichen — einschließlich Leerzeichen, Satzzeichen, Nicht-ASCII-Zeichen und URL-Sonderzeichen wie &, = und # — müssen prozent-kodiert werden, bevor sie in eine URL eingefügt werden. Wird diese Kodierung vergessen, können URL-Parser die Struktur der Adresse falsch interpretieren und Daten stillschweigend korrumpieren.
Prozent-Kodierung ersetzt jedes unsichere Byte durch % gefolgt von zwei Hexadezimalziffern. Ein Leerzeichen wird zu %20, ein kaufmännisches Und zu %26. Mehrbytige UTF-8-Zeichen werden pro Byte kodiert: das Zeichen é (U+00E9) wird als %C3%A9 dargestellt, da es in UTF-8 zwei Bytes belegt.
Häufig kodierte Zeichen
| Zeichen | Kodiert | Hinweise |
|---|---|---|
| Space | %20 | Am häufigsten; in Formular-Submissions als + in application/x-www-form-urlencoded verwendet |
| & | %26 | Query-String-Trennzeichen; muss kodiert werden, wenn als Literalwert verwendet |
| = | %3D | Schlüssel-Wert-Trennzeichen in Query-Strings; kodieren wenn als Datum verwendet |
| + | %2B | Wird als Leerzeichen in application/x-www-form-urlencoded interpretiert; kodieren um + zu erhalten |
| # | %23 | Fragment-Bezeichner; kodieren wenn als Literaldaten in einem Pfad oder Query verwendet |
| / | %2F | Pfadsegment-Trennzeichen; kodieren wenn als Literaldaten, nicht als Pfad-Delimiter verwendet |
| : | %3A | Schema-Trennzeichen; in Pfad- und Query-Kontexten kodieren |
| @ | %40 | In mailto: und auth verwendet; kodieren wenn als Literaldaten verwendet |
encodeURI vs. encodeURIComponent
JavaScript stellt zwei Kodierungsfunktionen mit unterschiedlichem Umfang bereit. encodeURI kodiert eine vollständige URL und lässt Zeichen mit URL-struktureller Bedeutung (wie :, /, ?, #, @) unverändert. encodeURIComponent kodiert eine einzelne URL-Komponente — also etwa einen Query-Parameter-Wert oder ein Pfadsegment — und kodiert alle Zeichen außer A-Z, a-z, 0-9, -, _, ., ~. Als Faustregel gilt: encodeURIComponent für einzelne Werte verwenden und encodeURI für vollständige URL-Zeichenfolgen, bei denen die URL-Struktur erhalten bleiben soll.
Wo Kodierung in der Webentwicklung vorkommt
Der Authorization: Basic-Header kodiert Anmeldedaten als Base64(Benutzername:Passwort). Das ist Kodierung für Transportzwecke, KEINE Sicherheit. Base64 ist trivial umkehrbar — jeder, der den Header abfängt, kann die Anmeldedaten sofort lesen. Immer HTTPS mit Basic Auth verwenden, damit der Transport selbst verschlüsselt ist.
Daten-URIs betten Dateiinhalt direkt in HTML oder CSS ein: data:image/png;base64,.... Das eliminiert HTTP-Anfragen auf Kosten erhöhter Dokumentgröße. Da Base64 die Datenmenge um ca. 33 % vergrößert, empfiehlt es sich, Daten-URIs nur für kleine Ressourcen wie kleine Icons oder Schriftarten zu verwenden, bei denen der eingesparte HTTP-Request den Größenaufwand rechtfertigt.
E-Mail wurde für 7-Bit-ASCII entworfen. Binäre Anhänge wie Bilder oder PDF-Dokumente werden von MIME vor der Übertragung Base64-kodiert. Das E-Mail-Programm des Empfängers dekodiert die Anhänge beim Anzeigen der E-Mail transparent, sodass der Nutzer nichts von der Kodierung bemerkt.
JWT-Tokens verwenden Base64url-Kodierung für alle drei Teile (Header, Payload, Signatur), was sie URL-sicher macht, ohne dass eine zusätzliche Prozent-Kodierung erforderlich ist. Der Payload eines JWTs kann also direkt als Query-Parameter oder im Authorization-Header verwendet werden, ohne dass Sonderzeichen wie + oder / Probleme verursachen.
Alle benutzerseitigen Daten in URL-Query-Strings müssen prozent-kodiert werden. Wird & oder = in einem Wert nicht kodiert, korrumpiert dies stillschweigend das Query-String-Parsing. Immer encodeURIComponent für einzelne Werte verwenden.
Nicht-ASCII-Domainnamen wie münchen.de werden mit Punycode (xn--Präfix) für die DNS-Kompatibilität kodiert. Der Browser zeigt die Unicode-Form an, schickt aber intern die Punycode-Form an den DNS-Resolver. Dieser Mechanismus wurde durch RFC 3492 standardisiert und ermöglicht es, Domainnamen in jeder Sprache zu registrieren, ohne das DNS-System zu ändern.
Häufig gestellte Fragen
Nein. Base64 ist Kodierung, keine Verschlüsselung. Es ist eine vollständig umkehrbare Transformation ohne geheimen Schlüssel — jeder, der eine Base64-Zeichenfolge sieht, kann sie sofort dekodieren. Base64 niemals als Sicherheitsmaßnahme verwenden. Für echten Schutz vertraulicher Daten ist eine kryptografische Verschlüsselung wie AES oder RSA erforderlich.
Base64 verarbeitet Eingaben in 3-Byte-Gruppen. Wenn die Eingabe kein Vielfaches von 3 Bytes ist, wird =-Auffüllung hinzugefügt, damit die Ausgabe immer ein Vielfaches von 4 Zeichen ergibt. Ein = steht für ein fehlendes Byte, == für zwei fehlende Bytes. Manche Implementierungen wie Base64url für JWTs lassen diese Auffüllung weg, da sie aus der Länge des Tokens abgeleitet werden kann.
Base64url ist eine URL-sichere Variante von Base64, die + durch - und / durch _ ersetzt und typischerweise =-Auffüllung weglässt. Dadurch kann Base64url direkt in URLs und HTTP-Headern verwendet werden, ohne dass die Sonderzeichen zusätzlich prozent-kodiert werden müssen. JWTs verwenden Base64url für alle drei Teile — Header, Payload und Signatur.
encodeURIComponent für einzelne Werte verwenden — etwa Query-Parameter-Werte oder Pfadsegmente. encodeURI für eine vollständige URL-Zeichenfolge, bei der URL-Strukturzeichen wie /, :, ?, # erhalten bleiben sollen. Im Zweifelsfall ist encodeURIComponent die sicherere Wahl, da es ein breiteres Spektrum an Zeichen kodiert.
UTF-8 ist ASCII-kompatibel und platzsparend für lateinischen Text. Die meisten URLs, HTML-Tags und Quellcode bestehen aus ASCII-Zeichen, die in UTF-8 jeweils nur ein Byte belegen. UTF-16 dagegen ist nicht rückwärtskompatibel mit ASCII und benötigt für ASCII-Zeichen zwei Bytes. HTTP und HTML verwenden standardmäßig UTF-8.
Prozent-Kodierung stellt Zeichen als % gefolgt von ihrem zweistelligen Hexadezimal-Bytewert dar. Ein Leerzeichen ist %20, da sein dezimaler Bytewert 32 dem Hexadezimalwert 20 entspricht. Mehrbytige UTF-8-Zeichen werden pro Byte einzeln kodiert: é (U+00E9) wird in UTF-8 durch die zwei Bytes 0xC3 und 0xA9 dargestellt und erscheint in einer URL als %C3%A9.
Base64 erhöht die Datengröße um ca. 33 % und fügt CPU-Overhead für die Kodierung und Dekodierung hinzu. Bei durchsatzintensiven Systemen sind Binärprotokolle vorzuziehen. URL-Kodierung fügt minimalen CPU-Overhead hinzu, kann aber URLs mit vielen Sonderzeichen deutlich verlängern. Für die meisten Webanwendungen ist der Performance-Einfluss beider Kodierungsformen vernachlässigbar.
Punycode ist eine durch RFC 3492 definierte Kodierung zur Darstellung von Unicode-Zeichen im ASCII-kompatiblen DNS-System. Internationalisierte Domainnamen wie münchen.de werden als xn--mnchen-3ya.de in DNS-Anfragen übertragen. Browser zeigen die Unicode-Form an, verwenden intern aber Punycode, um die Kompatibilität mit der bestehenden DNS-Infrastruktur zu gewährleisten.