Codificare le entità HTML

Sono `<`, `>`, `&` e le due specie di virgolette. Il minore apre un tag, il maggiore lo chiude, la e commerciale apre un riferimento di carattere, e le virgolette chiudono il valore di un attributo. Tutto il resto del repertorio non cambia in nessun modo come un documento viene analizzato.

La brevità della lista è la ragione per cui la protezione minima è quella giusta quasi sempre: proteggere solo cinque caratteri lascia il testo leggibile nel sorgente, che è utile a chiunque lo debba guardare in seguito. Proteggere tutto produce un documento corretto e illeggibile, e la leggibilità del sorgente non è un vezzo quando qualcuno dovrà rileggerlo per capire un difetto.

L’ordine delle sostituzioni non è indifferente. Se sostituisci il minore prima della e commerciale, la `&` che hai appena introdotto in `&lt;` viene protetta a sua volta e diventa `&amp;lt;`: nel documento finale compare la scritta `&lt;` invece del carattere.

È l’errore classico di ogni funzione di protezione scritta a mano, e si riconosce dalla forma del risultato — un `&amp;` seguito da un nome di entità. Qui le sostituzioni avvengono in un passaggio solo, il che rende l’ordine irrilevante per costruzione, che è il modo giusto di non doversene ricordare.

Dentro il testo di un elemento bastano `<` e `&`. Dentro il valore di un attributo servono anche le virgolette, perché quelle chiudono il valore in anticipo e tutto ciò che segue diventa un altro attributo — che è esattamente il modo in cui si inserisce un `onerror` in un tag che non doveva averne.

Peggio ancora è un attributo senza virgolette, dove basta uno spazio a terminare il valore. Questa pagina protegge entrambe le specie di virgolette proprio perché il testo che esce da qui può finire in tutti e due i posti, e la protezione più prudente è l’unica che regga senza sapere dove andrà.

In un documento HTML dichiarato come UTF-8 — cioè in tutto ciò che si scrive oggi — le lettere accentate non hanno nessun bisogno di essere protette. `città` funziona così com’è, e trasformarlo in `citt&agrave;` non aggiunge niente se non rumore.

La seconda modalità esiste per un caso preciso: una catena di elaborazione che non tratta bene l’UTF-8. Un vecchio sistema di posta, un generatore di PDF, un endpoint che dichiara Latin-1, un campo di database con una codifica ereditata. Lì scrivere tutto in ASCII puro con entità numeriche è l’unico modo per far arrivare una `à` intatta dall’altra parte.

La protezione va fatta quando il dato esce, cioè nel momento in cui viene inserito in un documento, e non quando entra. Un dato ripulito all’ingresso è un dato modificato per sempre, e va bene finché non serve mostrarlo in un contesto diverso — un file CSV, una email di testo semplice, una risposta JSON — dove quelle entità diventano rumore visibile.

La differenza pratica è che il valore giusto da conservare è quello che la persona ha scritto. Un utente che si chiama `D&Agrave;` in un database ha subito un difetto, non una protezione, ed è il tipo di guasto che si scopre anni dopo quando qualcuno esporta i dati verso un altro sistema.

Un riferimento di carattere può avere un nome — `&amp;` —, una forma decimale — `&#38;` — o una esadecimale — `&#x26;`. Sono equivalenti per qualunque parser HTML, e la scelta è di leggibilità: i nomi si leggono, i numeri funzionano anche dove il nome non esiste.

I nomi però non sono universali fuori dall’HTML. In XML ne esistono cinque soltanto, quindi un `&nbsp;` scritto dentro un documento XML o dentro un feed RSS rigoroso è un errore di sintassi e non uno spazio: lì serve la forma numerica, `&#160;`. È una delle differenze che spiegano perché un frammento copiato da una pagina web rompa un feed.

Per l’apostrofo dritto questa pagina produce il riferimento numerico `&#39;` invece del nome `&apos;`. Il motivo è compatibilità: `&apos;` è definito in XHTML e in XML, e non faceva parte dell’HTML 4. I browser moderni lo capiscono tutti, ma il testo che esce da qui può finire in un feed, in un template o in un parser che non è un browser.

La forma numerica non ha quel problema in nessun contesto, perché il numero è il punto di codice e non un nome da cercare in una tabella. È la stessa logica per cui un codificatore prudente preferisce `&#39;` ovunque: costa quattro caratteri in più e toglie una categoria intera di sorprese.

La protezione delle entità vale nel contesto HTML e non altrove. Un valore inserito dentro un blocco `<script>`, dentro un attributo `href` che comincia per `javascript:` o dentro un pezzo di CSS obbedisce ad altre regole di analisi, e le entità lì non fanno niente di utile.

Ogni contesto ha la sua protezione, e questa pagina ne fa una sola. Se stai costruendo un documento a mano invece di usare un motore di template, quella è la decisione da rivedere per prima: i template moderni proteggono in automatico e sanno in che contesto stanno scrivendo, mentre una concatenazione di stringhe non lo sa e non lo può sapere.

Quello che si porta a un codificatore di entità è quasi sempre testo scritto da qualcun altro: un commento, una recensione, la descrizione di un prodotto, un messaggio di assistenza. Sono contenuti di persone, e su un servizio remoto sarebbero una comunicazione di dati a un terzo senza alcuna necessità.

Qui la sostituzione avviene nella scheda, quindi il testo non ci arriva e non compare in nessun log. Nel senso del GDPR non c’è niente da giustificare per il contenuto del campo: quello che resta è la visita alla pagina, che è scritta nell’informativa e riguarda te e non le persone di cui stai maneggiando le parole.