URL kodieren und dekodieren
Alle drei Varianten der Prozentkodierung nebeneinander, damit du siehst, welche du willst.
Drei Regeln, und die falsche zu wählen ist der Fehler
Prozentkodierung ersetzt ein Zeichen durch % gefolgt von seinem Bytewert in Hexadezimal. Einfach genug. Ärger macht, dass es drei verschiedene Auffassungen darüber gibt, welche Zeichen ersetzt gehören — und sie widersprechen sich genau bei den Zeichen, auf die es ankommt.
| Regel | Maskiert / ? & = # | Leerzeichen wird | Verwenden für |
|---|---|---|---|
encodeURIComponent | Ja | %20 | Einen Wert, der in eine URL eingesetzt wird |
encodeURI | Nein | %20 | Das Aufräumen einer vollständigen URL |
| Formularkodierung | Ja | + | Das, was ein HTML-Formular sendet |
Genau deshalb zeigt das Werkzeug alle drei zugleich. Sie nebeneinander zu lesen geht schneller, als abstrakt zu entscheiden, welche gemeint war.
Der Fehler, den das verhindert
Angenommen, ein Suchwert lautet coffee & cake. Als Komponente kodiert wird daraus coffee%20%26%20cake, und die URL ist:
/search?q=coffee%20%26%20cakeEin Parameter, Wert unversehrt. Mit encodeURI kodiert bleibt das kaufmännische Und es selbst:
/search?q=coffee%20&%20cakeJetzt sieht der Server zwei Parameter — q ist „coffee “, und es gibt einen zweiten, leeren namens „ cake“. Nichts wirft einen Fehler. Die Suche liefert einfach stillschweigend das Falsche, und das ist die Art Fehler, die ein Review übersteht, weil die URL in Ordnung aussieht.
Das Plus, das kein Plus ist
Die andere verlässliche Verwirrungsquelle. In formularkodierten Daten bedeutet + ein Leerzeichen, und ein echtes Pluszeichen muss %2B heißen. C%2B%2B nach der Formularregel dekodiert ergibt also C++, C++ dekodiert dagegen C — plus zwei Leerzeichen, und der Sprachname ist weg.
Am härtesten trifft das Telefonnummern. +44 20 7946 0958, über ein Formular abgeschickt und mit der falschen Regel dekodiert, wird zu 44 20 7946 0958, verliert also die Ländervorwahl — und nirgends meldet etwas einen Fehler.
Was Sie statt Handarbeit tun sollten
Bauen Sie Query-Strings in JavaScript mit URLSearchParams, statt sie zusammenzusetzen. Es wendet je Wert die richtige Regel an und kommt mit wiederholten Schlüsseln zurecht:
const url = new URL('https://example.com/search');
url.searchParams.set('q', 'coffee & cake');
url.searchParams.set('page', '2');
// https://example.com/search?q=coffee+%26+cake&page=2Jede andere Sprache hat eine Entsprechung, und jede davon ist verlässlicher, als Zeichen für Zeichen zu entscheiden. Diese Seite ist für die Fälle, in denen Sie eine URL lesen, die Ihnen jemand geschickt hat, oder eine debuggen, bei der schon etwas schiefging.
Eine kodierte URL lesen
Ein paar Sequenzen sollte man auf den ersten Blick erkennen, weil sie in Logs ständig auftauchen:
| Sequenz | Zeichen | Warum es zählt |
|---|---|---|
%20 | Leerzeichen | Mit Abstand die häufigste |
%2F | / | Ein kodierter Schrägstrich im Pfad ist oft ein Traversal-Versuch |
%3A | : | Üblich in kodierten URLs innerhalb von Weiterleitungsparametern |
%25 | % | Doppelte Kodierung zeigt sich als %2520 |
%00 | Null | Fast nie legitim |
Besonders %2520 sollte man kennen: Es ist ein %20, das ein zweites Mal kodiert wurde. Meist heißt das, ein Wert lief durch zwei Schichten, die ihn beide kodiert haben — die Signatur einer Weiterleitungskette oder eines Proxys, der das Falsche tut.
Verwandt
Um Bytes zu kodieren statt Text zu maskieren, ist Base64 die andere Aufgabe. Entpuppt sich der dekodierte Wert als JSON, liest ihn der Formatter, und ist es ein Token, der JWT-Decoder.
Fragen zur Kodierung
Was ist der Unterschied zwischen encodeURI und encodeURIComponent?
encodeURIComponent maskiert die Zeichen mit struktureller Bedeutung in einer URL — / ? & = # : und andere —, weil es davon ausgeht, dass Sie einen Wert kodieren, der in eine URL eingesetzt wird. encodeURI lässt sie stehen, weil es annimmt, Sie übergäben ihm eine ganze URL, die nur aufgeräumt werden soll. Einen Query-Parameter mit encodeURI zu kodieren ist der klassische Fehler: Ein & im Wert überlebt und teilt Ihren Parameter stillschweigend in zwei.
Warum ist ein Leerzeichen mal %20 und mal +?
Beides ist im jeweiligen Zusammenhang richtig. %20 ist die allgemeine Prozentkodierung für ein Leerzeichen und funktioniert überall in einer URL. Die Konvention mit + stammt aus application/x-www-form-urlencoded, dem Format, in dem HTML-Formulare abschicken: Dort bedeutet + ein Leerzeichen, und ein echtes Pluszeichen muss als %2B geschrieben werden. Ein Leerzeichen im Pfad ist also %20, eines in abgeschickten Formulardaten ein +. Dekodiert man Formulardaten nach der falschen Regel, wird jedes Pluszeichen im Text der Nutzer zu einem Leerzeichen.
Ich bekomme einen „URI malformed“-Fehler. Woran liegt das?
An einem Prozentzeichen, auf das nicht zwei Hexadezimalziffern folgen. Meist ist es ein wörtliches % in einem Text, das nie kodiert wurde — ein Rabattcode wie „50% off“ genügt, weil %20 als Escape-Sequenz gelesen wird und %off ungültig ist. Ein wörtliches Prozentzeichen muss %25 geschrieben werden. Die andere Ursache ist doppeltes Dekodieren: Wer einmal Kodiertes zweimal dekodiert, trifft irgendwann auf ein %, das bleiben sollte.
Soll ich die ganze URL kodieren oder nur die Werte?
Praktisch immer nur die Werte. Bauen Sie die URL strukturell auf und kodieren Sie jeden Parameter beim Einsetzen — in JavaScript erledigt das URLSearchParams, zuverlässiger als Handarbeit. Eine vollständige URL zu kodieren ergibt nur Sinn, wenn Ihnen eine bereits fehlerhafte übergeben wurde und Sie sie flicken.
Macht das Kodieren einer URL sie sicher?
Nein. Prozentkodierung betrifft Syntax, nicht Sicherheit: Sie stellt sicher, dass ein Wert die Einbettung in eine URL übersteht, ohne deren Struktur zu verändern. Wohin die URL zeigt, ändert sie nicht, und ein Schutz gegen Injection ist sie auch nicht — ein für die URL korrekt kodierter Wert bleibt gefährlich, wenn er später ohne die dort passende Maskierung in HTML oder SQL eingesetzt wird.
Zuletzt geprüft . Etwas veraltet gefunden? Sagen Sie uns Bescheid.