Base64 vs URL-Kodierung

Base64-Kodierung und URL-Kodierung (Prozentkodierung) dienen in der Webentwicklung unterschiedlichen Zwecken. Zu verstehen, wann welche verwendet werden sollte, ist essenziell. Obwohl beide Kodierungsschemata sind, die Daten in eine andere Darstellung umwandeln, lösen sie grundlegend unterschiedliche Probleme. Base64 wurde entwickelt, um beliebige Binärdaten in ein sicheres ASCII-Textformat zu konvertieren, während die URL-Kodierung sicherstellt, dass Sonderzeichen in URLs sicher über das Internet übertragen werden. Die Wahl der falschen Kodierung für Ihren Anwendungsfall kann zu Datenkorruption, defekten URLs, Sicherheitslücken oder unnötig aufgeblähten Nutzlastgrößen führen.

Entwickler stehen häufig vor Situationen, in denen sie zwischen diesen beiden Kodierungsmethoden wählen müssen. Wenn Sie beispielsweise ein Authentifizierungstoken in einen URL-Abfrageparameter aufnehmen, fragen Sie sich vielleicht, ob Sie Base64-Kodierung oder URL-Kodierung verwenden sollen. Die Antwort hängt von der Art der Daten, den Einschränkungen des Übertragungsmediums und den Anforderungen des empfangenden Systems ab. Dieser Leitfaden bietet einen umfassenden Vergleich, um Ihnen die richtige Wahl zu erleichtern.

URL-Kodierung verstehen

Die URL-Kodierung, auch als Prozentkodierung bekannt, wandelt Zeichen in ein Format um, das über das Internet übertragen werden kann. Die URL-Spezifikation (RFC 3986) definiert, welche Zeichen in URLs unreserviert zulässig sind und welche kodiert werden müssen. Zu den unreservierten Zeichen gehören Groß- und Kleinbuchstaben, Ziffern sowie die Zeichen Bindestrich (-), Unterstrich (_), Punkt (.) und Tilde (~). Alle anderen Zeichen müssen prozentkodiert werden, wenn sie in einer URL erscheinen.

Leerzeichen werden zu %20, und Sonderzeichen werden durch ihre hexadezimalen ASCII-Werte ersetzt, denen ein % vorangestellt ist. Der Kodierungsprozess ist unkompliziert: Jedes Byte, das kein unreserviertes Zeichen ist, wird durch ein % gefolgt von seiner zweistelligen Hexadezimaldarstellung ersetzt. Beispielsweise wird der String hallo welt zu hallo%20welt und a&b=c zu a%26b%3Dc.

Warum URL-Kodierung notwendig ist

URLs haben aus historischen und praktischen Gründen einen eingeschränkten Zeichensatz. Die ursprüngliche URL-Spezifikation wurde entwickelt, als das Internet hauptsächlich 7-Bit-ASCII-Text übertrug. Zeichen außerhalb dieses Bereichs oder Zeichen, die in URLs eine besondere Bedeutung haben (wie ?, # und &), müssen kodiert werden, um zu verhindern, dass sie vom URL-Parser falsch interpretiert werden.

Zum Beispiel wird das &-Zeichen verwendet, um Abfrageparameter zu trennen. Wenn Ihre Daten ein & enthalten, würde es als Parametertrenner und nicht als Daten interpretiert. Die URL-Kodierung wandelt & in %26 um und stellt sicher, dass es als Teil des Parameterwerts behandelt wird. Ebenso markiert das #-Zeichen den Beginn eines URL-Fragments; %23 stellt sicher, dass es als Daten erscheint.

Die URL-Kodierung ermöglicht auch die Aufnahme von Nicht-ASCII-Zeichen in URLs durch UTF-8-Kodierung. Beispielsweise wird das Unicode-Zeichen U+00E9 (é) in einer URL als %C3%A9 kodiert. Dies ermöglicht die Darstellung internationalisierter Domainnamen und Pfade innerhalb der reinen ASCII-URL-Spezifikation.

Häufige URL-kodierte Zeichen

Das Leerzeichen verdient eine besondere Erwähnung, da es zwei mögliche Kodierungen hat. In Abfragezeichenfolgen kodiert die Spezifikation application/x-www-form-urlencoded Leerzeichen als + anstelle von %20. Dieses Legacy-Verhalten stammt aus HTML-Formularübermittlungen. Wenn Sie Daten für Abfrageparameter kodieren, sollten Sie + für Leerzeichen verwenden, wenn Sie der Formularkodierungskonvention folgen, oder %20 für Leerzeichen in anderen URL-Komponenten wie dem Pfad.

URL-Kodierung in verschiedenen URL-Komponenten

Verschiedene Teile einer URL haben unterschiedliche Kodierungsanforderungen. Die Pfadkomponente sollte / nicht kodieren, da es Pfadsegmente trennt. Die Abfragekomponente sollte ? oder & nicht kodieren, da sie in der Abfragezeichenfolge eine besondere Bedeutung haben. Wenn Ihre Daten jedoch diese Zeichen enthalten, müssen sie kodiert werden: ? wird zu %3F, & wird zu %26.

Die Fragmentkomponente (nach #) hat die tolerantesten Kodierungsregeln, da das Fragment nie an den Server gesendet wird. Die Kodierung wird jedoch empfohlen, um Mehrdeutigkeiten bei der clientseitigen Analyse zu vermeiden.

Base64-Kodierung verstehen

Base64 wandelt Binärdaten unter Verwendung eines 64-Zeichen-Alphabets in ASCII-Text um. Das Alphabet besteht aus A-Z, a-z, 0-9, + und /, wobei = für Auffüllung verwendet wird. Dieser 64-Zeichen-Satz stellt sicher, dass die kodierte Ausgabe nur aus universell sicheren ASCII-Zeichen besteht, obwohl die Zeichen + und / bei Verwendung in URLs eine zusätzliche URL-Kodierung erfordern.

Base64-Kodierung funktioniert, indem Eingabedaten in Gruppen von 3 Bytes (24 Bit) verarbeitet werden. Diese 24 Bit werden in vier 6-Bit-Gruppen aufgeteilt, und jeder 6-Bit-Wert (0-63) wird einem Zeichen im Base64-Alphabet zugeordnet. Wenn die Eingabelänge kein Vielfaches von 3 Bytes ist, werden Auffüllzeichen (=) hinzugefügt, um die Ausgabelänge zu einem Vielfachen von 4 Zeichen zu machen.

Der Hauptzweck der Base64-Kodierung besteht darin, Binärdaten für textbasierte Transportkanäle sicher zu machen. E-Mail (MIME), JSON, XML und HTTP-Header sind alles textbasierte Protokolle, die rohe Binärdaten nicht zuverlässig verarbeiten können, da binäre Bytes als Steuerzeichen interpretiert oder von der Transportschicht modifiziert werden können.

Hauptunterschiede

Die grundlegenden Unterschiede zwischen Base64 und URL-Kodierung ergeben sich aus ihren unterschiedlichen Zwecken und Designeinschränkungen.

Base64 erweitert die Daten unabhängig vom Eingabeinhalt immer um etwa 33 Prozent, da alle 3 Eingabebytes zu 4 Ausgabezeichen werden. Die URL-Kodierung erweitert die Daten um einen variablen Betrag. ASCII-Buchstaben und Ziffern werden überhaupt nicht erweitert (1 Byte wird zu 1 Byte). Leerzeichen erweitern sich von 1 Byte auf 3 Bytes (%20). Zeichen außerhalb des ASCII-Bereichs, die als UTF-8 kodiert sind, erweitern sich noch mehr: Ein einzelnes Unicode-Zeichen könnte zu 2 oder 3 UTF-8-Bytes werden, die jeweils als %XX kodiert sind, was zu 6 oder 9 Bytes in der URL führt.

Die Zeichensätze unterscheiden sich ebenfalls erheblich. Die Base64-Ausgabe verwendet einen festen Satz von 65 Zeichen, während die URL-Kodierung jedes Zeichen in der Form %XX erzeugen kann. Dies bedeutet, dass die Base64-Ausgabe für Binärdaten kompakter ist, aber Zeichen außerhalb ihres Alphabets ohne sekundäre Kodierung nicht darstellen kann. Die URL-Kodierung ist flexibler, aber für Binärdaten weniger platzeffizient.

URL-sicheres Base64 (Base64URL)

Da Standard-Base64 + und / als Teil seines Alphabets verwendet, können Base64-kodierte Daten nicht ohne zusätzliche URL-Kodierung direkt in URLs verwendet werden. Um dies zu beheben, wurde die Base64URL-Variante eingeführt. Base64URL ersetzt + durch - und / durch _ und entfernt die Auffüllzeichen =. Diese Ersetzungen erzeugen eine Ausgabe, die ohne Prozentkodierung sicher für URLs ist.

Base64URL wird von JWT (JSON Web Tokens) verwendet, die ihren Header und Payload mit dieser Variante kodieren. Wenn Sie ein JWT-Token wie eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dQw4w9WgXcQ sehen, sind die ersten beiden Segmente Base64URL-kodiert.

Wann welche verwendet werden sollte

Die folgende Tabelle bietet eine schnelle Orientierung für häufige Szenarien.

Die richtige Kodierung wählen

Befolgen Sie diese Richtlinien, wenn Sie sich zwischen Base64 und URL-Kodierung entscheiden.

Base64 verwenden, wenn:

• Sie Binärdaten (Bilder, Dokumente, verschlüsselte Daten) über ein textbasiertes Protokoll übertragen müssen.
• Sie Daten inline in HTML, CSS oder JSON einbetten möchten (Data URIs).
• Sie Daten für MIME-E-Mail-Anhänge kodieren.
• Sie Authentifizierungstoken oder andere undurchsichtige Datenblobs erstellen.

URL-Kodierung verwenden, wenn:

• Sie URLs oder Abfragezeichenfolgen mit Sonderzeichen konstruieren.
• Sie Formulardaten verarbeiten, die über application/x-www-form-urlencoded übermittelt wurden.
• Sie Textdaten für die Verwendung in URL-Pfadsegmenten, Abfrageparametern oder Fragmenten kodieren müssen.
• Sie Cookie-Werte kodieren, die Sonderzeichen enthalten können.

Kodierungen kombinieren

In einigen Fällen müssen Sie möglicherweise beide Kodierungen zusammen verwenden. Wenn Sie beispielsweise einen Base64-kodierten Wert als Abfrageparameter übergeben, müssen Sie die Base64-Ausgabe URL-kodieren, um sicherzustellen, dass die Zeichen + und = in der URL sicher sind. Diese Doppelkodierung ist in API-Designs üblich, bei denen Token oder Identifikatoren Base64-kodiert und als Abfrageparameter übertragen werden.

const base64Data = btoa('some binary data');
const urlSafe = encodeURIComponent(base64Data);
// urlSafe is now safe for use in a URL

Auf der Empfängerseite kehren Sie den Prozess um: zuerst URL-dekodieren, dann Base64-dekodieren.

Praktische Beispiele

Beispiel 1: Ein Bild in HTML einbetten

Sie haben ein 1 KB großes PNG-Symbol, das Sie in eine HTML-E-Mail einbetten möchten. Der richtige Ansatz ist die Base64-Kodierung:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...">

Die URL-Kodierung würde hier nicht helfen, da HTML-E-Mails nativ keine prozentkodierten Data-URIs unterstützen.

Beispiel 2: Eine Suchanfrage in einer URL übergeben

Sie möchten einen Suchlink erstellen, der die Abfrage "café & bakery" enthält. Der richtige Ansatz ist die URL-Kodierung:

https://example.com/search?q=caf%C3%A9+%26+bakery

Die Verwendung von Base64 würde hier eine viel längere und weniger lesbare URL erzeugen.

Beispiel 3: API-Authentifizierungstoken

Ihre API verwendet ein Token, das eine Benutzer-ID und einen Zeitstempel kombiniert, signiert mit einem HMAC. Das Token ist binär und muss als Abfrageparameter übertragen werden. Der richtige Ansatz ist Base64 (vorzugsweise Base64URL) gefolgt von URL-Kodierung oder einfach Base64URL, wenn die Transportschicht die verbleibenden Sonderzeichen behandelt.

https://api.example.com/data?token=eyJ1c2VySWQiOjEyMywidGltZXN0YW1wIjoxNzA0MDAwMDAwfQ

Die direkte Verwendung der URL-Kodierung auf dem binären Token würde ein viel längeres Ergebnis erzeugen.