Prozentkodierung

Prozentkodierung (auch URL-Kodierung genannt) ist der Mechanismus, mit dem URLs Zeichen darstellen, die in der URL-Grammatik nicht zulässig sind oder reservierte Bedeutungen haben. Definiert in RFC 3986 §2.

Das Schema: Jedes zu maskierende Byte wird als % gefolgt von zwei Hex-Ziffern geschrieben, die den Bytewert darstellen. Ein Leerzeichen wird zu %20. Ein Fragezeichen wird zu %3F. Ein Schrägstrich wird zu %2F. Das Doppelkreuz wird zu %23.

Bei Nicht-ASCII-Zeichen (Umlaute, Akzente, CJK, Emoji) wird das Zeichen zunächst UTF-8-kodiert in eine Bytefolge, dann wird jedes Byte prozentkodiert. Das einzelne Zeichen „é“ (U+00E9) wird in UTF-8 zu den Bytes 0xC3 0xA9, prozentkodiert als %C3%A9.

Drei Zeichenklassen, die man kennen sollte:

• Nicht reserviert — A-Z, a-z, 0-9 sowie -_.~. Werden nie maskiert.
• Reserviert — Zeichen mit syntaktischer Bedeutung (:/?#[]@!$'()*+,;=). Maskiert, wenn sie in Daten auftreten, die nicht als URL-Syntax interpretiert werden sollen.
• Sonstige — alles Übrige (Leerzeichen, Nicht-ASCII, Steuerzeichen). Immer maskiert.

Kodieren oder dekodieren Sie eine beliebige Zeichenkette in unserem URL-Encoder, der UTF-8 korrekt behandelt (einige ältere Implementierungen behandeln Zeichenketten als ISO-8859-1 und erzeugen für dieselbe Eingabe abweichende Ausgaben).

Die Fußnote zum Leerzeichen-als-Plus: Im Pfad und Fragment einer URL wird ein Leerzeichen als %20 kodiert. In der Query-Zeichenkette eines application/x-www-form-urlencoded-Bodys jedoch werden Leerzeichen als + kodiert – eine formularspezifische Konvention, die der modernen URL-Spezifikation vorausgeht. JavaScripts encodeURIComponent() gibt stets %20 aus; das ältere escape() (veraltet) gab + aus. Bei Formularübermittlungen und den meisten URL-Bibliotheken dekodieren beide Darstellungen korrekt zu einem Leerzeichen, doch ihre Vermischung in einer manuell zusammengebauten URL zerbricht Zeichenketten-Gleichheitsprüfungen. Der moderne Rat: Nutzen Sie die Standard-URL-APIs (WHATWG URLSearchParams in Browsern, url.URL in Node) und überlassen Sie der Implementierung die kontextgerechte Kodierung.

Doppelkodierung – der häufigste Produktionsfehler: Durchläuft ein Wert zwei Encoder ohne dazwischenliegenden Decoder, wird das ursprüngliche % aus dem ersten Durchgang zu %25, und der Nutzer sieht Kauderwelsch wie %2520 statt %20. Die Ursache ist fast immer eine Systemschicht, die annimmt, ihre Eingabe sei Klartext, obwohl sie bereits URL-kodiert ist. Die Lösung ist eine klare Grenze: Eingabe bleibt Klartext bis zum URL-Builder, ist nur in URL-Form prozentkodiert und wird in dem Moment, in dem sie den URL-Kontext verlässt, wieder zu Klartext dekodiert. Verwandt: UTF-8, ASCII. Referenz: RFC 3986 §2.1 — Percent-Encoding.

Durchgerechnetes Beispiel

Kodieren Sie die Suchanfrage café & thé in eine URL-Query-Zeichenkette. Schritt eins – jedes Zeichen in UTF-8: c a f é <space> & <space> t h é wird zu den Bytes 63 61 66 C3 A9 20 26 20 74 68 C3 A9. Schritt zwei – Prozentkodierungsregeln anwenden: nicht reservierte Zeichen (c a f t h) bleiben; Multibyte-UTF-8-Sequenzen und reservierte Zeichen (&) werden maskiert. Ergebnis: caf%C3%A9%20%26%20th%C3%A9. Vollständige URL: https://example.com/search?q=caf%C3%A9%20%26%20th%C3%A9. Auf der Empfangsseite dekodiert der Server, indem er beide Schritte umkehrt: jedes %XX durch seinen Bytewert ersetzen, um die UTF-8-Bytes zu erhalten, dann UTF-8 dekodieren, um café & thé wiederherzustellen. Behandelt der Server die Bytes als Latin-1 statt UTF-8, kommt „café“ als „café“ durch – der klassische Mojibake.

Wann und warum es zählt

Jede durch Zeichenkettenverkettung erstellte URL ist ein potenzieller Injection- oder Routing-Fehler. Ein vom Nutzer gelieferter Dateiname wie ../../../etc/passwd, roh in eine URL eingebettet, wird zu einem Path-Traversal-Versuch; prozentkodiert als ..%2F..%2F..%2Fetc%2Fpasswd ist er als einzelnes Segment sicher, kann aber auf der falschen Schicht dekodiert werden und das Traversal wieder einführen. Suchanfragen mit & oder # werden stillschweigend abgeschnitten, wenn sie nicht kodiert sind. Moderne HTTP-Frameworks (Express, FastAPI, ASP.NET) erledigen das automatisch, wenn Sie ihre Query-Parameter-Builder verwenden; die Fehler häufen sich bei handgebauten Redirect-URLs, Log-Korrelations-IDs und Generatoren signierter URLs, wo Entwickler Zeichenketten verketten. Die defensive Gewohnheit: niemals + zur Zeichenkettenverkettung beim Aufbau einer URL verwenden – immer über URLSearchParams oder das Äquivalent Ihres Frameworks gehen. Referenz: WHATWG URL Standard — Percent-encoded bytes.