URL Kodier- und Dekodierwerkzeug

Die URL-Kodierung (auch Prozent-Kodierung genannt) ist ein Mechanismus zur Umwandlung von Zeichen in ein Format, das sicher in einer URL übertragen werden kann. Da URLs nur bestimmte Zeichen aus dem ASCII-Zeichensatz enthalten dürfen, müssen andere Zeichen (wie Umlaute, Leerzeichen und Sonderzeichen) als %XX-Format kodiert werden, wobei XX der hexadezimale Wert des Zeichens ist. Beispiel: Ein Leerzeichen wird als %20 kodiert, und das Zeichen ö wird als %C3%B6 kodiert. URL-Encoding wandelt Zeichen in eine Form um, die sicher in URLs übertragen werden kann. Leerzeichen, Nicht-ASCII-Zeichen, Reserved Characters und Sonderzeichen werden je nach Kontext prozentkodiert. Wichtig ist die Unterscheidung zwischen kompletter URL, Pfadsegment, Query-Parameter und Fragment, weil nicht überall dieselben Zeichen maskiert werden sollen. Doppelte Kodierung oder fehlende Kodierung kann Links, Signaturen, API-Requests und Weiterleitungen beschädigen.

Die URL-Kodierung (Prozentkodierung) ist in RFC 3986 §2.1 definiert und wandelt Zeichen in das Format %XX um, wobei XX die zweistellige Großbuchstaben-Hexadezimaldarstellung des Bytewerts in UTF-8 ist. Die RFC definiert zwei Zeichenklassen: nicht reservierte Zeichen (A-Z a-z 0-9 - _ . ~), die niemals kodiert werden, und reservierte Zeichen (gen-delims : / ? # [ ] @ und sub-delims ! $ & ' ( ) * + , ; =), deren Kodierung vom Kontext abhängt — sie tragen in manchen URL-Komponenten strukturelle Bedeutung, sind in anderen jedoch Literaldaten. JavaScript stellt zwei integrierte Funktionen mit unterschiedlichem Geltungsbereich bereit. encodeURIComponent() kodiert jedes Zeichen außer A-Z a-z 0-9 - _ . ! ~ * ' ( ) — dies ist die richtige Wahl für die Kodierung einzelner Query-Parameterwerte, Pfadsegmente und Fragment-Identifikatoren. encodeURI() bewahrt zusätzlich die strukturellen Zeichen : / ? # [ ] @ ! $ & ' ( ) * + , ; = und ist dafür ausgelegt, vollständige URIs zu kodieren, ohne deren syntaktische Struktur zu verändern. Der entscheidende Unterschied besteht darin, dass encodeURIComponent() / und & kodiert, was eine URL zerstören würde, wenn es auf den gesamten String angewendet wird, während encodeURI() diese beibehält. Die Behandlung von Leerzeichen ist die häufigste Interoperabilitätsfalle. RFC 3986 schreibt %20 als kanonische Prozentkodierung für das Leerzeichen (U+0020) vor. Der MIME-Typ application/x-www-form-urlencoded (verwendet bei HTML-Formularübermittlungen seit HTML 4.01) kodiert Leerzeichen jedoch als +. Die beiden sind nicht austauschbar: Ein Server, der %20 erwartet, interpretiert + als Literalzeichen, und ein Server, der + erwartet, behandelt %20 als Prozentzeichen gefolgt von 20. Das Tool verwendet encodeURIComponent(), das %20 erzeugt und damit RFC 3986 entspricht. Benutzer, die x-www-form-urlencoded-Payloads dekodieren (aus POST-Bodies oder von Legacy-Middleware geparsten Query-Strings), sollten diesen Unterschied kennen. Die Behandlung von Mehrbytezeichen erfolgt automatisch, ist aber verständlich: Der Eingabestring wird zunächst in UTF-8-Bytes kodiert, dann wird jedes Byte einzeln prozentkodiert. Ein CJK-Zeichen wie 你 (U+4F60) belegt 3 UTF-8-Bytes (E4 BD A0) und ergibt %E4%BD%A0. Wenn der Server mit einem anderen Zeichensatz wie GBK parst, wird dasselbe Zeichen zu %C4%E3 (2 Bytes) kodiert, und das Dekodierungsergebnis wird unleserlich, sofern sich beide Seiten nicht auf UTF-8 geeinigt haben. Doppelkodierung ist ein weiterer häufiger Fehler: %2520 bedeutet ein literalen Prozentzeichen (%25) gefolgt von 20, was darauf hinweist, dass die Eingabe bereits prozentkodiert war und ein zweites Mal kodiert wurde. Der Dekodierungsmodus erkennt fehlerhafte Sequenzen (unvollständige %XX) und meldet den Fehler, anstatt stillschweigend Unsinn auszugeben.

• encodeURIComponent vs. encodeURI: encodeURIComponent kodiert / ? & # und ist korrekt für Query-Werte, Pfadsegmente und Fragmente; encodeURI bewahrt diese strukturellen Zeichen und ist korrekt für vollständige URLs — die Verwendung der falschen Funktion ist der häufigste URL-Kodierungsfehler.
• Reservierte Zeichenklassen gemäß RFC 3986: gen-delims (: / ? # [ ] @) tragen URL-Syntax; sub-delims (! $ & ' ( ) * + , ; =) können Trennzeichen oder Daten sein, je nach URL-Komponente — der Kontext bestimmt, ob ein reserviertes Zeichen prozentkodiert wird.
• Leerzeichenkodierung: Die kanonische Form gemäß RFC 3986 ist %20 (erzeugt von encodeURIComponent); application/x-www-form-urlencoded verwendet + (HTML-Formular-Standard) — die beiden sind semantisch inkompatibel, und ihre Vermischung zerstört serverseitige Parser.
• UTF-8-Multibyte-Kodierung: 你 (U+4F60) → UTF-8-Bytes E4 BD A0 → %E4%BD%A0 (3 prozentkodierte Oktette); dasselbe Zeichen unter GBK → %C4%E3 (2 Oktette) — die Einigung auf einen Zeichensatz zwischen Client und Server ist für Nicht-ASCII-Text zwingend erforderlich.
• Doppelkodierungs-Erkennung: %2520 wird zunächst zu %20 und dann zu Leerzeichen dekodiert — die Ausgabe des Dekodierungsmodus zeigt dieses Muster; fehlerhafte Sequenzen wie %ZZ oder %2 (unvollständig) werden erkannt und als Fehler gemeldet.
• IRI (RFC 3987): Internationalized Resource Identifiers erlauben Unicode-Zeichen direkt in URLs; Browser zeigen die dekodierte Form in der Adressleiste an, übertragen aber die prozentkodierte UTF-8-Form über das Netzwerk — der Kodierungsmodus des Tools zeigt, was tatsächlich über HTTP gesendet wird.
• decodeURIComponent-Fehlerbehandlung: Ein String mit einer unvollständigen Prozentsequenz (% gefolgt von weniger als 2 Hexadezimalziffern) löst einen URIError aus — das Tool kapselt den Aufruf in try/catch und zeigt die Fehlermeldung an, anstatt stillschweigend einen leeren String zurückzugeben.