Řetězce jako &, viditelné " nebo text café bývají opravovány dalším decode voláním. Taková změna může skrýt jeden symptom a poškodit další data. Encoding chyby obvykle ukazují, že se vrstvy neshodují, zda hodnota představuje obyčejný Unicode text, HTML source, sanitizovaný markup nebo již escapovaný prezentační výstup. Kvalita dat se obnoví až tehdy, když každý typ dostane jednoznačnou kanonickou podobu a každá konverze známého vlastníka.

Obyčejný text má zůstat obyčejným textem

Jméno, popis nebo zpráva se v databázi obvykle ukládají jako Unicode text. Hodnota „A & B“ zůstane přesně taková. HTML template při výstupu escapuje ampersand, JSON serializer použije JSON pravidla a plain-text e-mail zobrazí znak přímo.

Uložení A & B sváže data s jedním prezentačním formátem. Editace, export, full-text search i další klient pak musí hádat, zda hodnotu dekódovat. Kanonická sémantická podoba tuto nejistotu odstraňuje.

Sanitizované HTML je samostatný datový typ

Pokud produkt ukládá rich text, pole má být pojmenováno a dokumentováno jako HTML. Na určené hranici projde sanitizerem a raw se renderuje pouze v komponentě očekávající tento trusted typ. Nemá se míchat s plain-text sloupci ani automaticky dekódovat při každém čtení.

Schema, wrapper class nebo type system může rozdíl zviditelnit. Vývojář pak nemusí podle výskytu tagu odhadovat, zda je string bezpečný. Samotná přítomnost angle brackets typ spolehlivě neurčuje.

Decode je správný pouze pro deklarovaný encoded vstup

Externí feed může výslovně poskytovat HTML character references. V takovém případě je jednorázové dekódování součástí importní smlouvy. Aplikovat stejnou operaci na libovolný uživatelský text může změnit záměrně napsanou sekvenci a vytvořit markup-significant znaky.

Repeated decode je obzvlášť nebezpečný. Nested hodnota se po několika průchodech může stát tagem nebo skriptem. Boundary musí znát vstupní formát, provést přesně jednu transformaci a výsledek dál označit jako plain text či HTML podle skutečného významu.

Double encoding znamená duplicitní odpovědnost

Když backend escapuje text pro HTML a auto-escaping template udělá totéž znovu, syntax entity se objeví uživateli. Oprava obvykle není decode v browseru. Je potřeba odstranit předčasnou prezentační transformaci a ponechat odpovědnost poslednímu rendereru.

Raw helper může viditelný artefakt odstranit, ale současně otevřít XSS. Nejprve se musí určit datový typ a původ hodnoty, teprve potom zvolit správné vykreslení.

Byte encoding a HTML entities jsou jiné vrstvy

HTML reference reprezentuje znak uvnitř markup syntaxe. UTF-8 určuje, jak se Unicode znaky zapisují do bajtů. Mojibake typu café obvykle vzniká, když UTF-8 bajty někdo dekóduje jako jinou charset. Entity decoder tuto chybu spolehlivě neopraví.

Databáze, connection, soubory, HTTP Content-Type a serializer mají používat konzistentní UTF-8. Diagnostika má zkontrolovat skutečné bajty a deklaraci charset dříve, než začne provádět nahodilé replacements nad již poškozeným textem.

Legacy migrace potřebuje klasifikaci, ne opakovaný decode

Starý sloupec může obsahovat směs plain textu, jednou encoded hodnot, double encodingu a uživatelem doslova napsaných entity-like sekvencí. Jediný globální převod část záznamů opraví a část zničí. Migrace má nejprve změřit vzory, vybrat reprezentativní vzorky a vytvořit vratný plán.

Transformace může používat zdroj záznamu, datum, historickou verzi editoru a další metadata. Nejasné případy se označí k ruční kontrole. Po cleanupu se jednotný write boundary vynutí validací a round-trip testem.

Nečistá reprezentace poškozuje vyhledávání

Plain a encoded varianta stejného viditelného textu nejsou v databázi shodné. Search index, deduplikace, řazení a analytics je považují za jiné hodnoty. Uživatel pak nenajde záznam podle textu, který na stránce skutečně vidí, nebo vzniknou zdánlivé duplicity.

Indexovat se má kanonický sémantický text. Escaping proběhne až po načtení a výsledek se nesmí zapsat zpět jako změna obsahu. Rich HTML může potřebovat zvlášť odvozenou plain-text podobu pro hledání.

API musí deklarovat text versus markup

Klient nedokáže bezpečně poznat typ podle tagů. Plain text může legitimně obsahovat <b> a malformed HTML nemusí vypadat zjevně. Schema má uvést, která pole jsou text, která sanitizované HTML, jaký allowlist platí a jak je smí klient vykreslit.

Když API potřebuje nabídnout reusable hodnotu i server-rendered prezentaci, má použít dvě oddělená pole. Přetížení jednoho stringu nutí každý klient implementovat vlastní křehkou detekci.

Round-trip test odhalí místo ztráty významu

Reprezentativní hodnoty projdou formulářem, uložením, API serializací, opětovnou editací a finálním renderem. Test zahrne ampersand, uvozovky, český i ne-latinský text, doslovnou entity sekvenci a povolený rich markup. Výsledek se hodnotí podle toho, co uživatel vidí a co zůstane po druhém uložení.

Taková sada chrání framework upgrade, import i migraci databáze. Popisuje smlouvu pozorovatelným chováním místo seznamu implementačních escape volání.

Každá reprezentace potřebuje vlastníka

Spolehlivý systém rozlišuje plain Unicode text, sanitizované HTML, URL a serializovaná data. Každý typ má známého producenta, storage representation, validační pravidlo a output encoder. Vývojář nemá string prohlížet a hádat, zda už byl někdy escapován.

Výjimky, například importovaný archivní obsah, mají být označené zdrojem a verzí transformačního pravidla. Když se později najde chyba sanitizeru nebo charsetu, lze dohledat dotčené záznamy a opravit je cíleně místo další globální konverze.

Encoding a decoding jsou boundary operace, nikoli obecné nástroje na úklid. Jasná smlouva odstraní většinu viditelných entity artefaktů, zlepší search a zároveň chrání důležitější hranici mezi zobrazovanými daty a spustitelným markupem.