Escapen und Unescapen von HTML-Entities. Konvertieren Sie < > & " ' in benannte Entities, codieren Sie optional alle Nicht-ASCII-Zeichen und decodieren Sie benannte oder numerische Referenzen zurück in Text.
Escapen Sie Text, damit er sicher innerhalb von HTML ist, oder verwandeln Sie Entities zurück in Zeichen. Geben Sie in eines der beiden Felder ein, um in diese Richtung zu konvertieren. Der Minimal-Modus escaped nur die fünf Zeichen, die für die Korrektheit wichtig sind; der erweiterte Modus codiert zusätzlich jedes Nicht-ASCII-Zeichen für maximale Kompatibilität.
Ein HTML-Parser liest < als Beginn eines Tags und & als Beginn einer Entity-Referenz. Enthält Ihr Inhalt eines davon, hört der Parser auf, es als Text zu behandeln. Escapen ersetzt das Zeichen durch eine Referenz, die der Parser wieder auf das ursprüngliche Glyph auflöst, ohne ihm jemals eine strukturelle Bedeutung zu geben.
Nur fünf Zeichen müssen in HTML wirklich escaped werden:
& wird zu & — muss zuerst erfolgen, sonst escapen Sie alles andere doppelt
< wird zu <
> wird zu >
" wird zu " — erforderlich innerhalb von doppelt in Anführungszeichen gesetzten Attributwerten
' wird zu ' — erforderlich innerhalb von einfach in Anführungszeichen gesetzten Attributwerten
In Elementtext benötigen Sie streng genommen nur & und <. Die anderen drei sind wichtig, sobald Ihr Text in einem Attribut landen kann, und da Sie das an der Escaping-Stelle selten kontrollieren, ist das Escapen aller fünf die sichere Gewohnheit.
Benannte, dezimale und hexadezimale Referenzen
Dasselbe Zeichen kann auf drei Arten geschrieben werden. Ein geschütztes Leerzeichen ist ,   oder  . Benannte Referenzen sind am lesbarsten, aber die HTML5-Liste hat etwa 2.200 Einträge und ältere Parser kennen weit weniger, sodass obskure Namen ein Portabilitätsrisiko darstellen. Numerische Referenzen funktionieren für jeden Unicode-Codepunkt und sind immer sicher. Jede benannte Referenz in HTML5 erfordert das abschließende Semikolon; eine Handvoll Legacy-Namen wie & wird ohne es aus Rückwärtskompatibilität weiterhin geparst, aber sich darauf zu verlassen ist ein Fehler, der nur darauf wartet, zu passieren.
Escapen ist nicht Sanitisieren
Escapen ist das, was Cross-Site-Scripting stoppt: wenn eine Benutzereingabe mit <script> zu <script> escaped wird, rendert der Browser den literalen Text und führt nichts aus. Aber Escapen funktioniert nur, wenn es im richtigen Kontext geschieht. HTML-Escapen reicht nicht innerhalb eines <script>-Blocks, innerhalb eines style-Attributs oder in einer URL – jeder davon benötigt seine eigene Codierung. Und Escapen muss einmalig zum Zeitpunkt der Ausgabe angewendet werden. Escapen bei der Eingabe und erneut bei der Ausgabe erzeugt &lt; und sichtbaren Müll.
Wann Sie den erweiterten Modus benötigen
Das Escapen von Nicht-ASCII-Zeichen wird von keiner modernen Spezifikation verlangt. Ein UTF-8-Dokument kann é und 中 direkt enthalten, und das ist meist die bessere Wahl: es ist kürzer, lesbarer und leichter zu durchsuchen. Der erweiterte Modus existiert für die Fälle, in denen der Byte-Strom einen Kanal überleben muss, der Nicht-ASCII verstümmelt – einige Legacy-E-Mail-Vorlagen, ältere CMS-Felder, XML-Pipelines mit unklarer deklarierter Kodierung oder ein Build-Schritt, der in Latin-1 feststeckt. Wenn Sie die Kodierung von Ende zu Ende kontrollieren, bleiben Sie im Minimal-Modus.
Die geschützte-Leerzeichen-Falle
ist U+00A0, ein anderes Zeichen als das gewöhnliche Leerzeichen U+0020. Es verhindert einen Zeilenumbruch und stoppt Browser daran, Folgen von Leerzeichen zusammenzufalten, weshalb WYSIWYG-Editoren es großzügig ausgeben. Da es identisch aussieht, bricht es stillschweigend String-Vergleiche, mit \s geschriebene reguläre Ausdrücke in einigen Engines und CSV-Importe. Wenn ein Wert korrekt aussieht, sich aber nicht abgleichen lässt, prüfen Sie auf ein verirrtes geschütztes Leerzeichen.
FAQs
Muss ich das Größer-als-Zeichen escapen?
Streng genommen nein — ein alleinstehendes > im Text ist eindeutig und wird korrekt geparst. Es wird aus Konvention escaped, weil es nichts kostet und Verwirrung in generiertem Markup vermeidet, besonders wenn die Ausgabe später von Werkzeugen verarbeitet wird, die strenger als ein Browser sind.
Warum muss & zuerst escaped werden?
Weil jede andere Escape-Sequenz mit einem Kaufmanns-Und beginnt. Wenn Sie < durch < ersetzen, bevor Sie & escapen, würde der nächste Durchlauf dieses Kaufmanns-Und zu & machen und Sie landen mit &lt; auf der Seite.
Reicht Escapen, um XSS zu verhindern?
Nur für HTML-Text- und Attribut-Kontexte, und nur wenn es bei der Ausgabe angewendet wird. Inhalt, der in JavaScript, CSS oder eine URL injiziert wird, benötigt stattdessen die Escaping-Regeln dieser Sprache. Escapen ist eine Schicht, keine vollständige Verteidigung.
Benannte oder numerische Entities — welche sollte ich verwenden?
Numerische Referenzen werden universell unterstützt und funktionieren für jeden Codepunkt. Benannte Referenzen sind lesbarer für die Handvoll, die jeder kennt. In der Praxis verwenden Sie benannt für die fünf Kernzeichen und numerisch für alles Ungewöhnliche.
Sollte ich akzentuierte Zeichen codieren?
Nicht in einem UTF-8-Dokument, was im Grunde der gesamte moderne Web-Inhalt ist. Schreiben Sie sie direkt. Verwenden Sie den erweiterten Modus nur, wenn etwas in Ihrer Pipeline nicht vertrauenswürdig genug ist, um Nicht-ASCII-Bytes intakt zu tragen.
Was ist der Unterschied zwischen und einem normalen Leerzeichen?
Ein geschütztes Leerzeichen ist Codepunkt U+00A0. Es sieht gleich aus, verhindert aber Zeilenumbrüche und wird nicht mit angrenzendem Leerraum zusammengefasst. Es ist auch ein eigenes Zeichen für Vergleichszwecke, was es zu einer häufigen Quelle für subtile Fehler macht.