URL-Encoder / -Decoder & Query-String-Parser

encodeURIComponent() kodiert fast alles und ist damit das Richtige für ein einzelnes Stück einer URL — einen Query-Wert, ein Pfadsegment. encodeURI() lässt die reservierten Zeichen : / ? # & = + und sogar # unberührt und ist damit das Richtige für eine URL, die schon zusammengesetzt ist und nur noch von Leerzeichen und Nicht-ASCII-Zeichen befreit werden muss. Geben Sie eine ganze URL an encodeURIComponent, wird sie zu einem undurchsichtigen Block (https%3A%2F%2F…); geben Sie einen einzelnen Wert an encodeURI, wird ein darin enthaltenes & stillschweigend zum Parameter-Trennzeichen. Der Encode-Modus hier legt beides offen: Standard ist die Komponenten-Regel, und die Checkbox „Whole URL“ ist Byte für Byte encodeURI().

Beides ist korrekt — an unterschiedlichen Stellen. RFC 3986 kennt nur %20. Die +-Konvention kommt vom Absenden von HTML-Formularen (application/x-www-form-urlencoded) und gilt für Formular-Bodies und, aus langer Gewohnheit, für Query-Strings — weshalb URLSearchParams ein + als Leerzeichen dekodiert, es in einem Pfad aber unberührt lässt. Das heißt: %20 ist immer sicher, während + nur dann ein Leerzeichen ist, wenn der Erzeuger des Werts es so gemeint hat. Der Decode-Modus zeigt Ihnen, welche Konvention angewendet wurde, und lässt Sie umschalten — damit Sie „Ada+Lovelace“ den Namen von „Ada Lovelace“ den zwei Wörtern unterscheiden können.

Prozent-Kodierung ersetzt ein Byte durch ein % gefolgt von diesem Byte als zwei Hexadezimalstellen. Eine URL darf nur einen kleinen Satz von ASCII-Zeichen tragen, also wird alles andere — ein Leerzeichen, ein Akzent, ein Emoji oder ein reserviertes Zeichen, das als Daten benutzt wird — zuerst in UTF-8-Bytes umgewandelt und dann jedes Byte als %XX geschrieben. é sind zwei Bytes und wird daher zu %C3%A9. Dekodieren macht es umgekehrt: die Bytes sammeln und sie dann wieder als UTF-8 lesen.

Zweimal dekodieren. %2520 bedeutet, dass das % von %20 selbst zu %25 kodiert wurde — das passiert, wenn ein Client encodeURIComponent() auf einen bereits kodierten Wert anwendet, der klassische OAuth-redirect_uri-Fehler. Dieses Werkzeug erkennt das: Fügen Sie den Wert im Decode-Modus ein, und es meldet, dass der erste Durchgang noch Escapes enthält, zeigt, was ein zweiter Durchgang ergibt, und bietet eine Schaltfläche „Decode again“. Die eigentliche Lösung liegt weiter oben: genau einmal kodieren, und zwar in dem Moment, in dem der Wert in die URL gesetzt wird.

Weil die kodierten Bytes kein gültiges UTF-8 sind. %C3%A9 ist eine wohlgeformte Zwei-Byte-Sequenz und wird zu é; %E9 allein ist hingegen das Latin-1-Byte (ISO-8859-1) für é und in UTF-8 unzulässig — es wird daher zu U+FFFD, dem Ersatzzeichen. Dieses Werkzeug benennt die betroffenen Bytes, anstatt wie decodeURIComponent() einen URIError zu werfen. Das sagt Ihnen, dass der Wert aus der falschen Quellkodierung stammt, statt Sie rätseln zu lassen.

Kein Teil des URL-Standards legt fest, welcher gewinnt — deshalb wird hier jede Zeile aufgeführt und die späteren werden als Duplikate markiert. In der Praxis behalten PHP und Express den letzten Wert, Go’s r.URL.Query() liefert alle, ASP.NET verbindet sie mit Kommas, und Rails gruppiert sie nur, wenn der Schlüssel auf [] endet. Genau diese Uneinigkeit ist der Grund, warum ein Werkzeug alle Werte zeigen sollte, statt still einen auszuwählen.

Punycode ist die ASCII-Kodierung eines internationalisierten Domainnamens. DNS trägt nur ASCII-Labels, also wird münchen.example zu xn--mnchen-3ya.example umgewandelt, bevor überhaupt eine Auflösung stattfindet — und diese ASCII-Form muss auch ein TLS-Zertifikat treffen. Der Parser zeigt hier den umgewandelten Host mit dem von Ihnen eingegebenen Namen darunter, sodass Sie eine ähnlich aussehende Domain erkennen können. Absichtlich wandelt er Punycode nicht zurück nach Unicode: einen von Angreifern gelieferten Namen als schönes Unicode darzustellen, ist genau die Grundlage von Homograph-Phishing.

Der unreservierte Satz aus RFC 3986 §2.3: A–Z, a–z, 0–9 und die vier Zeichen - . _ ~. Diese sind überall sicher und dürfen niemals unnötig kodiert werden, denn %2D und - sind dieselbe URL, und ein erneutes Kodieren bricht Signaturverfahren, die den Rohstring hashen. Beachten Sie: encodeURIComponent() lässt außerdem ! ' ( ) * unberührt — ein Überrest des älteren „mark“-Satzes aus RFC 2396. RFC 3986 führt diese fünf als Sub-Delimiter, also kodiert der Komponenten-Modus hier sie und sagt Ihnen, wenn er vom Browser-Built-in abweicht.

Nicht mehr. HTML empfahl einmal, dass Server neben & auch ; als Parameter-Trennzeichen akzeptieren; dieser Hinweis wurde 2014 aus der Spezifikation entfernt. Browser und URLSearchParams haben es nie als Trennzeichen behandelt, also ist a=1;b=2 ein einzelner Parameter namens a mit dem wörtlichen Wert 1;b=2. Dieses Werkzeug verhält sich genauso und warnt, wenn es ein Semikolon sieht — denn ein altes Backend kann noch daran aufteilen und damit dem Browser davor widersprechen.

Ja — das gesamte Werkzeug ist eine statische Seite ohne Server dahinter. Parsen, Kodieren und Dekodieren laufen in Ihrem Browser-Tab, nichts wird hochgeladen, es gibt kein Logging und kein Konto. Das zählt hier mehr als bei den meisten Werkzeugen, denn Query-Strings sind genau der Ort, an dem Access-Tokens, signierte URLs, Session-IDs und E-Mail-Adressen landen. Wenn Sie eine zweite Meinung möchten: öffnen Sie beim Tippen das Netzwerk-Panel der Entwicklertools — es gibt keinen Request zu sehen.