URL-Encoder / -Decoder

Wozu Prozentkodierung dient

Eine URL darf nur einen kleinen Zeichenvorrat enthalten: die Buchstaben A–Z und a–z, die Ziffern, eine Handvoll Zeichen wie - . _ ~ sowie eine Menge reservierter Zeichen, die der Adresse ihre Gestalt geben — / ? # & = : @ und einige weitere. Alles andere, vom Leerzeichen über ein hebräisches Wort bis zum Emoji, muss indirekt dargestellt werden. Die Prozentkodierung ist diese Darstellung: Das Zeichen wird in seine UTF-8-Bytes umgewandelt, und jedes Byte wird als Prozentzeichen mit zwei Hexadezimalziffern geschrieben. Aus einem Leerzeichen wird %20, aus א wird %D7%90.

Die reservierten Zeichen sind der interessante Fall. Sie sind in einer URL erlaubt, bedeuten aber etwas Strukturelles: ? eröffnet die Query, & trennt Parameter, = trennt einen Schlüssel von seinem Wert. Gehört eines dieser Zeichen zu Ihren Daten statt zur Struktur, muss es kodiert werden — sonst liest der Parser auf der Gegenseite es als Satzzeichen und zerteilt Ihren Wert an der falschen Stelle.

Komponente oder ganze URL — die Unterscheidung, die Links zerstört

Das ist die häufigste Quelle von URL-Fehlern, und deshalb bittet dieses Werkzeug Sie, einen Bereich zu wählen, statt zu raten.

• Der Komponentenbereich maskiert auch die Trennzeichen: / ? : @ & = + $ , und #. Nutzen Sie ihn für ein einzelnes Datum — einen Suchbegriff, ein Weiterleitungsziel, ein Token —, das in eine größere URL eingesetzt wird.
• Der Bereich „ganze URL“ lässt diese Trennzeichen unangetastet und maskiert nur, was tatsächlich unzulässig ist, etwa Leerzeichen und Nicht-ASCII-Text. Nutzen Sie ihn, wenn Sie eine vollständige, bereits korrekt strukturierte Adresse haben, die nur aufgeräumt werden muss.

In beiden Richtungen falsch zu liegen zerstört etwas. Kodieren Sie eine ganze URL im Komponentenbereich, werden aus jedem Schrägstrich und Fragezeichen %2F und %3F — heraus kommt eine einzige unbrauchbare Zeichenkette. Kodieren Sie einen einzelnen Wert im Bereich „ganze URL“, überlebt ein Und-Zeichen darin als Trennzeichen: Aus einer Suche nach „Katzen & Hunde“ werden stillschweigend zwei Parameter, und die zweite Hälfte Ihres Werts verschwindet.

// Der Wert enthält ein Trennzeichen, muss also maskiert werden:
const q = 'cats & dogs'
`/search?q=${encodeURIComponent(q)}`  // /search?q=cats%20%26%20dogs
`/search?q=${encodeURI(q)}`           // /search?q=cats%20&%20dogs  ✗

// Noch besser: die Plattform zusammensetzen lassen
const url = new URL('https://example.com/search')
url.searchParams.set('q', 'cats & dogs')

Diesen letzten Ansatz sollte man sich zur Gewohnheit machen. URL und URLSearchParams stecken in jedem Browser und in Node und wenden auf jeden Teil die richtige Kodierung an — das nimmt Ihnen die Entscheidung ab, statt Sie zu zwingen, es jedes Mal von Hand richtig zu treffen.

Warum ein Leerzeichen mal + und mal %20 ist

Hier wirken zwei verschiedene Spezifikationen, und sie sind sich bei genau einem Zeichen uneinig. RFC 3986, der URLs allgemein regelt, kodiert ein Leerzeichen als %20. Das ältere Format application/x-www-form-urlencoded — das, was HTML-Formulare absenden und wonach deshalb die meisten Query-Zeichenketten aussehen — kodiert es als +.

Die Falle: decodeURIComponent setzt nur die erste Regel um. Geben Sie ihm hello+world, bekommen Sie hello+world zurück, Plus inklusive — kein Fehler, keine Warnung, nur ein subtil falscher Wert. Deshalb bietet dieses Werkzeug die Option „+ als Leerzeichen behandeln“ und weist darauf hin, wenn Ihre Eingabe ein Plus enthält, während die Option aus ist.

Beachten Sie: URLSearchParams, das die Aufschlüsselungstabelle unter dem Werkzeug speist, folgt den Formularregeln und wandelt + sehr wohl in ein Leerzeichen. Dieselbe Query-Zeichenkette kann sich also je nach genutzter API unterschiedlich dekodieren — absichtlich, und in beiden Fällen korrekt.

Eine Folge, die man sich merken sollte: Gehört ein Plus wirklich zu Ihren Daten — eine Telefonnummer, ein Filterausdruck —, muss es als %2B kodiert werden. Ein wörtliches + in einer Query-Zeichenkette ist bestenfalls mehrdeutig und wird von den meisten Parsern als Leerzeichen gelesen.

Eine URL lesen

Fügen Sie eine absolute URL ein, und das Werkzeug zerlegt sie in ihre Teile. Es lohnt sich, deren Namen zu kennen, denn Fehlermeldungen und Dokumentation setzen das Vokabular voraus:

• Schema — https, mailto, ftp. Alles vor dem Doppelpunkt, und das, was über die Deutung des Rests entscheidet.
• Benutzerinfo — ein optionales user:password vor dem Host. Nach wie vor zulässig und nach wie vor eine schlechte Idee: Sie reist bei jeder Anfrage mit und landet in Protokollen, im Browserverlauf und in Referrer-Headern.
• Host — der Domänenname oder die IP-Adresse. Alles danach behandelt dieser Server, nicht das Netzwerk.
• Port — meist abwesend, weil 443 für https und 80 für http mitgedacht sind.
• Ursprung — Schema, Host und Port zusammen. Das ist die Einheit, auf der die Sicherheit des Browsers aufbaut: Same-Origin-Policy, CORS und der Geltungsbereich von Cookies vergleichen Ursprünge, nicht Pfade.
• Pfad — der Teil nach dem Host und vor einem ? oder #.
• Query — die Schlüssel/Wert-Paare nach dem ?, getrennt durch &.
• Fragment — alles nach dem #. Als Einziges wird es nie an den Server gesendet; der Browser behandelt es vollständig allein.

Dieses Detail zum Fragment wiegt schwerer, als es klingt. Weil es den Browser nie verlässt, ist alles nach einem # für Serverprotokolle unsichtbar — weshalb manche Single-Page-Anwendungen es historisch fürs Routing nutzten, und weshalb man dort nicht suchen sollte, wenn man eine nie angekommene Anfrage debuggt.

Zum Schluss eine Warnung, was Kodierung nicht leistet. Prozentkodierung macht Text sicher transportierbar innerhalb einer URL; sie ist weder Bereinigung noch Sicherheitsmaßnahme. Einen Wert zu kodieren macht ihn nicht sicher für die Einbettung in HTML, SQL oder einen Shell-Befehl, und das Dekodieren nicht vertrauenswürdiger Eingaben kann Zeichen zutage fördern — Pfadtrenner, Nullbytes —, die die kodierte Form verbarg. Prüfen Sie, was ein Wert ist, getrennt davon, wie er kodiert reist.

Die eingegebene Adresse ist nicht immer die gesendete

Bevor eine URL irgendwohin geht, wird sie normalisiert, und das Umschreiben geschieht still. Dieses Werkzeug zeigt das Ergebnis, sobald es von der Eingabe abweicht, denn diese Zeichenkette — nicht die getippte — erreicht den Server und erscheint im Protokoll:

HTTPS://Example.COM:443\a\b     getippt
https://example.com/a/b         gesendet

Dort griffen vier verschiedene Regeln. Schema und Host werden kleingeschrieben, da beide nicht zwischen Groß- und Kleinschreibung unterscheiden. Der Port entfällt, weil 443 der Standard für https ist. Die Backslashes werden zu Schrägstrichen, eine Kompatibilitätsregel, die alle überrascht, die Pfade im Windows-Stil schreiben. Und ein leerer Pfad wäre zu einem einzelnen Schrägstrich geworden. Nichts davon ist ein Fehler, aber wer zwei URLs auf Gleichheit prüft oder eine gegen eine Positivliste abgleicht, muss die normalisierten Formen vergleichen, sonst kommt die falsche Antwort heraus.

Auch ein Hostname mit Nicht-ASCII-Zeichen wird umgeschrieben, in eine ASCII-Form, die mit xn-- beginnt und Punycode heißt. Das Werkzeug zeigt beide Richtungen: den lesbaren Namen und den, der tatsächlich reist. Das lohnt einen Blick statt eines Überspringens, denn zwei verschiedene Unicode-Namen können auf dem Bildschirm identisch aussehen — ein lateinisches „a“ und ein kyrillisches „а“ sind verschiedene Zeichen — und dabei völlig unterschiedlichen Punycode ergeben. Die ASCII-Formen zu vergleichen ist die einzige verlässliche Art, ein solches Paar auseinanderzuhalten.

Eines wird nie normalisiert: ein wiederholter Query-Parameter. ?tag=a&tag=b zu schreiben ist völlig zulässig, und der Standard sagt nicht, was es bedeutet — also hat jeder Stack seine eigene Antwort gewählt. PHP behält den letzten Wert, Express sammelt sie in einem Array, viele Frameworks und URLSearchParams.get nehmen den ersten. Das Werkzeug markiert wiederholte Schlüssel, statt sie kommentarlos zweimal aufzuführen, denn der daraus folgende Fehler — ein Wert, der in einem Dienst funktioniert und im nächsten verschwindet — ist beim Lesen wirklich schwer zu erkennen.