Was URL-Kodierung eigentlich ist
URL-Kodierung, auch Prozentkodierung genannt, ist die Art, wie eine URL Zeichen transportiert, die sie nicht enthalten darf. Eine URL darf nur wenige ASCII-Buchstaben, Ziffern und Satzzeichen verwenden. Alles andere – ein Leerzeichen, ein Umlaut, ein Emoji, ein kyrillisches oder arabisches Wort – muss als % plus zwei Hex-Ziffern pro Byte geschrieben werden.
Derselbe Trick gilt für Zeichen, die erlaubt sind, aber eine Bedeutung haben. Ein ? beginnt den Query-String und ein & trennt Parameter. Eine Suche nach Brot & Käse muss das Und-Zeichen also als %26 senden, sonst sieht der Server zwei Parameter statt einem.
Das ist ihre ganze Aufgabe: einen Wert sicher in eine URL zu bringen, ohne deren Bedeutung zu ändern. Sie ist weder Kompression noch Verschlüsselung noch ein Sicherheitsfilter.
Wie aus einem Zeichen %XX wird
Kodiert werden Bytes, nicht Zeichen. Der Text wird zuerst in UTF-8-Bytes umgewandelt, dann wird jedes zu kodierende Byte als % plus Hex-Wert geschrieben.
Ein ASCII-Zeichen ist ein Byte, ein Leerzeichen (Byte 32, hex 20) wird also zu %20. Zeichen außerhalb von ASCII belegen in UTF-8 zwei bis vier Bytes, und jedes Byte bekommt sein eigenes Escape:
ä→ Bytes C3 A4 →%C3%A4€→ Bytes E2 82 AC →%E2%82%AC😀→ Bytes F0 9F 98 80 →%F0%9F%98%80
Beim Dekodieren läuft es umgekehrt: Bytes einsammeln, dann als UTF-8 lesen. Wurden die Bytes mit einem anderen Zeichensatz wie Latin-1 erzeugt, entsteht Zeichensalat – Größe statt Größe. Alle modernen Browser und Frameworks nutzen UTF-8, und das solltest du auch.
Reserviert, nicht reserviert – und warum der Kontext zählt
RFC 3986 teilt URL-Zeichen in zwei Gruppen.
Nicht reservierte Zeichen – A–Z a–z 0–9 - . _ ~ – müssen nie kodiert werden. Es ist erlaubt, aber sinnlos, und ein guter Encoder lässt sie stehen.
Reservierte Zeichen – : / ? # [ ] @ ! $ & ' ( ) * + , ; = – geben der URL ihre Struktur. Ob du eines kodierst, hängt davon ab, wo es steht. Der / zwischen Pfadsegmenten muss ein Schrägstrich bleiben; ein / in einem Dateinamen, den du als Parameter übergibst, muss zu %2F werden. Deshalb gibt es nicht die eine richtige Art, „eine URL zu kodieren“: Man kodiert jedes Teil für den Ort, an den es kommt.
encodeURIComponent oder encodeURI
JavaScript hat zwei eingebaute Funktionen, und die falsche zu wählen ist der häufigste URL-Fehler überhaupt.
| Funktion | Wofür | Lässt stehen |
|---|---|---|
encodeURIComponent | Einen Wert: einen Parameter, ein Pfadsegment | Nur nicht reservierte Zeichen |
encodeURI | Eine ganze Adresse, die funktionieren soll | Auch reservierte Zeichen |
Wendest du encodeURI auf einen Wert wie a&b=c an, überleben & und =, und aus einem Parameter werden zwei. Wendest du encodeURIComponent auf eine ganze URL an, wird jeder / und : maskiert, und der Link ist keiner mehr. Faustregel: Baue URLs aus Teilen und kodiere jeden Wert mit encodeURIComponent – oder lass das gleich URLSearchParams erledigen.
Andere Sprachen haben dieselbe Trennung: quote und quote_plus in Python, rawurlencode und urlencode in PHP. Unser URL-Encoder und -Decoder bietet beide Modi, damit du den Unterschied an deiner eigenen Eingabe siehst.
+ oder %20: die Formular-Ausnahme
Im Pfad ist ein Leerzeichen %20 und ein + einfach ein Pluszeichen. HTML-Formulare, die mit dem Standardtyp application/x-www-form-urlencoded gesendet werden, kodieren ein Leerzeichen im Query-String jedoch als +, und Server dekodieren es zurück.
Ärger gibt es, wenn beide Konventionen aufeinandertreffen. Eine Telefonnummer wie +49 30 1234567, unkodiert in einen Query-String gesetzt, kommt als 49 30 1234567 an, weil der Server das + als Leerzeichen gelesen hat. Die Lösung: das Plus als %2B kodieren, was jeder Encoder nach Formularregeln tut. Wenn du nicht weißt, welche Konvention die Gegenseite erwartet, sind %20 für Leerzeichen und %2B für Plus immer sicher.
Doppelte Kodierung und der %2520-Fehler
%25 ist das kodierte Prozentzeichen selbst. Siehst du also %2520 in einer URL, ist das ein zum zweiten Mal kodiertes %20: Ein Wert ist durch einen Encoder gelaufen, obwohl er schon kodiert war.
Meist passiert das an einer Schnittstelle – ein Framework kodiert einen Parameter, den der aufrufende Code schon kodiert hatte, oder eine Weiterleitungs-URL wird einmal kodiert, um in eine andere URL zu passen, und dann noch einmal von einer Bibliothek. Sichtbare Folgen: ein 404, eine Suche nach dem wörtlichen Text %20 oder ein Dateiname voller Prozentzeichen.
Zweimal dekodieren liefert das Original, aber die eigentliche Lösung ist, den zweiten Encoder zu finden und zu entfernen. Kodiere genau einmal – in dem Moment, in dem ein Wert in die URL kommt.
Kodieren ist kein Escaping und keine Verschlüsselung
Prozentkodierung macht einen Wert innerhalb einer URL sicher. Für HTML, JavaScript oder SQL tut sie nichts. Sobald der Server %3Cscript%3E dekodiert, hat er wieder ein ganz normales <script>. Ausgaben müssen also weiterhin für ihr Ziel maskiert werden, und Datenbankabfragen brauchen weiterhin Parameter.
Geheim ist sie auch nicht. Jeder kann eine URL dekodieren, und URLs landen in Server-Logs, im Browserverlauf, in Analyse-Tools und im Referer-Header der nächsten Seite. Pack nie Passwörter, Tokens oder persönliche Daten in einen Query-String, nur weil es „verschlüsselt aussieht“. Dasselbe gilt für Base64, wie unser Base64-Guide erklärt.
Wenn das Dekodieren schiefgeht
Die meisten URL-Probleme sind eines davon:
- „URIError: malformed URI sequence“. Auf ein
%folgen keine zwei Hex-Ziffern, oder die Bytes sind kein gültiges UTF-8. Ein echtes Prozentzeichen muss selbst als%25gesendet werden. - Umlaute erscheinen als ä oder �. Die Bytes wurden in einem Zeichensatz geschrieben und in einem anderen gelesen. Stelle sicher, dass beide Seiten UTF-8 nutzen.
- Ein Parameter endet an einem &. Der Wert wurde nicht kodiert oder mit
encodeURIstattencodeURIComponent. - Pluszeichen werden zu Leerzeichen. Die Formular-Dekodierung hat
+als Leerzeichen gelesen. Kodiere ein echtes Plus als%2B. - %2520, %253D und Co. Doppelte Kodierung: Finde den zweiten Encoder.
Füge die URL in einen Decoder ein und sieh dir jeden Query-Parameter einzeln an – die Aufschlüsselung macht das Problem meist in Sekunden sichtbar.
Passende Tools und Guides:
- URL-Encoder und -Decoder - Text oder ganze URLs prozentkodieren, %XX zurück in Text wandeln und jeden Parameter sehen.
- Base64-Encoder & -Decoder - Text in Base64 kodieren oder zurück, mit URL-safe-Ausgabe und korrektem UTF-8.
- Base64 erklärt: wie Kodieren und Dekodieren wirklich funktionieren
Häufige Fragen
Was ist URL-Kodierung?⌄
URL-Kodierung, auch Prozentkodierung genannt, schreibt Zeichen, die in einer URL nicht erlaubt sind, als % plus zwei Hex-Ziffern pro UTF-8-Byte. Ein Leerzeichen wird zu %20, ä wird zu %C3%A4. So kann jeder Text in einer URL reisen, ohne ihre Bedeutung zu ändern.
Warum ist ein Leerzeichen mal + und mal %20?⌄
HTML-Formulare, die als application/x-www-form-urlencoded gesendet werden, kodieren ein Leerzeichen im Query-String als +. Überall sonst, auch in Pfaden und den meisten APIs, ist ein Leerzeichen %20 und + ein echtes Plus. %20 ist immer sicher.
Soll ich encodeURI oder encodeURIComponent verwenden?⌄
Nutze encodeURIComponent für einen einzelnen Wert wie einen Query-Parameter oder ein Pfadsegment, weil es &, =, / und ? kodiert. encodeURI nur für eine vollständige URL, die ihre Struktur behalten muss.
Was bedeutet %2520?⌄
Es ist ein doppelt kodiertes Leerzeichen: %25 ist das Prozentzeichen, %2520 also ein zum zweiten Mal kodiertes %20. Zweimal dekodieren, um es zu lesen, und dann den Code korrigieren, der doppelt kodiert.
Ist URL-Kodierung sicher?⌄
Nein. Jeder kann sie umkehren, sie bietet keine Geheimhaltung, und dekodierte Eingaben können trotzdem einen Injection-Angriff enthalten. Maskiere Ausgaben für HTML, nutze parametrisierte Abfragen für Datenbanken und pack nie Geheimnisse in eine URL.
Über 15 Jahre praktische Erfahrung in Webentwicklung und Sicherheit. Schwerpunkt ist praxisnahe Websicherheit: Websites sicher, zuverlässig und leicht zu diagnostizieren halten. BuildToolForge macht diese Prüfungen kostenlos, privat und verständlich. Die Tools laufen, wo immer möglich, in deinem Browser, und nichts, was du in ein Tool eingibst, wird gespeichert.
So schreiben wir unsere Anleitungen: Jede Anleitung entsteht aus praktischer Erfahrung, wird mit den offiziellen Standards abgeglichen und mit unseren eigenen Tools an echten Domains getestet. Wir aktualisieren die Anleitungen, wenn sich Standards oder Tools ändern. Einen Fehler gefunden? Schreib uns an contact@buildtoolforge.com.