Bereiten Sie Text als URL-Parameterwert vor oder lesen Sie prozentkodierte Inhalte. Das Werkzeug wendet encodeURIComponent oder decodeURIComponent auf die gesamte Eingabe an: Sie gilt als Komponentendaten, nicht als vollständige URL mit zu erhaltender Struktur.
Läuft lokal in deinem BrowserFügen Sie Text in das Eingabefeld ein. Die Verarbeitung erfolgt im Browser, ohne die eingegebene Adresse abzurufen. Dateiimport und Stapelverarbeitung sind nicht vorgesehen.
A-Z a-z 0-9 sowie - _ . ! ~ * ' ( ) bleiben beim Kodieren unverändert. Andere gültige Unicode-Zeichen werden als UTF-8-Prozentsequenzen dargestellt: 你好 😀 ergibt %E4%BD%A0%E5%A5%BD%20%F0%9F%98%80. Die zusätzliche Maskierung von ! ' ( ) * für strikte RFC-3986-Konformität findet nicht statt.
Aus a=1&b=two words wird a%3D1%26b%3Dtwo%20words. Auch bei einer vollständigen URL werden : / ? & = kodiert. Das passt, wenn die ganze Zeichenfolge als Datenwert benötigt wird, erhält aber nicht die URL-Struktur.
Dekodierte Trennzeichen können beim erneuten Einfügen die Interpretation einer URL ändern. Verwenden Sie das Ergebnis entsprechend als Parameterdaten. Die Ausgabe ist reiner Text, kein ausgeführtes HTML. Das Werkzeug prüft keine URL-Gültigkeit und verschlüsselt nichts.
Beim Kodieren wird auch % maskiert: %20 ergibt %2520. Dekodieren von %2520 liefert den wörtlichen Text %20, noch kein Leerzeichen. Es wird nur eine Ebene dekodiert; weder ein weiterer Durchlauf noch das Ersetzen der Eingabe erfolgt automatisch.
Dies ist keine Verarbeitung nach application/x-www-form-urlencoded. Kodieren ersetzt Leerzeichen durch %20 und + durch %2B. Ein wörtliches + bleibt beim Dekodieren erhalten: a+b%20c wird zu a+b c.
Beim Dekodieren sind etwa %, %GG und %E4%A fehlerhafte Escapes; %FF und %C0%AF enthalten ungültiges UTF-8. Statt Ersatzzeichen entsteht ein Fehler. Auch das Kodieren ungepaarter UTF-16-Surrogate scheitert. Nicht maskierter Text bleibt beim Dekodieren unverändert; nicht jedes wörtliche Zeichen wird validiert.
Leerraum wird nicht abgeschnitten, auch nicht am Anfang oder Ende. Das Textarea-Feld des Browsers vereinheitlicht eingegebene Zeilenenden jedoch zu LF, kodiert als %0A. Ursprüngliche CRLF- oder CR-Bytes bleiben daher nicht erhalten. Es wird keine Unicode-Normalisierung ergänzt. Eine leere Eingabe ergibt eine leere Ausgabe.