HTML-Entity-Encoder-Decoder: Flucht, Entweichen und Stoppen von Versand & amp; amp; an die Produktion

Um 2021 landete ein WP Adminify Support Ticket mit einem Screenshot, der mich immer noch zusammenzucken lässt. Ein Benutzer hatte einen benutzerdefinierten Administrator-Fußzeilentext festgelegt - eine perfekt unschuldige Copyright-Zeile mit a © und ein Link zu ihrer Agentur. Auf ihrem Bildschirm wurde es als © 2021 — Bright & Codrohen Drei sichtbare Entitäten, null gerenderte Zeichen. Der Schuldige war ich. Meine Speicherroutine entkam dem Text, meine Render-Routine entkam erneut und irgendwo dazwischen ist ein Filter ein drittes Mal. Als es den Browser traf, war dieser arme kaufmännische und viermal entkommen. Ich habe gezählt.

Die Lösung dauerte zehn Minuten. Es dauerte zwei Abende, weil es entkamen Text-Looks fast richtig du überflog © in einem Datenbank-Dump und Ihr Gehirn korrigiert es automatisch ©drohen Am Ende habe ich immer wieder Zeichenfolgen in eine scratch-HTML-Datei eingefügt, um zu sehen, was der Browser tatsächlich auf jeder Ebene rendern würde. Das ist ein miserabler Workflow, und genau deshalb ist ein HTML-Entity-Encoder-Decoder eines der ersten Tools, die ich in toolz.dev eingebaut habe.

Die Kehrseite derselben Münze ist beängstigender. Einige Monate vor diesem Ticket fand ich während einer Codeüberprüfung meines eigenen Plugins ein Einstellungsfeld, das die Eingabe von Benutzern in eine Administratormitteilung ohne Echo esc_html()drohen Jeder, der Zugriff auf dieses Feld hat, könnte gespeichert werden <script> und ließ es für jeden Administrator ausführen, der die Seite geladen hatte. Gespeichert XSS, in meinem eigenen Code, ein fehlender Funktionsruf entfernt. Niemand hat es ausgenutzt - ich hatte Glück. Aber es hat meine Meinung über das Entkommen permanent verändert: Es ist keine Formatierungsaufgabe, es ist die Grenze zwischen "Text" und "Code".

Diese Anleitung deckt also beide Richtungen ab. Codierung, also bleibt nicht vertrauenswürdiger Text Text. Dekodierung, so dass Sie lesen können, was eine übereifrige Pipeline verstümmelt hat. Und genug Theorie - genannt vs numerische Referenzen, die fünf Zeichen, die tatsächlich wichtig sind, warum die Reihenfolge der Operationen doppelt entweicht -, dass Sie dieses Zeug debuggen können, anstatt zu raten.

tl; dr: Fügen Sie Ihren Text in die toolz.dev HTML-Entitäten Encoder/Decoder Konvertieren zwischen Rohzeichen und Entitäten in beide Richtungen - benannt, dezimal oder hex. Es läuft 100% clientseitig, so dass Benutzerinhalte und PII Ihren Browser niemals verlassen. Faustregel: Entfliehen Sie immer den fünf Specials (& < > " ') in nicht vertrauenswürdiger Eingabe und Codierung & Zuerst oder Sie werden doppelt entkommen.

Hauptmerkmale

In beide Richtungen codieren und dekodieren

Die halbe Zeit muss ich umdrehen <script> in <script> So wird es als Text in einem Blog-Beitrag angezeigt. Die andere Hälfte gehe ich in die entgegengesetzte Richtung - drehe einen Kratzer ’s Zurück in einen lesbaren Apostroph. Das Werkzeug verarbeitet beides. Text einfügen, verschlüsseln oder dekodieren, fertig. Keine Modejagd, kein separates Werkzeug für jede Richtung. Das klingt trivial, bis Sie Tools verwendet haben, die nur dekodiert werden, und Sie finden eine zweite Registerkarte, um ein Codebeispiel für Ihre Dokumente zu codieren. Round-Tripping ist auch eine großartige Überprüfung der Gesundheit: Kodieren, dekodieren und bestätigen Sie, dass Sie Ihre ursprüngliche Zeichenfolge zurückbekommen. Wenn Sie dies nicht tun, wurde bereits etwas in Ihrer Eingabe teilweise entgangen - was selbst nützliche Informationen ist.

Benannte Entitäten: &, & amp;lt;, & amp; kopieren; und Freunde

Benannte Zeichenreferenzen sind die vom Menschen lesbaren — & für &, < für <, © für ©, — Für einen EM-Dash. Das Werkzeug trägt eine kuratierte Tabelle mit 147 Namen, nicht nur die berühmten Five: Typografie ( , …, ’, “), Währung, Mathematik und Pfeile, griechische Buchstaben, die volle latein1-akzente Reichweite und einige Quoten wie Kartenanzüge. Diese Reichweite ist das, was reale Inhalte tatsächlich benötigen - WordPress emittiert  , …, und ’ Durch wptexturize ständig und ein Decoder, der nur ein Dutzend Namen kennt, lässt die Hälfte Ihres Textes mit ungelösten Referenzen übersät.

Seien Sie sich darüber im Klaren, was 147 nicht ist: Der WhatWG-HTML-Standard definiert über 2.200 benannte Referenzen, daher ist dies eher eine praktische Teilmenge als die vollständige Tabelle. Wenn ein Name nicht darin ist, lässt die Dekodierung die Referenz nicht mehr als raten - &bogus; kommt raus als &bogus;drohen Die Codierung hat das komplementäre Verhalten und es ist die nützlichere Hälfte: jeder Charakter ohne Ein Name in der Tabelle wird automatisch auf eine dezimale numerische Referenz zurückgeführt, sodass nichts stillschweigend fallen gelassen wird. Ein Emoji kodiert als 🌍, chinesischer Text als 你好drohen Namen, wo sie existieren, überall sonst.

Eine weitere Abweichung vom Verhalten des Browsers: Der Decoder ist CASE-sensitive und benötigt das Semikolon. Browser werden aufgelöst © Und sogar eine nackte &amp Ohne ein nachlaufendes Semikolon in einigen Parsing-Kontexten dank älterer Kompatibilitätsregeln; dieser Decoder löst keine auf. In der Praxis ist das in Ordnung - alles ein modernes Werkzeug erzeugt ist in Kleinbuchstaben und beendet - aber wenn Sie abgekratztes HTML von einem alten CMS dekodieren, ist dies die Kante, die Sie treffen werden.

Numerische Referenzen: Dezimal und Hexadezimal

Jedes Unicode-Zeichen kann als numerische Zeichenreferenz geschrieben werden - dezimal wie — oder hex wie — (Beide sind ein EM-Dash). Der Decoder löst beide Formen auf. Dies ist die Fluchtschraffur für Zeichen, die im Standard keinen Namen haben, und dies ist die Form, die Sie in API-Antworten und RSS-Feeds ständig treffen werden. ’ (rechtes Einzelangebot) ist praktisch eine Signatur. Hex-Referenzen-Zuordnung direkt auf Unicode-Code-Punkte — U+2014 — — Deshalb bevorzuge ich sie, wenn ich gegen ein Unicode-Diagramm querverweisen.

Ehrliche Einschränkung, da Sie es innerhalb einer Minute nach der Verwendung des Tools bemerken werden: die numerische verschlüsseln Modus gibt nur Dezimalzahlen aus. Es gibt keine Hex-Ausgabeoption. Dekodierung — Funktioniert gut, der Encoder bittet, es zu produzieren. Die beiden Formulare sind semantisch identisch mit jedem Browser, so dass Sie nichts funktional kostet, aber wenn Ihre Codebasis auf Hex standardisiert, werden Sie von Hand umgewandelt. Es ist auf meiner Liste. Referenzen außerhalb der Reichweite werden eher erwischt als verstümmelt — � liegt über dem Unicode-Maximum und gibt einen expliziten Fehler anstelle eines Ersatzzeichens zurück.

Volle Unicode-Abdeckung

Emoji, CJK-Charaktere, Arabisch, die Diakritika kombiniert, die Werke. Wenn es einen Codepunkt hat, kann das Tool ihn als Entität ausdrücken und zurück auflösen. Dies ist wichtiger als Sie für die Lokalisierungsarbeit denken würden - ich habe deutsche Umlaute als ankommen ü von einem Übersetzungsanbieter und als RAW UTF-8 ü von einer anderen, in derselben Importdatei. Ein Werkzeug, das außerhalb von Latin-1 erstickt, ist dafür nutzlos. Zeichen über U + FFFF (Emoji leben dort) werden als einzelne Codepunkte korrekt behandelt, nicht als verstümmelte Ersatzpaare.

Entwirren Sie den doppelt entrinnenden Text

der & Problem Wenn zwei Schichten einer Pipeline entweichen, & wird & - und drei Schichten geben dir &drohen Die Dekodierung löst sich einmal genau eine Schicht ab, sodass Sie den Decoder wiederholt ausführen und das Zwiebeln auspacken können: & → & → & → &drohen Das Zählen der Pässe zeigt Ihnen an, wie viele Schichten Ihres Stapels entkommen. Dies ist genau die Diagnose, die ich während des vierfachen WP-Adminify-Fußzeilenfehlers benötigte. Eine Dekodierung pro Schicht. Es ist der schnellste Weg, den ich kenne, um zu lokalisieren, wo in einer Pipeline das zusätzliche Entkommen stattfindet.

Nebeneinander geschnittene Fenster mit Charakterzählungen

Eingabe links, Ausgabe rechts, Zeichen zählt über beiden. Dieses Count-Paar leistet mehr Arbeit als es sich anhört: Escaping ist eine Erweiterung, wenn Sie also 40 Zeichen codieren und 44 zurückerhalten, wurde genau ein Sonderzeichen berührt. Wenn ich auditive, ob eine Vorlage bereits etwas entkommen ist, sagt mir das Delta, bevor ich ein einzelnes Ausgabezeichen gelesen habe. Codieren, Dekodieren, Tauschen und Löschen sind Schaltflächen - es gibt keine Live-As-You-Typ-Konvertierung, die ich zugeben werde, dass ich einen absichtlichen Kompromiss bin, den ich manchmal bereue. Explizite Aktionen bedeuten, dass Sie immer wissen, in welche Richtung der Text erstellt wurde, den Sie betrachten, und mit entweichenden Fehlern ist diese Mehrdeutigkeit das ganze Problem. Aber zum Erkundungsstupsen wäre eine tastengesteuerte Version wirklich schöner.

100% clientseitig - nichts hochgeladen

Alles läuft in Ihrem Browser. Keine Anfrage, kein Server, keine Protokolle. Dies ist nicht schön: Der Text, dem Sie entkommen, ist oft genau der Text, den Sie nicht in zufällige Websites einfügen sollten - benutzergenerierte Kommentare mit echten Namen, E-Mail-Vorlagen mit Kundenadressen, Support-Ticket-Inhalte. Ich habe schon einmal darüber geschrieben, warum dies wichtig ist Unser Datenschutz-Guide; Die Kurzversion ist, dass ein Konverter, der Ihre Eingabe hochlädt, ein Datenprozessor ist, den Sie nie überprüft haben. der toolz.dev Entity-Tool Funktioniert einmal geladen offline. Der Flugzeugmodus ist ein gültiger Test - versuchen Sie es.

So verwenden Sie den HTML-Entitäts-Encoder und den Decoder

Schritt 1: Öffnen Sie das Werkzeug und fügen Sie Ihren Text ein

aufsuchen toolz.dev/tools/html-entities und fügen Sie Ihre Eingaben ein - ein Code-Snippet, ein verstümmelter RSS-Auszug, ein E-Mail-Vorlagenfragment, was auch immer. Es gibt keine große Deckengröße, die sich für den normalen Gebrauch Sorgen machen muss; ich habe ganze gerenderte Plugin-Changelogs eingefügt. Da die Verarbeitung clientseitig ist, ist sensibler Inhalt hier in Ordnung.

Schritt 2: Wählen Sie Codieren oder Dekodieren

Die Codierung verwandelt Rohzeichen in Entitäten (< → <) — Verwenden Sie es, wenn Markup als Text angezeigt werden soll. Dekodierung löst Entitäten wieder in Zeichen (& → &) — Verwenden Sie es, wenn Sie entkommene Inhalte lesen. Wenn Sie sich nicht sicher sind, in welchem Zustand sich Ihr Text befindet, dekodieren Sie zuerst und sehen Sie, was sich ändert. Unveränderte Ausgabe bedeutet, dass es bereits klar war.

Schritt 3: Wählen Sie den Referenzstil (bei der Codierung)

Das Dropdown-Modus für Modus hat genau drei Optionen, und die Auswahl ist wichtiger als es aussieht. benannt Codiert alles, wofür es einen Namen hat und fällt im Rest auf Dezimal zurück - lesbar in Quelle und Diffs, aber es entgeht auch ©, —, é Und jedes andere Nicht-ASCII-Zeichen, das die Ausgabe aufbläht, wenn Sie sowieso auf UTF-8 sind. numerisch Macht die gleiche Abdeckung in reiner Dezimalzahl. Nur Sonderzeichen berührt nichts als & < > " ' Und hinterlässt Ihre Akzente, EM-Dashes und Emoji als RAW UTF-8 - dies ist derjenige, den ich für echten Inhalt verwende, und es ist der Modus, der zu dem passt, was htmlspecialchars() tut in PHP. Beachten Sie, dass ' kommt immer als heraus ', nie ', in allen drei Modi; das ist absichtlich, da ' ist in HTML 4 undefiniert und ältere E-Mail-Clients ersticken noch daran.

Schritt 4: Überprüfen Sie die Ausgabe und kopieren Sie sie

Klicken Sie auf "Codieren" oder "Dekodieren" und lesen Sie das rechte Fenster. Suchen Sie nach Dekodierungsjobs speziell nach Resten & Sequenzen - Ein Überlebender bedeutet, dass der Text doppelt entkommen wurde, also drücken Sie Swap und Decodieren Sie erneut. Kopieren Sie das Ergebnis beim Reinigen in Ihre Vorlage, Ihr CMS oder Ihren Code. Bei Wiederholungsaufträgen einmal Round-Trip (codieren und dekodieren), um nichts Loses zu bestätigen, ist bei Sonderzeichen-Nur-Modus die Hin- und Rückfahrt genau.

Benannte vs numerische Entitäten - und die fünf Zeichen, die tatsächlich wichtig sind

Lassen Sie uns die Terminologie klarstellen, denn "HTML Entity" wird lose verwendet. Der WhatWG HTML-Standard – die Living-Spezifikation, die definiert, wie Browser HTML-Parse tatsächlich angeben – gibt eine Tabelle von an Benannte Zeichenreferenzen: über 2.200 Namen wie  , —, …, →, jede Zuordnung zu einem oder zwei Unicode-Codepunkten. separat, Numerische Zeichenreferenzen Lassen Sie jeden Codepunkt direkt ansprechen: dezimal (—) oder hexadezimal (—).). Gleicher EM-Dash, drei Schreibweisen.

Hier ist meine Meinung, geschärft durch jahrelange WordPress-Arbeit: Von diesen über 2.200 Namen sind nur fünf Zeichen für die Richtigkeit und Sicherheit von Bedeutung. Alles andere ist Typografie, und auf einer UTF-8-Seite - auf jeder Seite, die Sie 2026 versenden sollten - können Sie einfach den echten Charakter eingeben. Sie brauchen nicht —;; Sie brauchen -. Die fünf, die wichtig sind, sind diejenigen mit syntaktischer Bedeutung in HTML:

Beachten Sie die letzte Zeile: ', nicht 'drohen der Name ' ist in HTML5 gültig, aber es war nicht Teil von HTML4, und alte Tooling (und alte E-Mail-Clients - dazu später mehr) können darauf stolpern. Die numerische Form funktioniert überall. Dies ist die Art von Pedanterie, die Ihnen einen verwirrenden Fehlerbericht erspart.

Die Reihenfolge der Operationen ist das ganze Spiel. Bei der Codierung, & muss entkommen sein vorwegdrohen Wenn Sie entkommen < auf < Und dann entkomme Ampersands, du wirst deine eigene Ausgabe in umwandeln < - Herzlichen Glückwunsch, Sie sind doppelt entkommen. Dekodierung ist das Spiegelbild: & muss gelöst werden letze, oder < wird < wird < Und Sie haben eine unterdekodierte (oder schlimmer noch, Live-Markup aus Text, der absichtlich entkommen ist). Fast jeder handgerollte, von mir überprüfte Fehler - einschließlich meiner eigenen - ist ein Bestellfehler.

Der Kontext ist wichtig, und hier trifft die Flucht auf die Sicherheit. Der OWASP-Cross-Site-Skript-Prävention-Cheat-Sheet ist stumpf: HTML-Entitätscodierung ist die richtige Verteidigung für das HTML Leichnam und zuschreiben Kontexte, aber es ist nicht Ausreichend für JavaScript-Strings, URLs oder CSS. < In einem <script> Blockieren nicht dekodieren - Skriptinhalt wird nicht für Entitäten analysiert - Entitätscodierung ist dort also nichts nützlich. Jeder Kontext benötigt einen eigenen Encoder: Entitätscodierung für HTML, \uXXXX Escapeing für JS-Strings, Prozent-Codierung für URLs (das ist es, was unser URL-Encoder/Decoder ist für). Die Verwendung des richtigen Encoders im falschen Kontext ist die klassische Art und Weise, wie saniert aussehender Code ausnutzbar bleibt.

Auf der PHP-Seite, kennen Sie Ihre beiden Funktionen. htmlspecialchars() entkommt nur den fünf Specials (Pass ENT_QUOTES oder Sie verpassen das einzelne Zitat - ein echtes Gotcha). htmlentities() Flucht alles das hat eine benannte Entität, die sich dreht ü in üdrohen Auf UTF-8 Seiten, htmlentities() ist fast immer die falsche Wahl, es bläht die Ausgabe auf und verstaut, wenn Zeichensätze falsch deklariert werden. WordPress packt dies sinnvoll:

echo esc_html( $footer_text );              // body context
echo '<a title="' . esc_attr( $title ) . '">'; // attribute context

esc_html() und esc_attr() Beide entkommen den fünf Specials mit den richtigen Flaggen, die pro Kontext ausgewählt werden - genau die spät entkommene Disziplin OWASP verschreibt. Die Regel bohre ich in jede Code-Überprüfung: Escape zur Ausgabezeit genau einmal im Ausgangskontext.

Was es nach Hause bringt: Mit UTF-8 Sie selten brauchen Entitäten für typografische Zeichen überhaupt. Sie benötigen sie für Markup-bedeutende Zeichen und für nicht vertrauenswürdige Eingaben. Alles andere ist Vermächtnisgewohnheit.

Häufige Anwendungsfälle

Anzeigen von Code-Snippets in Blog-Posts und Dokumenten

Schreiben Sie ein Tutorial mit <script> oder <?php und füge es in ein CMS RAW ein, und der Browser wird es versuchen ausführen oder schlucken Ihr Beispiel, anstatt es anzuzeigen. Jedes Codebeispiel in einem HTML-Kontext benötigt <, >, und & verschlüsselt. Ich mache dies ständig für die Plugin-Dokumentation - Readme HTML, Knowledge-Base-Artikel, Inline-Beispiele in den Registerkarten der Administrator-UI-Hilfe. Der Workflow: Schreiben Sie das Snippet, führen Sie es durch die Entitätsgeber, füge die entkommene Version hinein <pre><code>drohen dreißig Sekunden und Ihre <script> zeigt als <script> anstatt ins Dom zu verschwinden. Wenn Sie im Allgemeinen einen Docs-Workflow erstellen, können Sie Anleitung für die Coding-Tools Deckt den Rest der Toolbox um diese herum ab.

Bereinigung von doppelt entrinnendem Text aus Datenbanken und Feeds

der & Pest. Es wird angezeigt, wenn ein CMS beim Speichern auskommt, ein Plugin beim Rendern ausgeht und eine Caching-Ebene erneut hilfreich ist. Ich habe einmal ein WP-Administrations-Changelog verschickt, in dem der WordPress.org-Readme-Parser und mein eigenes Build-Skript nicht übereinstimmen, wer entkommt - das gerenderte Changelog hatte 23 sichtbar &s drin, bevor mir ein Benutzer eine E-Mail schickte. RSS-Feeds sind schlimmer; Feed-Inhalte werden häufig aus HTML-HTML entweichen Innenseite XML, also Verbraucher über- oder unterdecodieren es routinemäßig. Der Fix ist die diagnostische Dekodierung: Fügen Sie den defekten Text ein, dekodieren Sie einen Durchgang nach dem anderen, zählen Sie, wie viele Durchläufe es sind, bis es sauber ist. Diese Anzahl entspricht der Anzahl der ausweichenden Ebenen - jetzt wissen Sie genau, wie viele Teile Ihrer Pipeline den Text berühren, und Sie können die redundante finden.

Benutzergenerierte Inhalte sicher vorbereiten

Kommentare, Rezensionstext, Profil-BIOS, Support-Tickets – alles, was ein Benutzer eingegeben hat, ist nicht vertrauenswürdig und enthält häufig PII: echte Namen, E-Mails, Adressen. Hier kollidieren zwei Anliegen. Erstens: Sicherheit: Dieser Inhalt muss am Ausgang entitätscodiert werden, oder Sie sind eine <img onerror=...> Weg von gespeicherten XSS (fragen Sie mich nach dem Einstellungsfeld, das ich fast versandt habe). Zweitens Datenschutz: Wenn Sie debuggen wieso Wenn ein bestimmter Benutzer Ihr Layout unterbricht, behandeln Sie seine persönlichen Daten - das Einfügen in einen serverseitigen Konverter bedeutet, dass Sie PII an einen Dritten versenden. Das Toolz.dev-Tool verarbeitet alles lokal, so dass das Testen echter Problemzeichenfolgen sicher ist. Codieren Sie das Beispiel, überprüfen Sie Ihre Vorlage sollte haben produziert, diff gegen das, was es produziert hat.

E-Mail-HTML-Vorlagen

E-Mail-HTML ist eine Webentwicklung mit einer 20 Jahre alten Rendering-Engine. Einige Clients handhaben RAW UTF-8 mit Geldstrafe, andere - abhängig davon, wie Ihr ESP-Set überträgt, typografische Zeichen in Mojibake verstümmeln. Die defensive Konvention Viele E-Mail-Entwickler folgen immer noch: Codieren Sie Nicht-ASCII-Typografie als Entitäten (—, ’,   für Abstands-Hacks) also sind die Bytes auf dem Draht reines ASCII. Und erinnere dich ' drüben ' — Outlooks ältere Engines sind genau das Werkzeug, das HTML5-Namen nie gelernt haben. Da Vorlagen mit Kundennamen und Adressen personalisiert werden, wird dies wiederum nur über ein clientseitiges Tool ausgeführt. Codieren Sie die Vorlage Chrome einmal, lassen Sie die Felder roh und entgehen Sie zum Zeitpunkt der Zusammenführung.

Dekodierung von Scrap-Inhalten und API-Antworten

Kratzen Sie eine Seite oder verbrauchen Sie eine schlampige API und Sie werden ertrinken ’, “, &, und  drohen Einige APIs geben in JSON entitätscodierte Zeichenfolgen zurück - ein Format, das überhaupt kein HTML-Folgen benötigt -, sodass Sie Artefakte wie erhalten "title": "Fish & Chips"drohen Bevor diese Daten in Ihre eigene Datenbank gelangen, dekodieren Sie sie, um UTF-8 zu reinigen, kanonischen Text zu speichern und bei der Ausgabe zu entweichen. Ich habe dies ständig beim Importieren von Inhalten in Laravel-Apps getroffen: Entitäten zuerst dekodieren, dann Pretty-Print und inspizieren Sie die Nutzlast mit dem JSON-Formaterdrohen In der anderen Reihenfolge zu tun bedeutet, JSON zu lesen, wo jeder Apostroph sieben Zeichen lang ist. Wenn die Nutzlast darüber hinaus base64-verpackt ist - tun dies einige Webhook-Anbieter - die Base64-Konverter behandelt die äußere Schicht und unsere Base64-Codierungshandbuch Erklärt, warum diese Verpackung existiert.

Lokalisieren von Inhalten mit Sonderzeichen

Übersetzungsdateien kommen in jedem erdenklichen Zustand an. Ein Anbieter sendet saubere UTF-8 ü;; ein anderer sendet ü;; ein dritter sendet ü; Gelegentlich erhalten Sie alle drei in einer Po-Datei. Vor dem Import normalisiere ich alles auf RAW UTF-8 mit einem Decodierungspass - kanonischer Speicher, konsistente Suche, vernünftige Diffs. Dasselbe gilt für RTL-Interpunktion, CJK-Klammern und akzentuiertes Latein in versandten Saiten. Dekodieren Sie beim Import, speichern Sie reale Zeichen und lassen Sie Ihre Ausgabeebene nur den fünf Specials entgehen. Ihre Übersetzer werden Ihnen auch danken: über ist kein Wort, das jemand Korrektur lesen muss.

Benannt vs Dezimal gegen Hex vs RAW UTF-8: Welche sollten Sie verwenden?

Meine Haltung, klar: Schreiben Sie RAW UTF-8 für Typografie, Reserve-Entitäten für die fünf Specials und nicht vertrauenswürdige Eingaben. ein Dokument voller — und … ist ein Dokument, das niemand Korrekturlesen kann, und es signalisiert einen Workflow, der seinen Zeichensatzdeklarationen seit 2008 nicht vertraut hat. Moderne Stacks - WordPress, Laravel, Next.js, jede Datenbank, die Sie heute auswählen würden - sind UTF-8 von End to End. Geben Sie das wahre Zeichen ein.

Wo Unternehmen ihren Aufenthalt verdienen: &, <, >, ", und ' Für alles, was als Markup interpretiert werden könnte, immer, keine Ausnahmen, zur Ausgabezeit. Und in feindlichen Rendering-Umgebungen - E-Mail-Clients, Feeds, die von unbekannten Parsern verbraucht werden - sind numerische Referenzen die paranoide, aber gerechtfertigte Wahl, da sie jedes Kompatibilitätsargument vorab datieren. Zwischen Dezimal und Hex ist es Geschmack, ich lehne Hex, weil — Entspricht U + 2014 und ich kann aufhören, Basiskonvertierungen in meinem Kopf zu machen.

Häufig gestellte Fragen

Was ist eine HTML-Entität?

Eine HTML-Entität ist eine Textsequenz, die ein Zeichen darstellt, anstatt das Zeichen direkt zu schreiben. Es beginnt mit einem Ampersand und endet mit einem Semikolon. Es gibt benannte Referenzen wie & und &kopie;, und numerische Referenzen wie © (dezimal) oder © (hex), die an einem Unicode-Codepunkt zeigen. Browser lösen sie beim Parsen auf, so wird < als weniger als Zeichen angezeigt, anstatt ein Tag zu öffnen. Sie existieren, so dass Sie Zeichen anzeigen können, die sonst als Markup interpretiert werden würden.

Welche Zeichen müssen in HTML entflohen sein?

Fünf: Das Ampersund, weniger als, größer als, doppeltes Zitat und einfaches Zitat - geschrieben als & lt;, & gt; ", & # 39 ;. AMPERSAND, weil es Entitäten startet, die Kurven, weil sie Tags begrenzen, die Anführungszeichen, weil sie Attributwerte eingrenzen. Im Elementkörpertext können Sie nur mit den ersten drei davonkommen, aber alle fünf überall zu entkommen ist die Gewohnheit, die Sie niemals beißt. Alles andere - Akzente, Striche, Emoji - kann auf einer ordnungsgemäß deklarierten Seite RAW UTF-8 sein.

Was ist der Unterschied zwischen < als benannte Entität und & # 60;

Nichts, sobald der Browser sie analysiert hat - beide erzeugen ein weniger als Zeichen. Das benannte Formular ist eine Suche in der Tabelle der benannten Referenzen; &# 60; adressiert den Unicode-Code-Punkt 60 direkt und ' Benannte Entitäten sind für den Menschen leichter zu lesen; numerische Referenzen funktionieren für alle Zeichen, einschließlich Tausender, die keinen Namen haben. Wählen Sie für die allgemeinen Specials, welche Ihr Team besser lesbar findet - Browser ist das egal.

Warum zeigt meine Seite und amp; statt eines kaufmännischen und amperischen und amperischen und amperischen und amperischen

doppelt entkommen. Eine Schicht Ihres Stapels entkam einer bereits entkommenen Zeichenfolge und verwandelte sich in & amp; Der Browser dekodiert eine Ebene und zeigt das Überbleibsel an. Es bedeutet normalerweise, dass zwei Komponenten für beide denken, dass es ihr Job ist - ein CMS beim Speichern plus eine Vorlage beim Rendern ist das klassische Paar. Dekodieren Sie die Zeichenfolge jeweils in einem Decoder, die Anzahl der Durchgänge, bis sie sauber liest, gleich der Anzahl der aus ihr liegenden Schichten. Dann machen Sie genau eine Schicht zur Ausgabezeit.

Verhindert entkommenes HTML XSS?

In HTML-Körper- und Attributkontexten ja — Entitätscodierung nicht vertrauenswürdige Eingaben gibt es die Kernverteidigung, da die Nutzlast als inerter Text rendert. Aber es reicht nicht überall. Das OWASP XSS-Präventions-Cheatblatt zeigt explizit, dass JavaScript-Strings, URLs und CSS jeweils eine eigene kontextspezifische Codierung benötigen; Entitätscodierung innerhalb eines Skriptblocks bewirkt nichts. Escape am Ausgang in dem Kontext, in dem Sie ausgeben, indem Sie diesen Kontext verwenden. Die Entitätscodierung ist ein Werkzeug in diesem Kit, nicht das gesamte Kit.

Was ist der Unterschied zwischen htmlSpecialchars und HTMLentities in PHP?

htmlSpecialChars() entgeht nur den markup-signifikanten Zeichen – und Sie sollten ENT_Quotes übergeben, damit es das einzelne Zitat abdeckt. HtmlEntities() konvertiert jedes Zeichen, das eine benannte Entität hat, so werden Buchstaben mit Akzent zu Dingen wie der UUML-Referenz. Auf UTF-8-Seiten ist HtmlSpecialChars() fast immer das, was Sie wollen, htmlentities() Bläht die Ausgabe und verursacht Mojibake, wenn Zeichensätze falsch konfiguriert werden. WordPress-Entwickler vermeiden die Frage meist, indem sie esc_html() und esc_attr() verwenden, die die richtigen Flags pro Kontext anwenden.

Sollte ich die mit dem Apos benannte Entität für Apostrophe verwenden?

lieber & # 39 ;. Der APOS-Name ist in HTML5 gültig, war jedoch nie Teil von HTML4, daher erkennen ältere Parser - einschließlich der Rendering-Engines in einigen E-Mail-Clients - ihn nicht und werden ihn wörtlich angezeigt. Die numerische Form bedeutet den gleichen Charakter und funktioniert in allem, was jemals versendet wurde. Es ist eine hässliche, aber sichere Wahl, die normalerweise der richtige Kompromiss für die Flucht ist. Wenn Sie wissen, dass Ihre Ausgabe nur moderne Browser trifft, ist APOS in Ordnung; E-Mail-Vorlagen sind genau dort, wo Sie das nicht wissen.

Ist es sicher, Benutzerdaten in einen Online-Entity-Konverter einzufügen?

Nur wenn das Tool Text in Ihrem Browser verarbeitet. Benutzergenerierte Inhalte und E-Mail-Vorlagen enthalten regelmäßig Namen, E-Mails und andere PII sowie einen Konverter, der Ihre Eingaben auf einen Server postet, diese Daten ohne Vereinbarung erhalten. Der Toolz.dev HTML-Entitäten Encoder/Decoder läuft 100% clientseitig – kein Upload, kein Protokollieren und funktioniert offline, sobald die Seite geladen wurde. Wenn Sie nicht überprüfen können, wie ein Werkzeug Eingaben verarbeitet, fügen Sie keine Produktionsdaten ein.

Entkommen Sie einmal, am richtigen Ort

Wenn Sie eines aus einem Jahrzehnt meiner flüchtigen Fehler herausnehmen, nehmen Sie dies: Genau eine Schicht Ihres Stapels sollte entweichen, und es sollte die Ausgabeebene sein. Reinigen UTF-8 lagern. Entfliehen Sie den fünf Specials zum Renderzeitpunkt in dem Kontext, in dem Sie rendern. jeder & In der Produktion ist eine Karte zweier Komponenten, die über diesen Job kämpfen - und jeder nicht entkommene Benutzerzeichenfolge ist ein gespeicherter XSS, der auf eine Codeüberprüfung wartet, die möglicherweise nicht erfolgt. Meins hat es fast nicht getan.

Halten Sie das HTML-Entitäten-Encoder/-Decoder in Ihrer Debug-Rotation neben seinen Geschwistern - die URL-Encoder/Decoder für prozentuale Codierungskontexte (die URL-Codierungshandbuch durchquert %2520, der prozentuale Codierungs-Cousin von &), das Base64-Konverter für verpackte Nutzlasten und Gehäusekonverter Für die kennungsumrändernde Grunzarbeit zwischen ihnen. der Anleitung für die Coding-Tools Geht das ganze Set.

Und da die von Ihnen debuggten Zeichenfolgen so oft der tatsächliche Name oder die E-Mail sind: Alles oben läuft clientseitig, nichts hochgeladen, überprüfbar in Ihrem Netzwerk-Tab. Das ist kein Marketing - es ist der Grund, warum ich diese Tools so gebaut habe, wie ich es getan habe. Mehr zu dieser Philosophie in der Datenschutz-Leitfadendrohen