URL kodieren

Eine URL besteht aus Teilen, und die Zeichen, die sie trennen — `/`, `?`, `&`, `=`, `#` — sind Struktur, wenn sie diese Aufgabe erfüllen, und Daten, wenn nicht. Eine ganze Adresse zu kodieren muss sie in Ruhe lassen, sonst ist sie keine Adresse mehr. Einen einzelnen Wert zu kodieren muss sie maskieren, sonst endet der Wert und etwas anderes beginnt.

Genau das ist der Unterschied zwischen `encodeURI` und `encodeURIComponent`, und darauf beruht der überwiegende Teil aller kaputten Weiterleitungsparameter im Web: ein `?return=https://example.com/a?b=c`, in dem das zweite Fragezeichen nie maskiert wurde, sodass alles dahinter zur äußeren URL gehört. Ergebnis ist ein Link, der im Test funktioniert, wo das Ziel keinen Query-String hat, und in der Produktion nicht, wo es einen hat.

Eine Prozentsequenz ist ein `%` gefolgt von zwei Hexziffern und bezeichnet ein Byte. Zeichen außerhalb von ASCII brauchen mehrere: `ü` ist `%C3%BC` und nicht `%FC`, weil UTF-8 es in zwei Bytes schreibt. Ein Emoji braucht vier Sequenzen.

Die alte Funktion `escape()` erzeugte `%FC` und ist genau deshalb abgekündigt — sie stammt aus der Zeit vor der Entscheidung, dass das Web UTF-8 spricht. Ihre Ausgabe begegnet einem noch in altem Code und in manchen Alt-Schnittstellen, wo sie auf allem außer einem Latin-1-Backend zum falschen Zeichen dekodiert. Hier ist durchgehend UTF-8 im Spiel.

`encodeURIComponent` lässt Ausrufezeichen, Apostroph, beide runden Klammern und Sternchen unmaskiert. RFC 3986 führt sie als reserviert, ein streng konformer Kodierer maskiert sie also — und die beiden sind sich damit bei fünf Zeichen uneinig, die in gewöhnlichem Text ständig vorkommen.

Auffallen tut das erst, wenn eine Signatur im Spiel ist. OAuth 1.0 und AWS Signature Version 4 bilden beide einen Hash über die kodierte Zeichenkette, ein einziger unmaskierter Apostroph ändert also den Hash und die Anfrage wird abgelehnt — mit einem Fehler über Zugangsdaten, der einen an völlig falscher Stelle suchen lässt. Die strenge Option hier maskiert alle fünf.

Beides begegnet einem, und es sind nicht dieselben Regeln. `%20` ist Prozentkodierung und überall in einer URL richtig. Das Pluszeichen stammt aus `application/x-www-form-urlencoded`, dem Format, in dem ein HTML-Formular absendet, wo ein Leerzeichen als `+` geschrieben wird — eine Konvention, die älter ist als die heutige Spezifikation und überlebt, weil Formulare es tun.

In einem Pfad ist `+` ein echtes Plus. In einem Query-String lesen die meisten Server es als Leerzeichen, weil die Formularkodierung das so sagt — ein echtes Plus in einem Query-Wert muss also `%2B` geschrieben werden oder es verschwindet. Dieser Kodierer erzeugt `%20`, was an beiden Orten eindeutig ist.

Eine bereits kodierte Zeichenkette erneut zu kodieren maskiert das `%` selbst, aus `%20` wird also `%2520`. Für keinen beteiligten Baustein ist das ein Fehler — es ist eine völlig gültige Kodierung des Literaltexts „%20“ —, und genau deshalb überlebt doppelte Kodierung bis zu dem Punkt, an dem eine Nutzerin `Hello%20world` in einer Überschrift sieht.

Das Erkennungszeichen ist ein `%25`, wo ein `%` stehen sollte. Wenn du eines siehst, kodiert irgendwo in der Kette etwas einen bereits kodierten Wert, meist weil ein Framework es für dich tut und eine Vorlage es noch einmal. Die Lösung ist, eine der beiden Stellen zu entfernen, und nicht, am Ende zweimal zu dekodieren.

Buchstaben, Ziffern und die vier Zeichen `-`, `_`, `.` und `~` heißen in RFC 3986 „unreserved“ und dürfen niemals maskiert werden. Ein Kodierer, der `%2E` statt eines Punkts erzeugt, ist nicht strenger, sondern falsch — manche Systeme normalisieren das zurück, andere nicht, und damit sind zwei URLs uneins, die dieselbe sein sollten.

Praktisch heißt das: Eine kodierte Zeichenkette, die auffällig viele Prozentsequenzen enthält, obwohl der Text hauptsächlich aus Buchstaben besteht, stammt meist aus einem überkodierenden Werkzeug. Das ist harmlos, bis eine Signatur oder ein Cache-Schlüssel darüber gebildet wird — dann ist es der Grund, warum zwei Systeme nicht zusammenfinden.

Alles nach dem `#` bleibt im Browser. Es steht in keiner Anfrage, erreicht keinen Server und taucht in keinem Zugriffsprotokoll auf. Das ist eine Eigenschaft von HTTP und keine Datenschutzfunktion, und es schneidet in beide Richtungen.

Wer einen Wert in den Anker kodiert, kodiert ihn für ein Skript im Browser und für sonst niemanden. Das ist der Grund, warum Single-Page-Anwendungen ihren Zustand dort ablegen — und warum der implizite OAuth-Fluss Tokens dort untergebracht hat, damit sie nicht von jedem Proxy dazwischen protokolliert werden.

Ein Hostname wird nicht prozentkodiert. `münchen.example` wird stattdessen nach Punycode umgesetzt — `xn--mnchen-3ya.example` —, was ein völlig anderes Verfahren mit eigenen Regeln ist. Ein Kodierer, der den Host wie einen Wert behandelt, erzeugt eine Adresse, die kein DNS auflöst.

Deshalb ist die Option „ganze URL“ hier keine Bequemlichkeit: Sie lässt den Host unberührt. Wer eine Adresse mit Umlauten im Namen hat, braucht ein Punycode-Werkzeug oder schlicht den Browser, der die Umsetzung beim Aufruf selbst erledigt.

Die Spezifikation nennt keine Grenze, die Praxis schon. Browser vertragen sehr viel, aber Server, Proxies und CDNs setzen eigene Obergrenzen — häufig acht Kilobyte für die Anfragezeile plus Header, und manche Weiterleitungsdienste deutlich weniger.

Kodierung verschärft das, weil sie verlängert: Jedes maskierte Zeichen wird zu drei, ein Umlaut zu sechs. Eine Adresse, die roh knapp unterhalb einer Grenze liegt, kann kodiert darüber liegen — und der Fehler kommt als abgeschnittene Anfrage oder als 414 zurück, was auf die Kodierung nicht offensichtlich hindeutet.

Werte sollten dort kodiert werden, wo sie in eine URL eingesetzt werden, und an keiner Stelle davor. Ein bereits kodierter Wert, der durch drei Schichten wandert, wird unterwegs mit ziemlicher Sicherheit noch einmal kodiert oder versehentlich dekodiert, und beides bemerkt niemand sofort.

In der Praxis heißt das: In der Datenbank steht der rohe Wert, im Template steht der Aufruf, der ihn kodiert. Wer stattdessen kodierte Werte speichert, hat den Fehler eingebaut, dass jede andere Verwendung — eine E-Mail, ein CSV-Export, eine API-Antwort — den Wert falsch ausliefert.

Was hier eingefügt wird, sind Suchbegriffe, Weiterleitungsziele, Kennungen und gelegentlich ein Token, das jemand gerade in eine Test-URL einbaut. Keines davon muss reisen, um maskiert zu werden.

Die Rechnung ist ein Funktionsaufruf des Browsers, und das Netzwerk-Panel zeigt beim Tippen nichts. Das ist auch der Unterschied zu den meisten Werkzeugen dieser Art: Sie schicken die Zeichenkette an einen Server, der dieselbe eingebaute Funktion aufruft — nur eben auf einem fremden Rechner mit einem Zugriffsprotokoll.