URL-Codec

Warum URLs kodiert werden müssen

Eine URL ist zugleich eine lesbare Adresse und eine strukturierte Zeichenkette, die von Browsern, Proxys und Servern zerlegt wird. Bestimmte Zeichen trennen Komponenten: ? beginnt die Query, & trennt Parameter, # startet das Fragment, / teilt Pfadsegmente, und Leerzeichen sind in vielen Kontexten problematisch. Enthält ein Parameterwert selbst & oder =, missversteht der Parser die Struktur, sofern diese Bytes nicht in einer sicheren Form geschrieben werden.

URL-Kodierung—formeller percent-encoding—ersetzt unsichere oder reservierte Bytes durch ein % gefolgt von zwei hexadezimalen Ziffern. Das Byte space wird oft zu %20 (oder zu + in der Variante application/x-www-form-urlencoded). Das ist keine Verschlüsselung; es ist eine Transportschreibweise, damit Struktur und Nutzdaten koexistieren können.

Probieren Sie eine Phrase mit dem Text-zu-URL-kodiert-Tool zu kodieren.

Reservierte versus unreservierte Zeichen

RFC 3986 definiert unreserved-Zeichen, die meist unverändert erscheinen: Buchstaben, Ziffern und -._~. Reserved-Zeichen wie :/?#[]@!$&'()*+,;= haben Rollen in der URL-Grammatik. Ob Sie ein reserviertes Zeichen kodieren, hängt vom Kontext ab. Ein / im Pfad ist ein Trenner; ein / innerhalb der Daten eines einzelnen Pfadsegments muss möglicherweise kodiert werden, wenn Sie einen literalen Schrägstrich in diesem Segmentwert wollen.

Praktische Regel: Kodieren Sie Daten, die Sie in eine Komponente einfügen, so dass reservierte Zeichen für den umgebenden Parser ihre Sonderbedeutung verlieren.

Mechanik von percent-encoding

1. Die Zeichenkette als Bytes ausdrücken (im modernen Web fast immer UTF-8).
2. Für jedes zu kodierende Byte % plus Groß- oder Kleinbuchstaben-Hex schreiben (Decoder akzeptieren beides; Emitter nutzen oft Großbuchstaben).
3. Sichere Zeichen unverändert lassen.

Beispiel: Das Leerzeichen in hello world wird zu hello%20world. Die UTF-8-Kodierung von é ist die Bytes C3 A9, das Zeichen wird also %C3%A9.

Dekodieren kehrt die Abbildung um. Unvollständige Sequenzen wie %Z oder ein abschließendes % sollten abgelehnt oder nach den Regeln Ihrer Plattform behandelt werden—raten Sie in sicherheitsrelevantem Code nicht stillschweigend.

Query-Strings und application/x-www-form-urlencoded

HTML-Formulare kodieren Leerzeichen traditionell als + und nutzen & / = als Trenner. Bibliotheken namens encodeURIComponent versus URLSearchParams unterscheiden sich in Grenzfällen. Beim Debuggen:

• Prüfen, ob + Leerzeichen oder ein literales Plus bedeutet.
• Werte vor dem Verbinden mit & kodieren.
• Nicht die gesamte URL blind kodieren—Schema und Host folgen anderen Regeln.

encodeURI und encodeURIComponent in JavaScript kodieren unterschiedliche Zeichensätze; die falsche Wahl ist eine häufige Ursache kaputter Links.

Pfade, Matrizen und Fragmente

Pfadsegmente sollten Leerzeichen und die meisten reservierten Zeichen kodieren, die nicht als Trenner gedacht sind. Fragmente (#...) werden vom Client verarbeitet und nicht mit der HTTP-Anfrage an Server gesendet; Kodierung bleibt für die Korrektheit im Client wichtig. Userinfo (user:pass@) ist für Geheimnisse in URLs überholt—legen Sie Zugangsdaten unabhängig von der Kodierung nicht in URLs ab.

Doppelkodierung und Dekodierungsfehler

Doppelkodierung entsteht, wenn %20 erneut zu %2520 kodiert wird. Symptome: literales %20 in UI-Texten oder Dateien nicht gefunden, weil der Server den falschen Namen sucht. Unterkodierung lässt & in einem Wert stehen und schneidet nachfolgende Parameter ab.

Eine robuste Pipeline kodiert genau einmal an der Grenze, an der ein Rohstring Teil einer URL-Komponente wird, und dekodiert einmal beim Extrahieren der Werte.

Internationalisierte Domainnamen und Pfade

Hosts nutzen IDNA (Punycode) für nicht-ASCII-Domainlabels—ein anderer Mechanismus als percent-encoding von Pfad- und Query-Daten. Pfade und Queries nutzen UTF-8-percent-encoding. Das Mischen veralteter Systemkodierungen (Latin-1 auf der einen Seite, UTF-8 auf der anderen) erzeugt Mojibake nach dem Dekodieren.

Dokumentieren Sie für neue APIs stets UTF-8 als Byte-Kodierung.

Sicherheitsaspekte

URL-Kodierung ersetzt weder HTML-Escaping noch SQL-Parametrisierung noch sichere Kommandoargumente. Eine für einen Query-Parameter korrekt percent-kodierte Zeichenkette kann später gefährlich sein, wenn sie ohne Escaping in HTML oder ohne korrektes Quoting in eine Shell gelangt.

Open-Redirect- und SSRF-Probleme betreffen oft URLs als Daten. Validieren Sie Schemas und Hosts nach dem Dekodieren—Angreifer können Punkte, Schrägstriche oder Zugangsdaten kodieren, um naive Filter zu verwirren. Vergleichen Sie dekodierte Formen sorgfältig; besser: mit einer Standard-URL-Bibliothek parsen und Eigenschaften per Allowlist prüfen.

Protokollierung und Datenschutz

Query-Strings enthalten häufig Suchbegriffe, Tokens oder personenbezogene Daten. Kodierung versteckt sie weder vor Server-Logs noch vor dem Browserverlauf. Bevorzugen Sie POST-Bodies oder Header für sensible Werte und entfernen Sie Geheimnisse aus Zugriffsprotokollen.

Test-Checkliste

1. Eine Zeichenkette mit Leerzeichen, &, = und Nicht-ASCII-Zeichen kodieren.
2. Dekodieren und mit den ursprünglichen Codepunkten vergleichen.
3. Den kodierten Wert in eine echte Query setzen und über die Parameter-API Ihres Frameworks zurücklesen.
4. Prüfen, dass Ihr Framework nicht doppelt dekodiert.
5. Sicherstellen, dass das Verhalten von + versus %20 zum verwendeten Medientyp passt.

Das URL-Kodierungs-Tool hilft bei den Schritten 1–2 bei manueller Exploration.

Häufige Szenarien

Suchlinks bauen. Den Benutzer-Query-Wert kodieren; ?q= selbst nicht kodieren. OAuth-Redirect-URIs. Exakter String-Vergleich kann nötig sein; Kodierungsunterschiede brechen Redirects. Object-Storage-Keys in URLs. Pfadsegmente kodieren, damit verschachtelte Keys mit Leerzeichen funktionieren. CSV mit Links. Aufpassen, dass Tabellenkalkulationen %-Sequenzen nicht neu interpretieren.

Verwandte Kodierungen

Verwechseln Sie percent-encoding nicht mit Base64 oder HTML-Entities. Base64 nutzt ein anderes Alphabet und dient beliebigen Bytes in Textkontexten; HTML-Entities schützen die Dokumentstruktur im Markup. Nutzen Sie den Encoder, der zum empfangenden Parser passt.

Zusammenfassung

URL-Kodierung lässt beliebigen Text in URL-Komponenten mitfahren, ohne Delimiter zu zerstören. In UTF-8-Bytes wandeln, unsichere Werte einmal percent-kodieren und beim Auslesen einmal dekodieren. APIs für Query- versus Voll-URI-Kodierung sorgfältig wählen, URLs nach dem Parsen aus Sicherheitsgründen validieren und bedenken: Kodierung ist Schreibweise—keine Vertraulichkeit.