Kodieren ersetzt Zeichen, die in Markup Bedeutung haben, durch ihre Entity-Entsprechungen, damit sie als Text erscheinen statt als Code gelesen zu werden. Die fünf, auf die es immer ankommt, sind das kaufmännische Und, die beiden spitzen Klammern und beide Anführungszeichen — sie sind es, die Benutzereingaben in ein script-Tag verwandeln, und sie zu maskieren ist die älteste Abwehr dagegen. Wie weit Sie darüber hinausgehen, entscheiden Sie.
Der benannte Umfang verwendet lesbare Entities für rund vierzig gängige Zeichen — das Copyright-Zeichen, typografische Anführungszeichen, Gedankenstriche, Buchstaben mit Akzent — und fällt für alles Übrige oberhalb von ASCII auf numerische Referenzen zurück. Beim Dekodieren läuft der Text durch den Parser des Browsers selbst, über ein losgelöstes Element, das jede dem Browser bekannte Entity auflöst, ohne irgendetwas auszuführen, denn dieses Element wird nie in die Seite eingehängt.
Wie viel kodieren, und wann
-
Die fünf Sonderzeichen sind die sicherheitsrelevanten:
Alles andere ist eine Frage der Darstellung oder des Transports. Wenn Sie Benutzereingaben für eine Seite maskieren, kommt es auf diese fünf an.
-
Moderne Seiten brauchen den Rest selten:
Mit UTF-8, das heute nahezu überall gilt, dürfen ein Buchstabe mit Akzent oder ein typografisches Anführungszeichen als sie selbst im Quelltext stehen. Vollständiges Kodieren ist für ältere Systeme, E-Mail-Vorlagen und alles, wo die Kodierung unsicher ist.
-
Benannte Entities sind lesbar, numerische universell:
Die benannte Form erkennt man leichter im Quelltext; die numerische funktioniert auch dort, wo ein Name nicht erkannt wird.
-
Das ist Maskieren, nicht Bereinigen:
Kodieren lässt Markup als Text erscheinen. Es entfernt nichts Gefährliches aus HTML, das Sie als HTML behalten wollen — das ist eine andere Aufgabe und braucht einen echten Sanitizer.
Five characters carry the actual security weight
The ampersand, the two angle brackets and both kinds of quote are what turn ordinary user input into an actual script tag if left unescaped, and encoding them is the oldest defence against exactly that. The [msm_tool slug="html-entities"] handles those five as the essential case; everything past them is a question of display rather than safety.
Modern, UTF-8 pages rarely need the rest
With UTF-8 now close to universal, an accented letter or a curly quote can sit directly in the page source as itself without needing an entity at all. Encoding beyond the five essential characters is mainly for older systems, email templates, or anywhere the page's encoding is genuinely uncertain rather than something every page needs by default.
Named entities read better, numeric ones work everywhere
The named scope covers around forty common characters — the copyright sign, curly quotes, dashes, accented letters — with readable entities, and falls back to numeric references for anything above that. A named entity is easier to recognise sitting in source code; a numeric one works even in the rare case a particular name is not recognised by whatever is reading it.
This is escaping, not sanitising
Encoding makes markup display as literal text rather than being interpreted as code, which is a genuinely different job from removing something dangerous out of HTML that is meant to stay HTML. Escaping output when it should read as plain text is the right tool here; cleaning up markup that must remain markup needs an actual sanitiser instead.
Decoding is safe because nothing ever runs
Decoding is done by handing the text to the browser's own parser through an element that is never attached to the page, so every entity the browser recognises gets resolved without any script content ever having the chance to execute. The element stays detached for the entire operation, which is what makes decoding untrusted input safe to do at all.