Text live URL-kodieren und dekodieren, URLs parsen und Sonderzeichen nachschlagen.
| Protokoll | {{ parsedUrl.protocol }} |
| Host | {{ parsedUrl.host }} |
| Port | {{ parsedUrl.port }} |
| Pfad | {{ parsedUrl.pathname }} |
| Hash / Fragment | {{ parsedUrl.hash }} |
| Parameter | Wert |
|---|---|
{{ p.key }} |
{{ p.value }} |
| Zeichen | Kodiert | Kategorie | Beschreibung |
|---|---|---|---|
{{ r.char }} |
{{ r.encoded }} |
{{ r.category }} | {{ r.desc }} |
URL-Kodierung (auch Percent-Encoding genannt) wandelt Sonderzeichen in ein Format um, das sicher in URLs übertragen werden kann. Dabei wird jedes nicht erlaubte Zeichen durch ein Prozentzeichen (%) gefolgt von zwei hexadezimalen Ziffern ersetzt, z.B. wird ein Leerzeichen zu %20. Dies ist in RFC 3986 definiert und sorgt dafür, dass URLs universell interpretiert werden können.
URL-Kodierung ist immer dann notwendig, wenn Sonderzeichen, Umlaute, Leerzeichen oder nicht-ASCII-Zeichen in einem URL-Parameter, Pfad oder Fragment vorkommen. Browser kodieren URLs oft automatisch, aber bei der manuellen Erstellung von API-Aufrufen, Redirect-URLs oder Tracking-Links muss die Kodierung explizit erfolgen.
encodeURIComponent() für einzelne Parameter-Werte, encodeURI() für ganze URLs.%2520 statt %20) sind ein häufiger Fehler — kodiere nur einmal.Percent-Encoding — auch URL-Encoding genannt — ist in RFC 3986 (Uniform Resource Identifier, 2005) standardisiert. Es ersetzt unsichere oder reservierte Zeichen durch ein Prozentzeichen gefolgt vom zweistelligen hexadezimalen Bytewert. Aus einem Leerzeichen (Byte 0x20) wird %20, aus dem deutschen u-Umlaut (UTF-8: 0xC3 0xBC) wird %C3%BC. Die Regel unterscheidet zwischen unreserved Zeichen (A-Z, a-z, 0-9, sowie - . _ ~) die unverandert bleiben, und reserved Zeichen (: / ? # [ ] @ ! $ & ' ( ) * + , ; =), die je nach Position kodiert werden mussen oder nicht.
Verwirrend ist, dass JavaScript zwei verschiedene Encoding-Funktionen anbietet: encodeURI() belasst URL-Strukturzeichen wie / ? & #, weil sie als Trenner gebraucht werden; encodeURIComponent() hingegen kodiert alles ausser den unreserved Zeichen. Faustregel: Wenn du eine komplette URL kodierst, nutze encodeURI; wenn du einen einzelnen Query-Parameter kodierst (z.B. den Wert hinter ?q=), nutze encodeURIComponent. Falsche Wahl fuhrt zu klassischen Bugs: ?redirect=https://example.com wird ohne Encoding zerlegt und der zweite URL-Pfad unterbricht den ersten.
Eine besondere Klippe ist das Plus-Zeichen +. In URL-Pfaden steht es fur sich selbst, im Query-String aber bedeutet es traditionell ein Leerzeichen (Erbschaft aus dem alten application/x-www-form-urlencoded Format, RFC 1866). Deswegen wird ein Plus innerhalb eines Query-Wertes oft als %2B kodiert. Server, die Query-Strings strikt nach RFC 3986 parsen, interpretieren + als Leerzeichen — Server, die HTML-Forms parsen, ebenso. Das ist auch der Grund, warum E-Mail-Adressen mit Plus-Aliasen ([email protected]) bei manchen Anbietern in URLs Probleme machen. Eine weitere haufige Verwirrung betrifft das Doppelkreuz (#): es markiert den Fragment-Identifier, der ausschliesslich client-seitig verarbeitet wird und nie an den Server gesendet wird. Wer URLs in Server-Logs analysiert, sieht den Hash-Teil nie — das ist ein Sicherheits-Feature, kein Bug. Single-Page-Apps nutzten das fruher (/#/route), heute wird Hash-Routing durch HTML5 History-API ersetzt.
So vermeidest du die haufigsten URL-Encoding-Fehler:
hash & salt.hash%20%26%20salt. Leerzeichen wird zu %20, Ampersand zu %26.?q=hash%20%26%20salt — funktioniert auch in Browser-Adressleiste.Typische Zeichen und ihr percent-encoded Aquivalent:
" " → %20 — der haufigste Fall.+ → %2B (in Query-Werten zwingend, sonst wird es als Leerzeichen interpretiert).u (u-Umlaut) → %C3%BC — zwei Bytes pro Zeichen.(grinning face) U+1F600 → %F0%9F%98%80 — vier Bytes in UTF-8./ → %2F (nur wenn nicht als Pfadtrenner gemeint).URL-Encoding ist keine Verschlusselung, kein Schutz vor Manipulation und keine Sanitisierung gegen XSS. Ein percent-encoded String enthalt dieselbe Information wie der Klartext, nur in URL-sicherer Form. Wer Passworter oder Tokens in URLs unterbringt, sollte zusatzlich an HTTPS denken, denn auch encodete Werte stehen im Klartext in Server-Logs, Browser-History und Referer-Headern. Doppelt-Encoding ist ein weiterer haufiger Bug: wenn du einen bereits encodeten String erneut kodierst, wird %20 zu %2520, und der Empfanger sieht %20 statt eines Leerzeichens. Die maximale URL-Lange ist nicht im RFC festgelegt; in der Praxis erzwingen Chrome (32k), Edge (2k harter Cut-off) und IE 11 (2083) Grenzen, ab denen Requests scheitern. Kodiere niemals Body-Daten in URLs — nutze POST. Ein weiterer Spezialfall: Webserver wie Apache und Nginx normalisieren URLs unterschiedlich. Apache kann standardmassig // zu / reduzieren, Nginx nicht — was bei statischen Datei-Routen zu uberraschenden 404-Fehlern fuhren kann. Im Zweifel die Server-Doku konsultieren, bevor URL-Strukturen entworfen werden.
encodeURI belasst URL-Strukturzeichen wie / ? & # unverandert — fur komplette URLs. encodeURIComponent kodiert alles ausser A-Z a-z 0-9 - _ . ~ — fur einzelne Query-Parameter-Werte.+ (RFC 1866, application/x-www-form-urlencoded), nicht als %20. Server parsen meist beide Varianten, manche aber nur eine.a (a-Umlaut) wird zu %C3%A4 — zwei Bytes. Asiatische Zeichen brauchen oft drei Bytes.%25-Sequenzen vorhanden sind.