L'escape è facile da sbagliare perché più lavori diversi sembrano simili da lontano. Hai del testo, il testo contiene caratteri speciali e un altro sistema deve riceverlo senza fraintenderlo. L'errore è presumere che un solo tipo di escape funzioni ovunque.
URL encoding, escape HTML ed escape JSON risolvono problemi diversi. Uno spazio in una query string non è lo stesso problema di un carattere < dentro HTML renderizzato o di una virgoletta dentro una stringa JSON. Lo strumento Case, Slug ed Escape aiuta perché tiene vicini questi output, ma la parte utile è sapere quale output appartenga alla destinazione che stai preparando.
L'URL encoding serve per URL e valori query
Usa l'URL encoding quando il testo deve entrare in un componente URL, soprattutto in un parametro query o in un valore che può contenere spazi, punteggiatura o caratteri non sicuri per un path.
Supponi che un link di supporto debba includere un termine di ricerca come pricing & billing. Incollare quella frase direttamente in un URL può cambiare il modo in cui l'URL viene interpretato, perché & ha già un significato dentro una query string. L'URL encoding trasforma il testo in una forma che può viaggiare dentro l'URL senza essere confusa con la sintassi dell'URL.
È diverso dal creare uno slug. Uno slug di solito trasforma un titolo in un segmento di path leggibile, come pricing-and-billing. L'URL encoding conserva il valore originale in modo più diretto per il trasporto.
L'escape HTML serve per testo che verrà renderizzato in HTML
Usa l'escape HTML quando il testo deve apparire come testo dentro un contesto HTML, non diventare markup.
Se un esempio di codice include <button> e vuoi che i lettori vedano quei caratteri, il browser ha bisogno che siano escaped. Altrimenti potrebbe interpretarli come un vero elemento. L'escape HTML serve a impedire che il testo venga letto come sintassi HTML in punti in cui il contenuto dovrebbe restare testo visibile.
Questo conta in documentazione, campi CMS, changelog e copy di prodotto. È particolarmente rilevante quando il testo sorgente include esempi di markup, snippet o valori generati dagli utenti che non devono diventare parte della struttura della pagina.
L'escape JSON serve per valori stringa dentro JSON
Usa l'escape JSON quando il testo deve stare in sicurezza dentro una stringa JSON.
Una virgoletta è innocua nella prosa normale, ma dentro una stringa JSON può chiudere la stringa in anticipo. Anche una nuova riga può richiedere una rappresentazione che mantenga valido il JSON. L'escape JSON serve a preservare il valore mantenendo parsabile il JSON circostante.
Succede spesso quando i team condividono esempi API, snippet di configurazione, payload analytics o dati di esempio. Se il passaggio successivo è una pulizia più ampia dei dati strutturati, abbina questo articolo a Come formattare JSON prima di condividere un esempio API e al Convertitore JSON / YAML / TOML.
Scegli l'escape in base alla destinazione
La regola più semplice è partire dalla destinazione.
| Destinazione | Usa | Perché |
|---|---|---|
| Valore query o componente URL | URL encoding | Impedisce che il testo venga interpretato come sintassi URL |
| Testo visibile dentro HTML | Escape HTML | Impedisce ai caratteri speciali di diventare markup |
| Valore stringa dentro JSON | Escape JSON | Mantiene parsabili virgolette, slash e interruzioni di riga |
| Titolo pubblico di articolo o rotta | Generazione slug | Crea testo leggibile per path invece di preservare ogni carattere |
Converty aiuta perché puoi incollare una volta e confrontare gli output senza aprire un encoder separato per ogni caso. Il lavoro resta proporzionato. Non stai costruendo una pipeline; stai preparando un valore testuale per il posto in cui deve andare.
Apri Case, Slug ed Escape quando devi decidere se il prossimo output debba essere uno slug, un valore URL-encoded, testo HTML-safe o una stringa JSON-safe.
