🛡️ HTML Entities
Sonderzeichen sicher in HTML Entities kodieren oder wieder in reinen Text zurückverwandeln.
Was ist eine HTML Entity?
Eine HTML Entity ist eine Textfolge, die ein bestimmtes Zeichen repräsentiert, ohne dieses Zeichen selbst direkt im Quelltext zu verwenden. Sie beginnt immer mit einem kaufmännischen Und-Zeichen (&) und endet mit einem Semikolon (;). Dazwischen steht entweder ein Name, etwa © für das Copyright-Symbol, oder ein numerischer Code, etwa © für dasselbe Zeichen in dezimaler Schreibweise oder © in hexadezimaler Schreibweise. Alle drei Schreibweisen erzeugen exakt dasselbe sichtbare Zeichen, das Copyright-Zeichen, sie unterscheiden sich nur darin, wie der Browser den Code liest.
Entities existieren aus einem einfachen Grund: Bestimmte Zeichen haben im HTML-Quelltext eine besondere Bedeutung und können deshalb nicht einfach so eingesetzt werden, ohne dass der Browser sie als Teil des Markups statt als sichtbaren Text interpretiert. Andere Zeichen, etwa ein geschütztes Leerzeichen oder ein typografischer Gedankenstrich, lassen sich über eine normale Tastatur gar nicht zuverlässig eingeben. Für beide Fälle bietet die HTML Entity einen Ausweg: ein Stück reiner Text, das der Parser gezielt in genau ein Zeichen zurückverwandelt.
So verwenden Sie den Encoder und Decoder
- Text oder HTML einfügen. Fügen Sie im Editor entweder rohen Text mit Sonderzeichen oder bereits vorhandenes HTML mit Entities ein.
- Kodieren oder dekodieren wählen. Klicken Sie auf "HTML kodieren", um Sonderzeichen in Entities umzuwandeln, oder auf "HTML dekodieren", um vorhandene Entities zurück in lesbare Zeichen zu verwandeln.
- Ergebnis übernehmen. Kopieren Sie das Ergebnis direkt aus dem Ausgabefeld oder laden Sie es als eigenständige
.txt-Datei herunter.
Welche Zeichen müssen escaped werden, und warum
Fünf Zeichen bereiten im HTML-Text die meisten Probleme, wenn sie unverändert eingefügt werden: <, >, &, " und '. Der Grund liegt in der Funktionsweise des HTML-Parsers selbst. Ein <-Zeichen signalisiert dem Parser den Beginn eines neuen Tags, ein &-Zeichen signalisiert den Beginn einer Entity-Referenz, und Anführungszeichen begrenzen Attributwerte. Taucht eines dieser Zeichen an einer Stelle auf, an der der Parser eigentlich reinen Text erwartet, interpretiert er es trotzdem nach seiner besonderen Bedeutung, mit teils unerwarteten Ergebnissen.
Ein konkretes Beispiel macht das deutlich. Möchten Sie in einem Tutorial erklären, wie man ein <div>-Element schreibt, und fügen den rohen Text <div> direkt in Ihre Webseite ein, versucht der Browser tatsächlich, ein div-Element zu öffnen, statt die drei Zeichen als sichtbaren Text darzustellen. Der Leser sieht dann gar nichts, wo eigentlich <div> stehen sollte, weil der Browser das vermeintliche Tag stillschweigend verarbeitet hat. Kodieren Sie dieselbe Zeichenfolge stattdessen als <div>, zeigt der Browser exakt den Text an, den Sie tippen wollten, ohne ihn als Markup misszuverstehen.
Beim kaufmännischen Und-Zeichen selbst kommt eine zusätzliche Falle hinzu. Moderne Browser interpretieren ein einzelnes &, dem kein gültiger Entity-Name folgt, meist tolerant und zeigen es einfach als Zeichen an, etwa in "Häppchen & Getränke". Verlassen Sie sich aber nicht auf diese Nachsicht: Folgt auf das Zeichen zufällig eine Buchstabenfolge, die selbst wie ein Entity-Name aussieht, etwa "AT&T" gefolgt von einem Wort, das mit den richtigen Buchstaben beginnt, kann der Parser das gesamte Fragment fälschlich als Entity-Referenz lesen und ein völlig anderes Zeichen einsetzen. Ein sauber kodiertes & vermeidet dieses Risiko zuverlässig, unabhängig davon, welcher Text zufällig danach folgt.
Benannte Entities gegenüber numerischen Entities
Für viele Zeichen gibt es zwei gültige Schreibweisen. Eine benannte Entity wie < ist für Menschen, die den Quelltext lesen, sofort verständlich, "lt" steht erkennbar für "less than". Eine numerische Entity wie < oder ihre hexadezimale Variante < verweist stattdessen direkt auf die Position des Zeichens in der Unicode-Tabelle und ist für einen Menschen ohne Nachschlagen kaum zu entziffern, dafür aber garantiert eindeutig, weil sie nicht von der Menge der im jeweiligen Dokument unterstützten benannten Entities abhängt.
In der Praxis bevorzugen die meisten Entwickler benannte Entities für die gängigen Sonderzeichen wie <, >, & und ©, weil sie den Quelltext selbsterklärend halten. Für seltenere Zeichen außerhalb der bekannten Kurzliste, etwa ein bestimmtes mathematisches Symbol oder ein Zeichen aus einem nicht lateinischen Alphabet, greifen viele Werkzeuge automatisch auf die numerische Schreibweise zurück, weil nicht jedes exotische Zeichen einen offiziell definierten Namen besitzt, während die numerische Schreibweise für jedes Unicode-Zeichen ausnahmslos funktioniert.
Die fünf vordefinierten Entities aus der XML-Spezifikation
Aus dem XML-Standard stammen fünf Entities, die dort verpflichtend sind: <, >, &, " und '. Ein XML- oder XHTML-Dokument, das eines dieser fünf Zeichen roh im Text verwendet, ohne es zu kodieren, gilt als nicht wohlgeformt, und ein strenger XML-Parser bricht die Verarbeitung mit einem Fehler ab, statt das Dokument großzügig zu interpretieren.
| Zeichen | Benannte Entity | Dezimal | Hexadezimal |
|---|---|---|---|
< | < | < | < |
> | > | > | > |
& | & | & | & |
" | " | " | " |
' | ' | ' | ' |
HTML ist an dieser Stelle nachsichtiger als XML. Ein Apostroph im normalen Textfluss eines HTML-Dokuments muss nicht zwingend als ' kodiert werden, ein HTML-Parser akzeptiert das rohe Zeichen dort ohne Probleme, weil ein einzelnes Apostroph außerhalb eines mit einfachen Anführungszeichen begrenzten Attributwerts keine strukturelle Bedeutung trägt. Bei den anderen vier Zeichen, allen voran < und &, gilt in HTML dieselbe Vorsicht wie in XML, weil sie dort weiterhin eine strukturelle Bedeutung besitzen. Wer XHTML schreibt oder Daten erzeugt, die von einem strengen XML-Parser gelesen werden, kodiert deshalb sicherheitshalber alle fünf, statt sich auf die Nachsicht von HTML zu verlassen.
Geschützte Leerzeichen und typografische Zeichen
Neben den strukturell notwendigen Entities gibt es eine zweite Gruppe, die vor allem der Typografie dient. Ein geschütztes Leerzeichen, , verhindert einen Zeilenumbruch zwischen zwei Wörtern, die zusammenbleiben sollen, etwa zwischen einer Zahl und ihrer Einheit. Das Copyright-Zeichen © und das Markenzeichen ™ lassen sich über die meisten Tastaturlayouts nicht direkt eingeben und werden deshalb praktisch immer über ihre Entity-Schreibweise gesetzt.
Auch typografische Satzzeichen gehören in diese Kategorie. Die Auslassungspunkte … erzeugen ein einzelnes, korrekt gekerntes Zeichen anstelle von drei einzelnen Punkten. Der Gedankenstrich — und der etwas kürzere Halbgeviertstrich – sind die typografisch korrekten Zeichen für Einschübe beziehungsweise Zahlenspannen wie "Seite 10 bis 20", ein einfacher Bindestrich ist dafür eigentlich zu kurz gedacht und wird in professionell gesetztem Text durch eine dieser beiden Entities ersetzt. Diese Zeichen von Hand über eine Sondertastenkombination einzugeben ist auf vielen Tastaturlayouts umständlich oder unmöglich, weshalb die Entity-Schreibweise in HTML-Quelltexten der zuverlässigere Weg bleibt.
Eine kleine, aber nützliche Ergänzung dazu sind Entities wie € für das Eurozeichen, ° für ein Gradzeichen oder § für ein Paragrafenzeichen, allesamt Symbole, die zwar auf den meisten deutschen Tastaturlayouts vorhanden sind, in Texten mit gemischten Zeichensätzen oder beim automatisierten Export aus einer Datenbank aber häufig zuverlässiger über ihre Entity-Form eingefügt werden, um Kodierungsprobleme von vornherein auszuschließen.
Attributwerte und Textinhalt: unterschiedliche Regeln
Wo Sie escapen müssen, hängt davon ab, wo im Dokument der Text steht. Innerhalb des sichtbaren Textinhalts eines Elements müssen Sie vor allem < und & kodieren, weil diese beiden Zeichen dort eine neue Tag- beziehungsweise Entity-Struktur einleiten könnten. Innerhalb eines in doppelte Anführungszeichen gesetzten Attributwerts kommt eine zusätzliche Regel hinzu: Das doppelte Anführungszeichen selbst muss kodiert werden, weil der Parser sonst annimmt, der Attributwert sei an dieser Stelle bereits zu Ende.
Ein konkretes Beispiel zeigt den Unterschied. Ein title-Attribut, das ein Zitat mit Anführungszeichen enthalten soll, muss so geschrieben werden:
<span title="Er sagte "Hallo"">Text</span>Ohne die kodierten Anführungszeichen würde der Parser den Attributwert bereits nach dem ersten Anführungszeichen von "Hallo" beenden und den Rest als ungültiges, überschüssiges Markup direkt neben dem Element interpretieren, mit unvorhersehbaren Folgen für die Darstellung. Dasselbe Prinzip gilt für ein alt-Attribut auf einem Bild oder jedes andere Attribut, dessen Wert ein doppeltes Anführungszeichen enthalten könnte.
Der Sicherheitsaspekt: Escaping als Schutz vor XSS
Escaping ist nicht nur eine Frage der korrekten Darstellung, es ist auch eine der grundlegendsten Verteidigungslinien gegen Cross-Site-Scripting, kurz XSS. Immer wenn eine Website von Nutzern eingegebenen Text unverändert in eine Seite einfügt, etwa einen Kommentar, einen Produktnamen oder eine Suchanfrage, besteht die Gefahr, dass darin enthaltenes Markup vom Browser tatsächlich ausgeführt wird, statt als reiner Text angezeigt zu werden.
Ein einfaches Beispiel verdeutlicht das Risiko. Trägt jemand in ein Kommentarfeld den Text <script>alert('gehackt')</script> ein, und rendert die Website diesen Kommentar später ohne Kodierung direkt in die Seite, führt der Browser jedes Besuchers, der den Kommentar zu sehen bekommt, das enthaltene Skript tatsächlich aus. In einem realen Angriff steht dort natürlich kein harmloser Alert-Dialog, sondern Code, der etwa Session-Cookies ausliest und an einen fremden Server sendet. Kodiert die Website denselben Kommentar dagegen vor der Anzeige, wird aus dem gefährlichen Skript-Tag der harmlose, sichtbare Text <script>alert('gehackt')</script>, lesbar, aber vollständig wirkungslos.
Aus diesem Grund kodieren so gut wie alle modernen Web-Frameworks nutzergenerierte Inhalte standardmäßig automatisch, bevor sie in die Seite eingefügt werden. Wer rohes HTML dennoch manuell zusammenbaut, etwa beim Erstellen eines E-Mail-Templates, eines Server-Log-Viewers oder eines einfachen serverseitigen Renderers ohne Framework, trägt diese Verantwortung selbst und sollte jeden Wert, der aus einer nicht vertrauenswürdigen Quelle stammt, vor der Einfügung in HTML konsequent kodieren.
Typische Anwendungsfälle für den HTML Entity Encoder
Dieselbe Kodierung landet je nach Beruf und Projekt auf ganz unterschiedlichen Schreibtischen. Ein paar Situationen tauchen dabei besonders häufig auf.
- Technische Dokumentation. Wer in einem Tutorial, einer README-Datei oder einer Wissensdatenbank ein Codebeispiel mit HTML-, JSX- oder XML-Syntax zeigen will, muss die enthaltenen spitzen Klammern kodieren, damit der Beispielcode als Text sichtbar bleibt, statt vom Browser als echtes Markup verarbeitet zu werden.
- Kommentarfunktionen und Foren. Jede Plattform, die Nutzern erlaubt, eigenen Text zu veröffentlichen, muss diesen Text vor der Anzeige kodieren. Andernfalls kann ein einzelner böswilliger Beitrag Skriptcode enthalten, der bei jedem Besucher der Seite ausgeführt wird.
- RSS- und Atom-Feeds. Feed-Formate sind selbst XML-basiert, weshalb Titel und Beschreibungstexte, die Sonderzeichen wie kaufmännische Und-Zeichen enthalten, korrekt kodiert werden müssen, damit Feed-Reader die Datei überhaupt fehlerfrei einlesen können.
- Legacy-Systeme und einfache Templates. Ältere Content-Management-Systeme oder handgeschriebene serverseitige Templates ohne automatisches Escaping verlangen, dass Autorinnen und Autoren Sonderzeichen selbst kodieren, bevor ein Text in die Seite eingefügt wird.
- Aufbereitung kopierter Inhalte. Wird Text aus einer Textverarbeitung oder einer anderen Anwendung kopiert und enthält dabei bereits HTML-Entities, etwa aus einem exportierten Dokument, lässt sich dieser Text hier mit einem Klick zurück in lesbaren Klartext dekodieren, bevor er weiterverarbeitet wird.
In allen diesen Fällen erledigt dieses Werkzeug denselben letzten Schritt: Text sicher und korrekt zwischen seiner rohen Form und seiner HTML-tauglichen Form hin und her zu übersetzen, ohne dass dafür eine eigene Codezeile geschrieben oder ein zusätzliches Paket in ein Projekt eingebunden werden muss.
Häufig gestellte Fragen
Verwandte Entwicklertools
🔒 100% Clientseitige Privatsphäre
Die gesamte HTML-Kodierung und -Dekodierung erfolgt <strong>vollständig in Ihrem Browser</strong>. Es wird niemals Text oder Code auf einen Server hochgeladen. Ihre Code-Schnipsel bleiben jederzeit auf Ihrem Gerät.