Skip to main content

URL-Kodierung

Deutsch

URL-Zeichenketten kodieren oder dekodieren.

→ HTML-Entity-Kodierung→ Base64
Alle Berechnungen erfolgen lokal in Ihrem Browser. Es werden keine Daten an einen Server gesendet.

Die Ergebnisse dienen zur Information. Überprüfen Sie sie anhand anderer Quellen.

Ein polnischer Satz aus 17 Zeichen wird in einer URL zu 66

Prozentkodierung arbeitet auf Bytes, nicht auf Zeichen, und UTF-8 verbraucht für alles außerhalb von ASCII mehr als ein Byte. Jedes Byte wird zu drei Zeichen, akzentuierter Text bläht sich also heftig auf: zażółć gęślą jaźń hat 17 Zeichen, 26 Bytes und kodiert 66 Zeichen — Faktor 3,88.

So wird gerechnet

  • Kodiert Text prozentual für den sicheren Einsatz in URLs und dekodiert ihn zurück.
  • Kodiert zuerst nach UTF-8, woher die Größenzunahme stammt.
  • Unterscheidet das Kodieren einer ganzen URL vom Kodieren einer einzelnen Komponente — verschiedene Aufgaben mit verschiedenen sicheren Zeichenmengen.
jedes unsichere Byte → % gefolgt von zwei Hexziffern

UTF-8-Bytezahlen:
  ASCII        1 Byte  → 1 Zeichen unkodiert
  ł, ü         2 Bytes → 6 Zeichen   (%C5%82)
  €, 日        3 Bytes → 9 Zeichen   (%E2%82%AC)
  Emoji        4 Bytes → 12 Zeichen  (%F0%9F%98%80)

71 der 95 druckbaren ASCII-Zeichen bleiben unangetastet

Rechenbeispiel

Dieselben Zeichen kodiert und danach der klassische Doppelkodierungsfehler.

  1. a → a (1 Zeichen, unverändert)
  2. ł → %C5%82 (6 Zeichen)
  3. 😀 → %F0%9F%98%80 (12 Zeichen)
  4. "a b" → "a%20b"
  5. das erneut kodiert → "a%2520b"

Die zweite Kodierung macht aus dem % von %20 ein %25 und erzeugt %2520. Einmaliges Dekodieren liefert a%20b zurück, nicht a b — die Zeichenkette sieht dekodiert aus und ist weiterhin falsch, weshalb Doppelkodierungsfehler so lange überleben, bevor sie auffallen.

Das Ergebnis lesen

  • Ein Leerzeichen ist %20 im Pfad und + in formularkodierten Abfragedaten, und beide sind nicht austauschbar. Ein + als wörtliches Plus zu dekodieren, wo ein Leerzeichen gemeint war, oder umgekehrt, ist der zweithäufigste Kodierungsfehler nach der Doppelkodierung.
  • Kodieren Sie Komponenten, nicht ganze URLs. Eine vollständige URL durch die Komponentenkodierung zu schicken zerstört das :// und die Trenner; eine Komponente durch die URL-Kodierung zu schicken lässt & und = stehen, wodurch Benutzereingaben zusätzliche Parameter einschleusen können.
  • An der Aufblähung hängen praktische Grenzen. Server und Proxys kappen URLs häufig bei etwa 2.000 Zeichen, eine Abfragezeichenkette mit akzentuiertem Text stößt also um ein Vielfaches früher an diese Decke, als die Zeichenzahl vermuten lässt.
  • Kodierung ist kein Escaping für andere Kontexte. Eine prozentkodierte Zeichenkette ist in einer URL sicher und sagt nichts über Sicherheit in HTML, SQL oder einer Shell — jedes Ziel braucht seine eigene Kodierung, angewandt am Ort der Verwendung.

Häufige Fragen

Warum wurde mein Text zu %2520?
Er wurde zweimal kodiert. Der erste Durchgang machte aus einem Leerzeichen %20; der zweite sah das % als gewöhnliches Zeichen und kodierte es als %25, womit %2520 entstand. Dekodieren Sie zweimal, um das Original zurückzubekommen, und beheben Sie dann die Schicht, die überflüssig kodiert.
Sollte ein Leerzeichen %20 oder + sein?
%20 überall außer in formularkodierten Abfragezeichenketten, wo + die historische Konvention und weiterhin verbreitet ist. Dort dekodieren beide zu einem Leerzeichen, aber nur %20 ist in einem Pfadsegment korrekt.

Quellen