Escape HTML Gratuito: Codificare e Decodificare Entità HTML Online

A L'escape HTML converte caratteri speciali come <, >, & e " nelle loro entità HTML (&lt;, &gt;, &amp;, &quot;). Così il browser li mostra come testo invece di interpretarli come codice.

A Previene attacchi XSS (Cross-Site Scripting). Se mostri testo degli utenti senza escape, un attaccante potrebbe iniettare codice JavaScript malevolo.

A Sono codici che rappresentano caratteri speciali: &lt; per <, &amp; per &, &copy; per ©. Possono avere formato nome (&amp;) o numerico (&#38;).

A Da solo no. L'escape gestisce il contesto di output, ma gli XSS avvengono anche tramite esecuzione JavaScript, iniezione CSS o attacchi basati su attributi. Servono intestazioni Content Security Policy e validazione dell'input. Considera l'escape come un livello, non una soluzione universale. Abbinalo a una CSP che blocchi gli script inline.

A Il nostro strumento non supporta l'escape selettivo, e c'è un buon motivo. Un escape parziale lascia falle sfruttabili. Supponi di escludere < e > ma non &. Un utente che inserisce &lt;script&gt; potrebbe generare un tag reale se il tuo database lo codifica due volte. Fai un unico giro di escape completo e poi fidati dell'output. Eviterai casi limite fastidiosi.

A Lo strumento lo escapherà di nuovo, trasformando `&amp;` in `&amp;amp;`. Di solito non è quello che vuoi. Controlla sempre che l'input siano caratteri HTML grezzi, non entità. In caso di dubbio, incolla un piccolo campione e dai un'occhiata all'output. Questo errore è comune quando si copia testo da un CMS che lo ha già escapato una volta.

A Stai passando caratteri <code><</code> e <code>></code> grezzi tramite JavaScript. Con <code>innerHTML</code>, il browser li interpreta come markup, non come testo. Escapa prima la stringa — questo converte <code><</code> in <code>&lt;</code> e <code>></code> in <code>&gt;</code>. Poi assegna la versione escapata a <code>innerHTML</code>. Il browser mostrerà i tag come caratteri letterali. Salta questo passaggio e ti ritroverai con layout rotti o una falla XSS.

A Sì, assolutamente. Molti pensano che le textarea siano zone sicure perché mostrano il testo diversamente. Il browser analizza comunque l'HTML al loro interno. Inserisci < e > grezzi, e rompi la pagina o apri un vettore XSS. Escapa sempre il contenuto utente prima di iniettarlo. Il nostro strumento converte < in &lt; e > in &gt; in secondi, anche su migliaia di righe.

A Salva i dati grezzi ed esegui l'escape al momento del rendering. È la regola che ti salva dagli incubi del doppio encoding. Se scappi prima di salvare, poi dovrai decodificare per modificare e ri-codificare per visualizzare: tre punti dove i bug si infilano. Tieni il database pulito e passa tutto da questo strumento subito prima dell'invio al browser. Eviterai il disastro in cui &amp; diventa &amp;amp; e gli utenti vedono testo rotto. Un'eccezione: se stai costruendo un sito statico, l'escape al momento della build funziona benissimo.

A Risolvono problemi totalmente diversi. L'escaping HTML converte caratteri come < e > in entità (&lt;, &gt;) così il browser li mostra come testo, non come markup. La codifica URL trasforma i caratteri in valori percentuali (%3C, %3E) per il trasporto sicuro in query string e percorsi. Confonderli crea bug subdoli. Se costruisci un link con input utente, codifica l'URL. Se mostri quello stesso input su una pagina, fai l'escaping HTML. Due passaggi separati, due strumenti separati—questo gestisce solo HTML. Test rapido: se la tua URL mostra %26 al posto di &, quella è codifica, non escaping. Usa quello giusto a ogni livello ed eviterai ore di debug su doppie codifiche.