URL dekodieren

Dekodieren ist keine Nachschlagetabelle von `%41` zu `A`. Jede Sequenz bezeichnet ein Byte, und die Bytes bilden zusammen UTF-8-Zeichen — `%C3%BC` ist also ein einzelnes `ü` aus zwei Sequenzen, und ein Emoji besteht aus vier. Ein Dekodierer, der Sequenz für Sequenz übersetzt, erzeugt zwei Mojibake-Zeichen, wo eines stehen sollte.

Deshalb lässt sich eine unvollständige Sequenz auch nicht einfach überspringen. `%E0%A4` sind die ersten zwei Bytes eines Drei-Byte-Zeichens; es gibt keine richtige Ausgabe, nur eine Vermutung. Diese Seite meldet das als fehlerhaft, statt zu raten — der Unterschied zwischen dem Wissen, dass die Eingabe abgeschnitten war, und dem stillen Glauben an eine falsche Antwort.

Es gibt keine Regel, die sie aus der Zeichenkette allein auflöst. `application/x-www-form-urlencoded` — das, was ein HTML-Formular absendet und was die meisten Query-Strings in der Praxis sind — schreibt ein Leerzeichen als `+`. Die Prozentkodierung selbst kennt diese Regel nicht, in einem Pfad ist `+` also schlicht ein Pluszeichen.

Dieselben acht Zeichen dekodieren also auf zwei Arten, je nachdem, woher sie stammen, und nur du weißt welche. Deshalb wird die Einstellung angeboten statt angenommen. Bei einem Query-String ist „Leerzeichen“ fast immer richtig; bei einem Pfad oder einem Wert, der legitim ein Plus enthalten kann — eine Telefonnummer, eine Suche nach `C++` —, ist es das nicht.

Enthält das Ergebnis noch Prozentsequenzen, war der Text zweimal kodiert und du hast eine Schicht abgetragen. Das Erkennungszeichen ist `%2520`: Das ist ein `%20`, dessen `%` selbst als `%25` kodiert wurde. Einmal dekodieren gibt `%20`, noch einmal gibt das Leerzeichen.

Es lohnt sich, das zu bemerken statt einfach zweimal zu dekodieren, denn doppelte Kodierung ist weiter oben ein Fehler — meist ein Framework, das einen Wert kodiert, und eine Vorlage, die es noch einmal tut. Für die Nutzerin sichtbar wird es als `Hello%20world` in einem Seitentitel, und bis dahin liegen mehrere Systeme zwischen Ursache und Wirkung.

Das ist der häufigste Grund, hier zu sein. Ein Zugriffsprotokoll oder ein Analytics-Export speichert die vollständige Anfragezeile, und jede URL, die selbst ein Parameter war — ein Weiterleitungsziel, ein Callback, ein Referrer —, kommt einmal für sich kodiert an und ein zweites Mal für die, in der sie steckt.

Die äußere Schicht zu dekodieren macht die innere URL lesbar; noch einmal zu dekodieren macht deren eigene Parameter lesbar. Ein drittes Mal sollte man nicht aus Gewohnheit dekodieren: Dann dekodiert man Sequenzen, die im Original wörtlicher Text waren, und macht aus einem `%` in jemandes Suchbegriff etwas anderes.

Die Meldung heißt, dass die Bytes, die deine Prozentsequenzen ergeben, keine gültigen UTF-8-Zeichen bilden. Die häufigste Ursache ist eine abgeschnittene Kopie mitten in einem Mehrbyte-Zeichen; die zweithäufigste ist etwas Altes, das in Latin-1 kodiert hat.

Im zweiten Fall gibt es keine richtige Antwort, sondern nur eine Entscheidung darüber, welche Kodierung gemeint war — und diese Seite trifft sie nicht für dich. Das ist bewusst: Ein Dekodierer, der stillschweigend auf Latin-1 ausweicht, liefert lesbaren Text, der an einzelnen Stellen falsch ist, und das ist die unangenehmste Art von Fehler.

Prozentkodierung verlängert: Aus einem Zeichen werden drei, aus einem Umlaut sechs. Dekodieren kehrt das um, und eine lange Kette aus Sequenzen schrumpft dabei erheblich — eine kodierte URL von vierhundert Zeichen kann als hundertzwanzig zurückkommen.

Das ist kein Datenverlust, sondern der Grund, warum überhaupt kodiert wurde. Auffällig wird es nur, wenn jemand die Länge als Prüfung benutzt hat: Ein Feld, das die kodierte Form gerade noch fasst, fasst die dekodierte mühelos, aber umgekehrt gilt das nicht.

Ein Anker wird nie an den Server geschickt — er bleibt vollständig im Browser. Wer eine URL aus einem Zugriffsprotokoll dekodiert und sich wundert, warum der Anker fehlt, sucht nach etwas, das dort nie war.

Das ist auch der Grund, warum Analytics-Werkzeuge den Anker nur kennen, wenn ein Skript im Browser ihn ausdrücklich meldet. Zwei Datenquellen über dieselben Aufrufe können sich hier also legitim unterscheiden, ohne dass eine von beiden falsch wäre.

Eine dekodierte Zeichenkette ist roher, unkontrollierter Text. Sie in eine Seite, ein Protokoll oder eine Datenbankabfrage einzusetzen, ohne sie für das jeweilige Ziel zu behandeln, ist genau der Weg, auf dem aus einem Query-Parameter ein Cross-Site-Scripting oder ein manipulierter Log-Eintrag wird.

Diese Seite ist ein Lesewerkzeug für Menschen. Wer dekodierte Werte weiterverarbeitet, braucht danach die zum Ziel passende Maskierung — HTML-Sonderzeichen für eine Seite, Parameterbindung für eine Datenbank —, und das ist ein eigener Schritt und nicht das Gegenteil von Dekodieren.

`%3A` und `%3a` bezeichnen dasselbe Byte, und jeder Dekodierer nimmt beide. RFC 3986 empfiehlt Großbuchstaben, und die meisten Kodierer erzeugen sie auch, aber verbindlich ist es nicht.

Relevant wird es nur beim Vergleich zweier URLs als Zeichenketten — etwa als Cache-Schlüssel oder in einer Signatur. Zwei Adressen, die sich nur in der Schreibweise ihrer Hexziffern unterscheiden, sind dieselbe Adresse und zwei verschiedene Zeichenketten, und das ist eine der stilleren Ursachen für einen Cache, der nie trifft.

Ein Query-String wird protokolliert. Er steht im Zugriffsprotokoll jedes Servers und jedes Proxys, den die Anfrage passiert hat, im Verlauf des Browsers, im Referrer-Header an die nächste Seite und häufig in einem Analytics-Datensatz. Nichts daran ist flüchtig.

Ein Token, ein Zurücksetzungscode, eine Sitzungskennung oder eine E-Mail-Adresse in einem Query-String ist damit an mehreren Stellen aufgezeichnet worden, die niemand beabsichtigt hat. Es passiert ständig — Links zum Zurücksetzen von Passwörtern sind der Klassiker —, und ein dekodierter Query-String ist oft der Moment, in dem es jemandem auffällt.

URLs aus Logs tragen Sitzungskennungen, Tokens an Stellen, an denen sie nicht sein sollten, Suchbegriffe und oft genug eine E-Mail-Adresse. Das ist dieselbe Kategorie wie die Tokens auf der Base64-Seite und verdient dieselbe Behandlung.

Hier wird nichts hochgeladen. Das Dekodieren sind ein paar Zeilen Rechnerei in der Seite, die du gerade liest, und das Netzwerk-Panel ist die Art, das zu bestätigen, statt einem Satz auf einer Marketingseite zu glauben.