URL kodieren und dekodieren
URL-Encoder und -Decoder kodiert Text per Prozentkodierung und dekodiert ihn in Ihrem Browser. Der Modus ist wichtiger, als er aussieht: In einem Query-String ist ein Leerzeichen ein +, in einem Pfad ist es %20, und dekodiert man einen Formular-Body mit dem falschen davon, wird aus „a + b“ ein „a b“ – ganz ohne Fehlermeldung.
Wie funktioniert URL kodieren und dekodieren?
„URL-Kodierung“ bezeichnet drei verschiedene Kodierungen, und die falsche Wahl erzeugt einen Bug, der nie einen Fehler wirft.
Prozentkodierung ist nicht Form-Kodierung
Die Prozentkodierung nach RFC 3986 schreibt ein Leerzeichen als %20. Das application/x-www-form-urlencoded-Format – das ein Query-String und ein Formular-POST-Body tatsächlich verwenden – schreibt es als +, was bedeutet, dass ein literales Plus als %2B geschrieben werden muss. Dekodiert man einen Formular-Body mit decodeURIComponent, bleibt das + unangetastet – die Suche „a + b“ kommt also als „a + b“ an, wenn der Nutzer ein Plus getippt hat, und als „a+b“, wenn er Leerzeichen getippt hat. Eine der beiden Varianten ist falsch, und keine löst einen Fehler aus.
encodeURIComponent lässt fünf vom RFC reservierte Zeichen aus
!, ', (, ) und * sind von RFC 3986 reserviert und bleiben von encodeURIComponent unangetastet. Meistens harmlos; nicht harmlos, wenn eine Signatur über die kodierte Form berechnet wird – deshalb bringt jede AWS-SigV4- und OAuth-1.0a-Bibliothek ihren eigenen Encoder mit. Die strikte Option kodiert sie.
Jede URL-Komponente hat eigene Regeln
Ein Pfad darf / enthalten; ein Query-Wert darf kein unkodiertes & enthalten, sonst zerfällt er in zwei Parameter. Das ist der Unterschied zwischen Komponenten-Modus und Voll-URL-Modus: Der erste kodiert alles, was nicht unreserved ist, der zweite bewahrt die Zeichen, die einer URL ihre Struktur geben. Eine ganze URL mit encodeURIComponent zu kodieren erzeugt eine Zeichenkette, die keine URL mehr ist.
Doppelkodierung – und wie man sie sieht
%2520 ist ein Leerzeichen, das zweimal durch einen Encoder ging: das % von %20 wurde selbst als %25 kodiert. Für jemanden, der ein Log überfliegt, liest es sich als „%20“, und im dekodierten Wert erzeugt es ein literales %20. Das Tool zählt, wie viele Dekodier-Durchläufe die Eingabe übersteht – eine versehentlich zusätzliche Ebene ist damit sichtbar statt rätselhaft.
Das Zerlegen einer URL nutzt den Parser der Plattform
Die Aufschlüsselung der Komponenten stammt aus der eigenen URL-Implementierung des Browsers statt aus einem regulären Ausdruck – das URL-Parsing hat genug Randfälle (userinfo, IPv6-Literale, Standard-Ports, prozentkodierte Hosts), dass der WHATWG-Algorithmus, der bereits in der Plattform steckt, kürzer und korrekter ist als jedes Muster. Doppelte Query-Keys bleiben in ihrer Reihenfolge erhalten, weil viele APIs ihnen Bedeutung geben.
Eingabe
q=a + b
Kodiert
component: q%3Da%20%2B%20b form: q%3Da+%2B+b
Welche Optionen und Sonderfälle unterstützt URL kodieren und dekodieren?
| Parameter | Typ | Standard | Verhalten & Sonderfälle |
|---|---|---|---|
| Komponente | encodeURIComponent | Standard | Für einen einzelnen Query-Wert oder ein Pfadsegment. Kodiert alles außer A–Z a–z 0–9 - _ . ~ und den fünf Zeichen unten. |
| Vollständige URL | encodeURI | — | Für eine ganze URL. Behält : / ? # [ ] @ ! $ & ' ( ) * + , ; = bei, damit die URL eine URL bleibt. Der Komponentenmodus zerstört hier die Struktur. |
| Formular | x-www-form-urlencoded | — | Für einen Query-String oder einen POST-Body. Ein Leerzeichen wird +, ein literales + wird %2B. Korrektes Dekodieren erfordert, das + vor dem Percent-Decoding rückgängig zu machen, sonst wird aus einem literalen Plus ein Leerzeichen. |
| base64url | RFC 4648 §5 | — | Das URL-sichere Base64-Alphabet: - und _ statt + und /, ohne Padding. Genau das verwenden die JWT-Segmente. |
| RFC 3986 strikt | Boolesch | aus | Kodiert auch ! ' ( ) *, die encodeURIComponent unangetastet lässt. Nötig, wenn die kodierte Form in eine Signatur einfließt. |
| Alles kodieren | Boolesch | aus | Percent-kodiert jedes Byte, auch die unreservierten. Hässlich, gültig und gelegentlich das Einzige, was ein pingeliges Gateway akzeptiert. |
| Zeichensatz | UTF-8 | immer | Nicht-ASCII wird als seine UTF-8-Bytes kodiert, je eines als %XX – das erwarten alle aktuellen Browser und Server. |
| Fehlerhafte Eingabe | gemeldet | mit Position | decodeURIComponent wirft nur einen nackten URIError. Stattdessen wird die fehlerhafte Sequenz lokalisiert und benannt. |
Häufig gestellte Fragen
Warum ist mein Leerzeichen ein + statt %20?
Weil Sie im Formular-Modus sind, was für einen Query-String oder einen Formular-POST-Body korrekt ist – dieses Format definiert ein Leerzeichen als +. In einem Pfadsegment oder einem Fragment ist ein Leerzeichen %20 und ein + ein literales Plus. Beide Kodierungen sind korrekt; die falsche an der falschen Position zu verwenden ist es, was den Wert korrumpiert.
encodeURI oder encodeURIComponent?
encodeURIComponent für ein einzelnes Stück – einen Query-Wert, ein Pfadsegment, ein Fragment. encodeURI für eine ganze URL, die eine URL bleiben soll. Der Test ist einfach: Enthält der Text, den Sie kodieren, strukturelle Zeichen (ein ?, ein &, ein /) und sollen sie weiter funktionieren, brauchen Sie encodeURI; sollen sie zu Daten werden, brauchen Sie encodeURIComponent.
Was ist %2520 und wie habe ich es bekommen?
Ein Leerzeichen, zweimal kodiert. Der erste Durchlauf erzeugte %20; der zweite kodierte dieses % als %25 – heraus kam %2520. Meist bedeutet das, dass ein Wert vom Anwendungscode und dann noch einmal von einem Framework oder einem Proxy kodiert wurde. Der Tiefenzähler oben zeigt, wie viele Durchläufe Ihre Eingabe übersteht – so sehen Sie, ob eine Ebene zu viel ist.
Warum werden !'()* nicht kodiert?
encodeURIComponent lässt sie absichtlich aus, obwohl RFC 3986 sie reserviert. Fast immer harmlos – außer wenn die kodierte Zeichenkette die Eingabe für eine Signatur ist, wo Signierer und Prüfer Byte für Byte übereinstimmen müssen. Deshalb spezifizieren sowohl AWS SigV4 als auch OAuth 1.0a ihren eigenen Encoder. Schalten Sie in dieser Situation den strikten Modus ein.
Ist base64url dasselbe wie base64?
Derselbe Algorithmus, anderes Alphabet. base64 verwendet + und /, die in einer URL beide eine Bedeutung haben; base64url ersetzt sie durch - und _ und lässt das =-Padding weg, das in einem Query-String eine Bedeutung hat. Ein JWT besteht aus drei base64url-Segmenten, die durch Punkte verbunden sind – deshalb lässt sich ein JWT direkt in eine URL einfügen, ein base64-Blob nicht.
Wird meine Eingabe hochgeladen?
Nein. Kodieren und Dekodieren sind Zeichenketten-Operationen, die in Ihrem Browser laufen – öffnen Sie den Netzwerk-Tab und schauen Sie beim Tippen zu. Das ist hier relevant, weil URLs, die man dekodieren muss, häufig signierte Callback-URLs, OAuth-Redirects und Session-Tokens sind – also Zugangsdaten in einer Form, die harmlos aussieht.