HTML-Entities kodieren oder dekodieren _

Wie HTML-Entity-Kodierung funktioniert

Eine HTML-Entity ist eine Zeichenreferenz, die der Browser beim Parsen in ein einzelnes Zeichen umwandelt. Die fünf reservierten HTML-Zeichen (<, >, &, ", ') müssen immer kodiert werden, wenn Text als HTML gerendert wird; alles andere ist optional und hängt von der Dokumentkodierung ab.

1. Modus und Umfang wählen. Der Kodiermodus durchläuft die Eingabe Zeichen für Zeichen. Der Dekodiermodus sucht in der Eingabe nach Entity-Mustern. Der Umfang-Schalter bestimmt, ob nur die fünf HTML-sicheren Zeichen kodiert werden oder ob auch alle Nicht-ASCII-Codepunkte umgeschrieben werden.
2. Entity-Stil wählen. Named Entities (©) sind im Quellcode gut lesbar. Dezimalreferenzen (©) und Hexreferenzen (©) decken jeden Unicode-Codepunkt ab, ohne einen Namen zu benötigen. Ältere E-Mail-Clients und XML-Parser bevorzugen die numerischen Formen.
3. Eingabe durchlaufen. Beim Kodieren lesen wir jeden Codepunkt und suchen ihn in einer eingebauten Tabelle von etwa 200 häufigen Named Entities. Treffer ohne Namen werden numerisch ausgegeben. Beim Dekodieren scannen wir mit einem einzigen Regex, der &name;, &#NNN; und &#xHH; in einem Durchlauf abgleicht.
4. Auf Zeichen abbilden. Named Treffer werden über eine Rückwärtstabelle aufgelöst. Numerische Treffer werden über String.fromCodePoint mit Basis 10 oder Basis 16 verarbeitet. Unbekannte Named Entities bleiben unverändert, damit unvollständige Eingaben verlustfrei hin- und herkodiert werden können.
5. Live-Modus. Aktivieren Sie den Live-Modus, und jeder Tastenanschlag führt die Konvertierung mit einem 150-ms-Debounce erneut aus. Hilfreich, wenn Sie ein Snippet anpassen und sofortiges Feedback wünschen, bevor Sie es in ein Template einfügen.

Warum HTML-Entities kodieren

• Verhindern, dass Benutzereingaben das Layout zerstören. Wenn ein Benutzer ein unerwartetes < in ein Kommentarfeld tippt und dieser Text direkt in HTML eingefügt wird, wird der Rest der Seite neu strukturiert. Das vorherige Kodieren der reservierten Zeichen bewirkt, dass der Browser das Zeichen rendert, anstatt es als Beginn eines Tags zu interpretieren.
• Attributwerte gültig halten. Ein Anführungszeichen in einem HTML-Attribut muss durch " (bei doppelt angeführten Attributen) oder ' (bei einfach angeführten) ersetzt werden. Andernfalls schließt der Parser das Attribut vorzeitig, und der Rest der Zeile wird zu verwaistem Markup.
• Versehentliches HTML in gespeicherten Daten entschärfen. Logs, Fehlerberichte und Chat-Exporte enthalten oft echte spitze Klammern und Kaufmanns-Und-Zeichen. Das Entity-Kodieren des Dumps vor dem Einfügen in eine Dokumentationsseite hält diesen Inhalt als sichtbaren Text und verhindert, dass der Renderer oder der Link-Auto-Detektor anspringt.
• Code-Snippets sicher teilen. Das Posten eines Beispiel-Tags wie <script>alert(1)</script> in einem Blogbeitrag, einer E-Mail oder einer Slack-Nachricht erfordert die Kodierung der Klammern, damit das Snippet angezeigt und nicht ausgeführt wird. Dieselbe Technik gilt für RSS-Feed-Bodys und JSON-LD-`description`-Felder.

Typische Anwendungsfälle

Entity-Kodierung taucht überall auf, wo Rohtext zur Laufzeit zu HTML zusammengesetzt wird — auch wenn das Framework es normalerweise für Sie übernimmt, ist das manuelle Tool für die Fälle nützlich, in denen es das nicht tut.

• Server-seitige Templates: Jinja2, ERB, Twig und Handlebars escapen standardmäßig, aber Raw-Blöcke und `safe`-Marker schalten das ab — der Codec ermöglicht zu prüfen, was das Escaping ergeben hätte.
• E-Mail- und Newsletter-Authoring: Viele ESP-Template-Engines escapen Merge-Felder nicht automatisch, sodass typografische Anführungszeichen und Copyright-Glyphen in nutzerseitig eingepflegten Namen vorkodiert werden müssen.
• Dokumentation und Code-Samples: Ein Beispiel-HTML-Tag in einen Markdown-Blogbeitrag oder ein Static-Site-Snippet einzufügen erfordert die Kodierung der Klammern, damit der Renderer ihn als sichtbaren Text behandelt.

Ein ausgearbeitetes Beispiel

Fügen Sie <script>alert('hi')</script> in die Eingabe ein, mit Modus Kodieren, Stil Named und Umfang Minimal. Die Ausgabe lautet <script>alert('hi')</script>. Wechseln Sie zu Stil Numerisch Hex, und dieselbe Eingabe liefert <script>alert('hi')</script>. Stellen Sie den Modus auf Dekodieren, fügen Sie den kodierten String wieder ein, und das ursprüngliche Tag wird unverändert zurückgegeben.

FAQ

Was sind HTML-Entities?

HTML-Entities sind Zeichenreferenzen, die der Browser beim Parsen der Seite in einzelne Zeichen zurückwandelt. Sie gibt es in drei Formen: named (wie & für &), dezimal-numerisch (&) und hex-numerisch (&). Die fünf reservierten HTML-Zeichen (<, >, &, ", ') müssen immer kodiert werden, wenn der Text in HTML eingefügt wird. Die übrigen rund 2.225 Named Entities decken Symbole, Akzente und griechische Buchstaben ab, sind aber optional, sobald die Dokumentkodierung UTF-8 ist.

Wann sollte ich Named vs. numerische Entities verwenden?

Verwenden Sie Named Entities, wenn der Quellcode klar lesbar sein soll (ein Entwickler, der © in einem Template sieht, versteht es sofort). Verwenden Sie numerische (dezimale oder hexadezimale) Entities, wenn der Empfänger älter oder strenger ist — XML-Parser, Legacy-E-Mail-Clients und einige Feed-Reader erkennen nur eine kleine Teilmenge der HTML5-Named-Entities, aber alle erkennen die numerischen Formen. Hex setzt sich in sicherheitsorientierten Kontexten durch, weil es eins-zu-eins mit der Unicode-Codepunkt-Notation in Spezifikationsdokumenten übereinstimmt.

Verarbeitet die Dekodierung auch Hex-Entities wie &?

Ja. Der Decoder verwendet einen einzigen Regex, der alle drei Entity-Formen in einem Durchlauf abgleicht: &name;, &#NNN; und &#xHH;. Numerische Treffer werden mit String.fromCodePoint in Basis 10 oder Basis 16 aufgelöst. Gemischte Eingaben (Named und numerisch im selben String) werden korrekt dekodiert, und unbekannte Namen bleiben als Literaltext erhalten, damit unvollständige Eingaben verlustfrei hin- und herkodiert werden können.

Ist dies sicher für nicht vertrauenswürdige Eingaben?

Der Codec läuft ausschließlich im Browser und sendet Ihre Eingabe nirgendwohin. Ob die Ausgabe sicher eingebettet werden kann, hängt vom Kontext ab. Entity-Kodierung verarbeitet HTML-Body- und Attributwert-Kontexte, was den OWASP-Regel-1-Fall abdeckt. JavaScript-Kontexte (Inline-Eventhandler, `<script>`-Blöcke), CSS-Kontexte und URL-Kontexte benötigen jeweils eigene Kodierungsregeln — Entity-Kodierung allein reicht dort nicht aus. Für eine serverseitige Defense-in-Depth kombinieren Sie dies mit einer kontextbewussten Template-Engine wie DOMPurify oder dem Auto-Escape Ihres Frameworks.

Browser-seitige Entity-Kodierung sitzt an der Grenze zwischen Benutzereingabe und gerendertem HTML. Die lokale Konvertierung ermöglicht es, zu prüfen, was Ihr Framework ausgegeben hätte, ohne den Originaltext jemals an ein Drittanbieter-Tool zu senden.