Neulich schickte mir ein Kunde einen Screenshot: Auf seiner Kontaktseite stand statt „Bäckerei Müller & Söhne" plötzlich „Bäckerei Müller & Söhne" – also wörtlich das kaufmännische Und, gefolgt von „amp". Er dachte, ich hätte mich vertippt. Hatte ich nicht. Das Problem war ein fehlendes Semikolon in einer HTML-Entity, und die Seite zeigte seit Wochen fröhlich den kaputten Code an, weil niemand hingeschaut hatte.
Solche Sachen passieren ständig. Sonderzeichen in HTML sind eines dieser Themen, bei denen fast jeder denkt, er hätte es im Griff – bis dann das Euro-Zeichen als „&euro" ohne Semikolon in der Rechnung steht oder ein Umlaut als „ä" auftaucht. Ich zeige Ihnen hier, wie Sie Sonderzeichen in HTML korrekt einsetzen, wann Sie Entities brauchen und wann nicht, und warum die meisten Listen im Netz Ihnen mehr schaden als helfen.
Wichtige Erkenntnisse
- Mit <meta charset="utf-8"> im Head können Sie die allermeisten Zeichen direkt tippen – Entities sind dann nur noch für Sonderfälle nötig.
- Nur fünf Zeichen müssen als Entity geschrieben werden: &, <, > und in Attributen die Anführungszeichen.
- Named Entities (
ä) sind lesbarer, numerische (ä) sind universeller – für moderne Projekte ist UTF-8 plus Klartext meist die bessere Wahl. - Ein fehlendes Semikolon am Ende einer Entity ist der häufigste Fehler überhaupt – und der Browser verzeiht ihn oft genug, dass er monatelang unbemerkt bleibt.
- Für Pfeile, Kreise und Telefon-Symbole gibt es keine durchgängigen deutschen Entity-Namen – hier arbeiten Sie fast immer mit Unicode-Nummern.
Warum Ihr Browser manchmal Zeichensalat anzeigt
Der häufigste Grund für zerstörte Sonderzeichen ist ein Encoding-Konflikt: Die Datei ist in UTF-8 gespeichert, der Server schickt aber einen Content-Type-Header mit ISO-8859-1, oder die Meta-Angabe fehlt komplett. Dann interpretiert der Browser die Bytes anders, als sie gedacht waren – und aus einem harmlosen „ä" wird „ä".
Ich hatte das selbst bei einem Kundenprojekt, wo die Datenbank stillschweigend in Latin-1 lief, während das Frontend UTF-8 erwartete. Ergebnis: jeder dritte Produktname mit Umlaut kaputt. Die Reparatur dauerte zwei Tage, weil wir rückwärts durch vier Systeme suchen mussten, wo die Konvertierung schiefging.
Die eine Zeile, die alles löst
Setzen Sie in den <head> Ihrer Seite:
<meta charset="utf-8">
Diese Angabe sollte innerhalb der ersten 1024 Bytes des Dokuments stehen, sonst ignoriert der Browser sie unter Umständen. Und wenn Sie zusätzlich serverseitig einen HTTP-Header senden, achten Sie darauf, dass beide dieselbe Kodierung nennen. Zwei sich widersprechende Angaben sind schlimmer als eine fehlende.
Named Entity, numerisch oder Klartext?
Hier scheiden sich die Geister, und ich habe eine klare Meinung dazu: In modernen Projekten tippen Sie das Zeichen direkt. Für Sonderfälle gibt es aber gute Gründe für die eine oder andere Form.
| Form | Beispiel | Wann sinnvoll |
|---|---|---|
| Klartext | ä | Standard bei UTF-8 – beste Lesbarkeit im Code, keine Tippfehler bei Entities |
| Named Entity | ä | Lesbar auch in alten Mails, CMS-Feldern ohne Encoding-Kontrolle, wenn die Datei selbst nicht UTF-8 ist |
| Numerisch dezimal | ä | Wenn es keinen Namen gibt – z. B. bei vielen Pfeilen und geometrischen Formen |
| Numerisch hexadezimal | ä | Funktional identisch zu dezimal, kürzer bei hohen Codepoints (griechisch, Emoji) |
Mein Rat: Solange Sie <meta charset="utf-8"> gesetzt haben, schreiben Sie das Zeichen. Entities sind ein Werkzeug für alte Systeme und für Zeichen, die Sie auf der Tastatur nicht finden – nicht für flächendeckendes Escaping „zur Sicherheit". Das macht den Quellcode unlesbar und führt zu genau der Verwirrung, die mein Bäckerei-Kunde erlebt hat.
Die fünf Zeichen, die Sie wirklich escapen müssen
Das ist der praktisch wichtigste Punkt, und er wird in den meisten Listen untergeht: Sie brauchen nicht hunderte Entities. Sie brauchen vier, plus eine situative Regel.
- & →
&– sonst beginnt der Browser, eine Entity zu lesen - < →
<– sonst denkt der Parser, ein Tag beginnt - > →
>– technisch selten zwingend, praktisch oft nötig - " →
"– in Attributwerten, die selbst in Anführungszeichen stehen - ' →
'– ebenfalls in Attributen und in dynamisch zusammengebauten Strings
Achten Sie auf die letzte Zeile: Für das einfache Anführungszeichen gibt es keinen offiziellen Entity-Namen in HTML. ' existiert nur in XML, nicht in HTML – manche Browser interpretieren es trotzdem, aber verlassen Sie sich nicht darauf. Ich habe das einmal in einem Formular verbaut, das in älteren Safari-Versionen dann tatsächlich den Fehler „unterminated attribute" warf. Peinlich.
Der Fall „vioma" – und was das über Suchanfragen verrät
Immer wieder sehen Sie Suchanfragen wie „html sonderzeichen vioma" – das ist kein Zeichen, das ist ein Firmenname, der versehentlich in die Suche gerutscht ist. Ähnlich verhält es sich mit Begriffen wie „sonderzeichen html quadrat" oder „html sonderzeichen kreis": Hier suchen Leute eigentlich nach geometrischen Symbolen wie ■, □, ●, ○ oder einem Quadrat als Aufzählungszeichen. Den Namen □ gibt es in HTML, aber die meisten praktisch gebrauchten Formen sind numerisch – und die Liste der Unicode-Zeichen ist schlicht zu lang für einen Namen.
Was wirklich hilft: eine eigene kleine Referenzdatei mit den 20 Symbolen, die Sie tatsächlich benutzen. Ich habe mir vor Jahren eine gebaut, sie hat 34 Zeilen, und ich öffne sie öfter als jede Online-Tabelle.
Pfeile, Telefon, Leerzeichen – die praktischen Fälle
Pfeile in HTML
Für Navigationspfeile reichen meist → (→), ← (←) und ↑ (↑). Für schräge Varianten gibt es ↗, ↘ und so weiter. Aber ehrlich: In modernen Interfaces greife ich fast immer zu SVG oder einer Icon-Font, weil Entities im Fließtext zwar funktionieren, aber nicht skalierbar sind. Ein Pfeil als Textzeichen hat keine Größensteuerung außer der Schriftgröße – ein SVG schon.
Telefon-Symbole
Es gibt kein „Telefon-Entity" in HTML im strengen Sinn. Sie können das klassische Telefon-Symbol ☎ (numerisch ☎) verwenden, aber das ist ein Dingbat-Zeichen aus Unicode und sieht je nach Schriftart komplett unterschiedlich aus. In einem Projekt mit einer reinen Systemschrift-Stack zeigte es sich auf Windows als klobiger alter Hörer, auf macOS als filigranes Symbol – das wirkte auf der Seite wie ein Fehler. Besser: ein SVG oder ein Icon-Set.
Leerzeichen und geschützte Leerzeichen
ist eine der meistgenutzten Entities überhaupt – und eine der meistmissbrauchten. Es erzeugt ein geschütztes Leerzeichen, das nicht umbricht. Das ist sinnvoll bei „10 km" oder „Dr. Müller", damit die Einheit nicht allein in die nächste Zeile rutscht. Es ist aber kein Werkzeug für Abstände im Layout – dafür gibt es CSS. Wenn Sie zehnmal hintereinander setzen, um einen Text einzurücken, machen Sie etwas falsch. Das sage ich ohne jede Ironie, weil ich es selbst jahrelang so gemacht habe.
Für einen schmalen geschützten Abstand gibt es übrigens   und   – nützlich für typografische Feinheiten, aber für den Alltag meist überflüssig.
Drei Fallen, in die ich selbst getappt bin
Das fehlende Semikolon
Der Klassiker. © ohne Semikolon – manche Browser rendern es als ©, andere als Text „©". Das Verhalten hängt von der folgenden Zeichenkombination ab. Ergebnis: Ein Fehler, der auf dem Entwicklungsrechner nie auftaucht, beim Kunden aber sofort.
Doppelte Kodierung
Wenn Daten aus einer Datenbank kommen, die schon HTML-escaped sind, und Sie sie nochmals durch htmlspecialchars() in PHP jagen, kommt „&" heraus und wird als „&" angezeigt. Ich habe das in einem Newsletter-System erlebt, wo Umlaute nach einem Update als „ä" in den Mails standen – 32.000 Empfänger haben das gesehen, bevor es jemand meldete.
Anführungszeichen in Attributen
<a title="Der "beste" Link"> bricht das Attribut mitten im Wert. Konsequent escapen, oder – besser – außen einfache und innen doppelte Anführungszeichen verwenden. Klingt banal, ist es aber nicht, wenn der Titel dynamisch aus einer Nutzereingabe kommt.
Was am Ende bleibt
Wenn Sie sich nur eine Sache aus diesem Text mitnehmen: Setzen Sie <meta charset="utf-8">, und schreiben Sie Sonderzeichen im Zweifel direkt. Die unzähligen Entity-Tabellen im Netz sind beeindruckend, aber für 95 Prozent Ihrer Arbeit brauchen Sie fünf Zeilen daraus.
Was mich bis heute beschäftigt: Wie viele dieser Fehler monatelang unbemerkt bleiben, weil wir selbst beim Testen immer dieselben drei Seiten aufrufen. Mein Bäckerei-Kunde hätte das „&" nie gefunden – seine Stammkunden auch nicht, die haben einfach gedacht, der Laden heißt jetzt so.
