Was bedeuten «kodieren» und «dekodieren» bei einer URL?
Eine URL kodieren (« url encode », « urlencode ») wandelt jedes unzulässige Zeichen in einer Adresse — Leerzeichen, Akzent, Et-Zeichen, Pluszeichen — in eine Sequenz um, bestehend aus einem Prozentzeichen und den beiden Hexadezimalziffern seines Bytes. Eine URL dekodieren (« url decode », « decoder url ») liest diese Sequenzen rückwärts: Die Bytes werden rekonstruiert und dann je nach deklariertem Zeichensatz — meist UTF-8 — in Zeichen umgewandelt. Genau dieses Paar suchen die Menschen, wenn sie « encoder decoder url » oder « percent encoding online » eingeben.
Percent-Encoding ist weder Kompression noch Verschlüsselung: Ein Wort mit Akzent wird doppelt so lang, und jeder kann es mit bloßem Auge lesen. Seine einzige Aufgabe ist es, jedes Byte durch eine URL zu bringen, die standardmäßig nur eine Teilmenge von ASCII zulässt. Umgekehrt dient Base64 dazu, Bytes in vollständig textbasierte Kanäle zu übertragen — beide sehen auf den ersten Blick ähnlich aus, sind aber nicht austauschbar.
Wie man eine URL ins Percent-Encoding kodiert
Schritt 1: Der Text wird je nach gewähltem Zeichensatz in Bytes umgewandelt, standardmäßig UTF-8. Schritt 2: Für jedes Byte wird geprüft, ob das zugehörige Zeichen in der Liste der für den gewählten Bereich erlaubten Zeichen steht. Schritt 3: Wenn es dazugehört, wird es unverändert übernommen; andernfalls wird es zu %XX, wobei XX die beiden Hexadezimalziffern des Bytes sind. Schritt 4: Wenn die Option Leerzeichen als + aktiv ist, wird Byte 32 durch ein Pluszeichen ersetzt statt durch %20.
Konkretes Beispiel: « café & été » ergibt im Komponentenbereich caf%C3%A9%20%26%20%C3%A9t%C3%A9. Geben Sie diesen Text einfach in den Kodierer ein: Das Ergebnis, die Eingabegröße, die Ausgabegröße und der Overhead erscheinen, bevor Sie die Taste loslassen.
Die vier Kodierungsbereiche
Der Komponentenbereich behält nur die Buchstaben, die Zahlen und - _ . ! ~ * ' ( ) : das ist der Wert eines Parameters, und er entspricht encodeURIComponent. Der Query-String behält außerdem die Et-Zeichen und die Gleichheitszeichen, um den kompletten Query-String wiederherzustellen. Der Pfadsegment erlaubt / : @ & = + $ , ; damit die Schrägstriche nicht zerstört werden. DieVollständige URL fügt zusätzlich ?, #, [ und ] : fast nichts wird kodiert, nur Leerzeichen und Nicht-ASCII-Zeichen gehen in %XX.
Wie man eine kodierte URL dekodiert
Die Dekodierung scannt die Zeichenkette von links nach rechts: Ein Prozentzeichen mit zwei Hexadezimalziffern ergibt ein Byte, jedes andere Zeichen wird nach der Konvertierung gemäß dem gewählten Zeichensatz übernommen. Die Bytes werden anschließend zusammengefasst und in Zeichen umgewandelt — zwei Bytes für « é », drei für « 日 », vier für ein Emoji. Der Tab «Dekodieren» zeigt jede gefundene Sequenz, ihre Position in der Zeichenkette, ihre Bytes und den zugehörigen Text.
Folgt auf das Prozentzeichen keine gültigen zwei Ziffern, ist der Fehler eindeutig: unvollständige Sequenz oder ungültiges Hexadezimalzeichen. Der Knopf «%-Zeichen korrigieren» macht aus vereinzelten Prozentzeichen %25, sodass die Zeichenkette ohne Informationsverlust dekodierbar wird — die sicherste Option für eine teilweise escapierte URL.
Leerzeichen: %20 oder + — die Formularregel
%20 ist das Leerzeichen im strikten Percent-Encoding: Es funktioniert im Pfad, in der Query, im Fragment und in den Headern. Das Zeichen +, ist dagegen nur im Format application/x-www-form-urlencoded der von HTML-Formularen und historisch von den Query-Strings verwendet wird. Sonst bleibt es ein wörtliches Pluszeichen — und da es leicht mit einem Leerzeichen verwechselt wird, muss man es als %2B kodieren, sobald man einen Wert umwandelt.
Praxis: Ein Formularfeld zu füllen oder das Verhalten eines <form>, aktivieren Sie « Leerzeichen als + ». Bei einer Redirect-URL, einer Canonical oder einem geteilten Link sollten Sie immer %20. Der Dekodierer behandelt + standardmäßig als Leerzeichen, und Sie können dieses Verhalten per Klick deaktivieren.
RFC 3986: unreserved, sub-delims und gen-delims
Die RFC 3986 teilt die ASCII-Zeichen in drei Kategorien. Die nicht reservierten Zeichen — Buchstaben, Zahlen, - _ . ~ — bleiben stets unverändert erhalten. Die Subdelimiter ! $ & ' ( ) * + , ; = und die generischen Trennzeichen : / ? # [ ] @ haben eine strukturelle Bedeutung: Sie trennen Autorität, Pfad, Query und Fragment. Alles andere — Leerzeichen, Anführungszeichen, spitze Klammern, geschweifte Klammern, Prozentzeichen — muss kodiert werden.
Diese Kategorien sind genau diejenigen, die der Tab «RFC 3986 & Referenz» Zeichen für Zeichen anzeigt: Klicken Sie auf eine Kachel, um ihren Hexadezimalcode, ihre Kategorie und die Bereiche zu sehen, die sie behalten. Das ist die schnellste Referenz für die Frage «Muss ich dieses Zeichen escapen?».
Sonderzeichen, Emojis und UTF-8
Eine URL transportiert nur sichere ASCII-Bytes, daher muss jedes Zeichen über U+007F hinaus kodiert werden. In UTF-8 hat « é » den Wert C3 A9 und wird zu %C3%A9, « 日 » hat drei Bytes und erzeugt drei Sequenzen, ein Emoji belegt vier und ergibt acht kodierte Zeichen. Wenn das Ergebnis lang erscheint, ist das kein Fehler: Es ist der Preis für die Kompatibilität mit allen Protokollen. Achten Sie zuletzt auf den Zeichensatz der Quelle: Wird eine in Latin-1 kodierte Zeichenkette in UTF-8 dekodiert, entstehen fehlerhafte Zeichen — daher die vier Optionen im Tab «Dekodieren».
Warum encodeURIComponent nicht immer reicht
encodeURIComponent kodiert alles außer A-Z a-z 0-9 - _ . ! ~ * ' ( ), was für einen Parameterwert genügt, aber eine vollständige URL zerstört, da es auch Schrägstriche, Doppelpunkte und Et-Zeichen kodiert. encodeURI macht das Gegenteil: Er erhält die Struktur der URL, lässt aber Leerzeichen und Akzente durch — und scheitert an rohem Text. Beide Varianten werden hier abgedeckt — und mehr noch, denn die Bereiche «Query-String» und «Pfadsegment» schließen die Lücke zwischen beiden.
Percent-Encoding und Base64: zwei verschiedene Werkzeuge
Percent-Encoding ersetzt Byte für Byte und erhält die Lesbarkeit des Originaltexts — mit dem Nachteil erheblicher Längenzunahme. Base64 fasst Bytes zu je drei zusammen und schreibt sie in ein 64-Zeichen-Alphabet: kompakt, aber völlig unlesbar und ohne URL-safe-Variante in einer URL nicht verwendbar. Der Tab «Mehrfachkodierungen» zeigt beides auf einen Blick, dazu die Hexadezimal-Bytes, die HTML-Entities und die escapte JSON-Zeichenkette — so wählen Sie die richtige Darstellung, bevor Sie etwas kopieren.
Häufige Fehler: doppeltes Kodieren und isoliertes %
Der häufigste Fehler ist es, dieselbe Zeichenkette zweimal zu kodieren: Aus einem Leerzeichen wird %20, dann %2520, und der Server erhält buchstäblich «%20». Der zweite Fehler ist, das Prozentzeichen selbst zu vergessen, das zu %25 — sonst hält der Dekodierer es für den Anfang einer Sequenz und stürzt ab oder kürzt ab. Schließlich führt ein + nicht kodiertes in einem Formularparameter dazu, ein unerwünschtes Leerzeichen einzufügen. Der Dekodierer meldet fehlerhafte Sequenzen, und der Knopf «%-Zeichen korrigieren» behebt den zweiten Fall ohne Verlust.
Wo kodierte URLs stecken
In den Tracking-Query-Strings UTM, in den redirect_uri und den Zuständen von OAuth, in den Webhooks deren Ziel-URL verschachtelte Parameter enthält, in den Callback-URLs mit Signatur, in den Server-Logs, in den Sitemaps und Canonicals, in den <a href> die clientseitig erzeugt werden, in den JWT deren Payload in Base64URL vorliegt, in den data: und den Headern Location, und in jedem per GET gesendeten HTML-Formular. Wer kodieren und dekodieren in einer Sekunde beherrscht, muss für eine einzige Zeichenkette kein Terminal öffnen.
Performance und bewährte Praxis
Im Browser sind Kodierung und Dekodierung linear und kosten selbst bei mehreren Megabytes kaum etwas: Jedes Zeichen wird nur einmal verarbeitet, ohne Rekursion und ohne Speicherzuweisung pro Zeichen. Die einzigen Fallstricke sind das doppelte Kodieren — prüfen Sie vor dem Speichern immer den Round-Trip — und URLs mit mehreren Kilobyte, die von Proxys jenseits von 2 000 Zeichen oft abgeschnitten werden. Dokumentieren Sie den verwendeten Bereich neben der erzeugten Zeichenkette: «Komponente» und «Vollständige URL» liefern beim selben Text nicht dasselbe Ergebnis.
Empfohlen für
Back-End- und Front-End-Entwickler (Query-Strings, Redirects, OAuth), Integratoren und technische Redakteure (UTM-Links, Canonical, Tracking), Administratoren und DevOps (Webhooks, signierte URLs, Logs), Tester und Pentester (Fuzzing von Parametern, Umgehung von Filtern), Studierende (UTF-8, ASCII und RFC 3986 verstehen) und alle, die einen URL-Encoder und -Decoder online brauchen — schnell, vollständig und vertraulich — ergänzt durch den Base64-Encoder und -Decoder und den JSON-Formatter.
Français
English
Español
Deutsch
Português
中文
हिन्दी
العربية
Русский
Bahasa Indonesia
日本語
Italiano
Türkçe
한국어
Nederlands
Polski
Tiếng Việt