HTML-Sonderzeichen dekodieren

Der naheliegende Weg, Entitäten aufzulösen, ist, den Text in ein Element zu schreiben und den Browser nach dem Ergebnis zu fragen. Das ist auch der Weg, auf dem sich die Hälfte aller Werkzeuge dieser Gattung eine Lücke einbaut: Ein `<img src=x onerror=...>` im Text wird dabei zu einem echten Element, und je nach Methode löst das eine Netzwerkanfrage aus oder führt Code aus.

Hier passiert das nicht, weil kein HTML entsteht. Die Referenzen werden gegen eine Tabelle aufgelöst und die numerischen ausgerechnet — es gibt keinen Punkt, an dem dein Text als Markup interpretiert wird. Genau deshalb kann diese Seite auch keine Vorschau anbieten: Eine Vorschau wäre wieder das, was hier bewusst nicht getan wird.

Eine Zeichenreferenz beginnt mit `&` und endet mit `;`. Dazwischen steht entweder ein Name wie `amp` oder `nbsp`, eine Raute mit einer Dezimalzahl wie `#252`, oder eine Raute mit `x` und einer Hexzahl wie `#xFC`. Die letzten beiden bezeichnen denselben Unicode-Codepoint in zwei Zahlensystemen.

In der Praxis kommen alle drei in derselben Datei vor, weil verschiedene Bausteine sie erzeugt haben: Redaktionssysteme neigen zu benannten, Exportfunktionen zu dezimalen, XML-Werkzeuge zu hexadezimalen. Dieses Werkzeug behandelt sie gleich, du musst also nicht wissen, welcher Teil deiner Kette welche Vorliebe hatte.

Browser sind hier großzügig: `&amp` ohne Semikolon lösen sie in vielen Zusammenhängen trotzdem auf, weil frühe Seiten es so geschrieben haben und Kompatibilität gewann. Diese Nachsicht ist im HTML-Standard sogar festgeschrieben, allerdings nur für eine begrenzte Liste von Namen und nicht in Attributwerten.

Für dich heißt das: Ein `&amp` ohne Semikolon in deinen Daten ist eine Zeitbombe, weil verschiedene Verarbeiter es verschieden behandeln. Dieses Werkzeug verlangt das Semikolon und lässt unvollständige Referenzen stehen — was auf der Seite bleibt, ist damit sichtbar der Ort, an dem etwas nicht sauber erzeugt wurde.

Wenn im Ergebnis noch `&lt;` steht, war die Eingabe doppelt kodiert: Sie enthielt `&amp;lt;`, und ein Durchgang macht daraus korrekt `&lt;`. Das ist kein halbfertiges Ergebnis, sondern das richtige — ein Dekodierer, der so lange weiterläuft, bis nichts mehr aussieht wie eine Entität, würde auch Text zerstören, in dem `&lt;` buchstäblich gemeint war.

Die saubere Antwort ist, den Text ein zweites Mal durch das Feld zu schicken und dabei zu wissen, dass man es tut. Wenn dafür regelmäßig zwei Durchgänge nötig sind, ist die eigentliche Aufgabe, in der erzeugenden Kette die doppelte Kodierung zu finden — nicht, hier zweimal auf den Knopf zu drücken.

Fast immer aus einem Wert, der maskiert gespeichert und beim Ausgeben von einer Template-Engine noch einmal maskiert wurde. Beide Stellen sind für sich richtig; falsch ist, dass es zwei sind. Sichtbar wird es erst auf der fertigen Seite, wo Nutzerinnen dann `&nbsp;` als Text lesen.

Die zweithäufigste Quelle sind Import- und Migrationsläufe: Daten aus einem alten System kommen bereits maskiert an und werden von der neuen Importroutine behandelt, als wären sie roh. Auch das erkennt man an `&amp;` vor anderen Entitätsnamen — es ist die Signatur dafür, dass zwei Ebenen übereinanderliegen.

HTML5 definiert mehr als 2.200 benannte Referenzen, von `&amp;` über `&copy;` bis zu mathematischen Zeichen, die kaum jemand je tippt. Diese Liste ist bewusst eingefroren — es kommen keine neuen dazu, weil jede Ergänzung Dokumente ändern würde, die bereits existieren.

Praktisch bedeutet das: Wenn ein Name hier nicht aufgelöst wird, ist er entweder falsch geschrieben oder es war nie einer. Neue Zeichen bekommen keine Namen mehr; für alles, was Unicode seit 2014 hinzugefügt hat, gibt es ausschließlich die numerische Schreibweise. Ein `&emoji;` hat es nie gegeben und wird es nicht geben.

Codepoints über `FFFF` — Emoji, seltene Schriftzeichen, manche mathematischen Symbole — brauchen in JavaScript intern zwei Einheiten, ein sogenanntes Surrogatpaar. Ein Dekodierer, der das nicht berücksichtigt, erzeugt zwei kaputte halbe Zeichen statt eines vollständigen.

Gelegentlich begegnen einem auch Referenzen, die die Surrogathälften einzeln schreiben, weil ein altes Werkzeug so kodiert hat. Solche Werte sind streng genommen ungültiges Unicode; hier werden sie nicht stillschweigend zu einem Ersatzzeichen gemacht, sondern bleiben erkennbar, damit du siehst, dass die Quelle das Problem hat und nicht die Anzeige.

Ein `&foo;`, ein `&#;` und ein `&` ohne alles bleiben unverändert. Das ist eine Entscheidung: Die Alternative wäre, Unbekanntes zu entfernen, und das würde bedeuten, dass ein Dekodierer Text verliert — die unangenehmste Eigenschaft, die ein Werkzeug dieser Art haben kann.

Der Nebeneffekt ist nützlich. Wenn nach dem Durchgang noch etwas wie eine Entität aussieht, ist genau dort der interessante Punkt: entweder ein Tippfehler in der Quelle, ein Name aus einer anderen Spezifikation, oder ein `&`, das nie hätte maskiert werden dürfen und jetzt versehentlich wie ein Anfang aussieht.

Aus `&nbsp;` wird ein Zeichen, das aussieht wie ein Leerzeichen und keines ist. Es hat den Codepoint `A0` statt `20`, und deshalb scheitert danach ein Vergleich, ein Suchen-und-Ersetzen oder ein `trim()`, ohne dass am Bildschirm etwas verdächtig aussieht.

Das ist der zähste Fehler aus dieser Ecke, weil er unsichtbar ist. Wer aus einem Redaktionssystem oder einer Textverarbeitung kopierten Text verarbeitet, sollte damit rechnen: Word und die meisten WYSIWYG-Editoren setzen geschützte Leerzeichen großzügig. Wenn ein Wert „offensichtlich gleich“ ist und der Vergleich trotzdem scheitert, ist das die erste Stelle zum Nachsehen.

Der dekodierte Text ist per Definition weniger harmlos als der kodierte — die Maskierung war ja der Schutz. Wer das Ergebnis hier wieder in eine Seite einsetzt, muss es für den Ort maskieren, an dem es landet, sonst hat er eine Lücke selbst gebaut.

Diese Seite ist ein Lesewerkzeug: Sie beantwortet die Frage, was in einem Feld steht. Sie ist nicht der letzte Schritt einer Verarbeitungskette, an deren Ende HTML ausgeliefert wird. Für den umgekehrten Weg gibt es die Seite zum Maskieren, und die beiden gehören in dieser Reihenfolge zusammen.

In dieses Feld kommt regelmäßig Text aus fremder Hand — ein Datenbankauszug, ein Support-Ticket, ein Feed-Eintrag mit Namen und Adressen darin. Weil die Auflösung in der Seite passiert, wird nichts davon an uns übermittelt, und es entsteht keine Auftragsverarbeitung für diesen Inhalt.

Das Netzwerk-Panel ist der Weg, das zu prüfen statt es zu glauben: Während der Benutzung geht keine Anfrage mit deiner Eingabe hinaus. Was bleibt, steht in der Datenschutzerklärung — der Seitenaufruf, die Werbe- und Analytics-Anfragen. Der Inhalt des Textfelds gehört nicht dazu.