Escape-Sequenzen aus Altbeständen lesen

Fügen Sie Text direkt ein. Die Verarbeitung erfolgt im Browser, ohne Datei-Upload, URL-Abruf oder Stapelverarbeitung. Für neuen Anwendungscode sind diese Funktionen nicht empfohlen.

  1. Geben Sie ursprünglichen Text zum Kodieren oder eine alte Escape-Darstellung zum Dekodieren ein.
  2. Starten Sie die gewünschte Umwandlung, prüfen und kopieren Sie die Textausgabe. Eine Änderung der Eingabe löscht das vorherige Ergebnis.
  3. Fügen Sie das Ergebnis für einen weiteren Schritt selbst ins Eingabefeld ein. Leeren setzt beide Felder zurück.

Codeeinheiten statt UTF-8-Bytes

Zwei- und vierstellige Hexadezimalwerte

A-Z a-z 0-9 sowie @ * _ + - . / bleiben unverändert. Andere UTF-16-Codeeinheiten unter 256 werden als %XX dargestellt, die übrigen als %uXXXX. Hexadezimalziffern erscheinen in Großschreibung, mit führenden Nullen auf zwei oder vier Stellen ergänzt; das u bleibt klein.

é ergibt %E9, 你好 wird zu %u4F60%u597D. 😀 besteht aus zwei Codeeinheiten und ergibt %uD83D%uDE00. Auch ~, ' und & werden kodiert: %7E, %27 und %26.

Ungültige Abschnitte bleiben unverändert

Dekodieren von %u4f60 %GG %U0041 liefert 你 %GG %U0041. Bei Hexadezimalziffern ist Groß- oder Kleinschreibung erlaubt, beim u-Präfix nur Kleinschreibung. %, %GG und %u123 bleiben wörtlicher Text und lösen keinen URIError aus. Gültige Sequenzen daneben werden trotzdem dekodiert; eine strenge Validierung findet nicht statt.

Keine Auswertung anderer Escape-Formate

%E4%BD%A0 wird zu den einzelnen Codeeinheiten U+00E4, U+00BD und U+00A0, nicht zu 你. Für moderne UTF-8-URL-Komponenten verwenden Sie stattdessen encodeURIComponent/decodeURIComponent.

Die wörtlichen Texte \n, \u4F60 und & bleiben beim Dekodieren erhalten. JS/JSON-Zeichenfolgenliterale und HTML-Entitäten werden nicht ausgewertet, Code wird nicht ausgeführt. Dies ist keine Verschlüsselung.

Fragen zu alten Escape-Darstellungen

Was passiert mit + oder bereits vorhandenem %20?

+ bleibt in beiden Richtungen +, ein Leerzeichen wird als %20 kodiert. Kodieren von %20 ergibt %2520. Dekodieren von %2520 liefert in einem Durchlauf den Text %20, noch kein Leerzeichen. Das ist keine Formulardekodierung.

Werden Leerraum und Zeilenenden bereinigt?

Leerraum wird nicht abgeschnitten; eine Unicode-Normalisierung wird nicht ergänzt. Das Textarea-Feld vereinheitlicht tatsächliche Zeilenenden jedoch zu LF, kodiert als %0A. Ursprüngliche CRLF- oder CR-Bytes bleiben nicht erhalten. Eine leere Eingabe ergibt eine leere Ausgabe.

Ist ein Ergebnis immer gültiger Unicode-Text?

Nein. escape/unescape akzeptiert ungepaarte UTF-16-Surrogate wie %uD800. Darstellung oder Zwischenablage können sie ersetzen; unverändertes Kopieren und Zurückfügen ist nicht garantiert. Fehlen die nativen Funktionen, meldet das Werkzeug dies, ohne einen anderen Kodierer einzusetzen.

Zuletzt verwendet: