Zwischen Text und Escapes wechseln

Mit %u4F60 lassen sich etwa chinesische Zeichen als Textfolge darstellen. Der Dekodierer liest außerdem %XX-Werte und hexadezimale Referenzen mit abschließendem Semikolon. Die Berechnung läuft im Browser; der Eingabetext wird dabei nicht in Konvertierungsanfragen gesendet.

  1. Kodieren Sie Aé你😀. Das Ergebnis lautet Aé%u4F60%uD83D%uDE00: é bleibt erhalten, während das Emoji zwei UTF-16-Einheiten benötigt.
  2. Dekodieren Sie %u4F60 oder 你, um 你 zu erhalten. Aus left; A wird left; A, einschließlich des Semikolons im gewöhnlichen Text.
  3. Kopieren Sie das Ergebnis als Klartext. Eine Änderung der Eingabe verwirft die alte Ausgabe. Leeren entfernt beides; bei einem Dekodierfehler bleibt ebenfalls kein altes Ergebnis kopierbar.

Format und Grenzen

Prozentwerte ohne UTF-8-Byteauswertung

%E4%F6%FC ergibt äöü. Jeder %XX-Wert wird einzeln auf U+00XX abgebildet. Die UTF-8-URL-Folge %E4%BD%A0 wird hier daher nicht zu 你; dafür ist der URL-Dekodierer vorgesehen.

Beim Kodieren bleiben Leerraum, Satzzeichen, Prozentzeichen und alle weiteren Zeichen bis U+00FF unverändert. Das ist weder die vollständige escape()-Funktion noch eine Ausgabe von JavaScript-Escapes mit Rückstrich.

Referenzen werden in einem Durchlauf ersetzt

A wird zu A und 😀 zu 😀. Diese mit Semikolon abgeschlossenen Referenzen werden direkt in Unicode-Skalarwerte umgewandelt. Surrogatwerte und Werte oberhalb U+10FFFF sind unzulässig. Ein vollständiges HTML-Dokument wird nicht geparst.

Die ältere Form &#x4F60 ohne Semikolon bleibt unterstützt und ergibt 你 als eine UTF-16-Einheit. Sie benötigt ein kleines x und genau vier Hexadezimalziffern, auf die keine weitere Hexadezimalziffer folgt. Andere nicht abgeschlossene Referenzen bleiben wörtlich stehen.

%25u0041 ergibt den wörtlichen Text %u0041. Dezimale und benannte Referenzen, \u0041, %U0041 sowie unvollständige Prozent-Escapes bleiben stehen. %u und die ältere vierstellige Referenz erhalten UTF-16-Einheiten einschließlich ungepaarter Surrogate; eine Prüfung der gesamten Zeichenfolge auf gültiges Unicode erfolgt nicht.

Fragen zu %u-Escapes

Ist die Rückumwandlung immer verlustfrei?

Nein. Ein bereits wörtlich vorhandenes %41 bleibt beim Kodieren stehen und wird beim Dekodieren zu A. Tatsächliche CR- und CRLF-Zeilenenden normalisiert das Eingabefeld außerdem zu LF. Eine Unicode-Normalisierung findet nicht statt.

Warum hieß die Seite zuvor UTF-8 zu GBK?

Die frühere Bezeichnung passte nicht zum Programmcode. Die beibehaltene Funktion verarbeitet Text-Escapes und keine Datei-Bytes zwischen Zeichencodierungen. HTML-Tags in der Ausgabe bleiben sichtbarer Text und werden nicht ausgeführt.

Zuletzt verwendet: