Escape / Unescape JSON
Esegui l'escape dei caratteri speciali di una stringa per un'integrazione JSON sicura, o esegui l'unescape di una stringa JSON in testo semplice.
Come funziona
- Incolla la tua stringa: inserisci il testo di cui fare l'escape, può essere testo semplice contenente virgolette, ritorni a capo, barre rovesciate o qualsiasi altro carattere speciale.
- Scegli escape o unescape: seleziona se vuoi fare l'escape di testo per integrarlo in JSON, o l'unescape di una stringa JSON in testo leggibile.
- Copia il risultato: l'output con escape o unescape appare all'istante. Copialo per usarlo nel tuo codice o nei tuoi dati.
Perché usare l'escape JSON?
Le stringhe JSON hanno regole di escape rigorose, le virgolette doppie devono diventare \", i ritorni a capo \n, le barre rovesciate \\ e le tabulazioni \t. Non eseguire correttamente l'escape di questi caratteri provoca errori di parsing JSON che rompono API, file di configurazione e pipeline di dati. Questo strumento gestisce automaticamente tutto l'escape e l'unescape, eliminando il cerca-sostituisci manuale ed evitando bug sottili dovuti a sequenze di escape mancate.
Funzionalità
- Copertura completa di escape: gestisce virgolette, barre rovesciate, ritorni a capo, tabulazioni, ritorni a capo carrello e sequenze di escape Unicode.
- Bidirezionale: sia escape (testo → stringa JSON) sia unescape (stringa JSON → testo) in un unico strumento.
- Risultati istantanei: l'output si aggiorna mentre digiti, senza ritardo.
- Copia negli appunti: copia con un clic del risultato con escape o unescape.
- Privacy prima di tutto: tutta l'elaborazione avviene localmente, le stringhe sensibili non lasciano mai il tuo dispositivo.
Domande frequenti
Quali caratteri gestisce l'escape JSON?
JSON richiede l'escape di: virgolette doppie ("), barra rovesciata (\), barra (/), ritorno a capo (\n), ritorno carrello (\r), tabulazione (\t), salto pagina (\f), backspace (\b) e caratteri Unicode al di sopra di U+FFFF. Questo strumento li gestisce tutti.
Perché il mio errore di parsing JSON è dovuto all'escape?
Le cause comuni includono virgolette doppie senza escape all'interno di un valore di stringa, ritorni a capo letterali in una stringa (devono essere \n) e barre rovesciate senza escape. Incolla qui la tua stringa rotta per fare l'escape correttamente.
Sono incluse le virgolette di delimitazione?
Per impostazione predefinita, lo strumento esegue l'escape del contenuto senza racchiudere virgolette, in modo che tu possa incollare il risultato nella tua stringa JSON. Attiva l'opzione «Includi le virgolette» se vuoi che l'output sia racchiuso tra virgolette doppie.
La specifica JSON String, in una tabella
RFC 8259 (dicembre 2017, di Tim Bray) è lo standard JSON attuale, sostituendo RFC 7159 e l'originale RFC 4627. La sezione 7 della spec elenca esattamente quali caratteri DEVONO essere escaped all'interno di un letterale stringa:
| Carattere | Escape | Code point | Significato |
|---|---|---|---|
" | \" | U+0022 | virgolette (termina la stringa) |
\ | \\ | U+005C | backslash (inizia un escape) |
\b | \b | U+0008 | backspace |
\f | \f | U+000C | form feed |
\n | \n | U+000A | line feed (LF) |
\r | \r | U+000D | carriage return (CR) |
\t | \t | U+0009 | tab |
/ | \/ | U+002F | slash (opzionale, ma utile per l'embedding HTML) |
| control | \uXXXX | U+0000-U+001F | qualsiasi carattere di controllo C0 non coperto sopra |
Regole equivalenti sono in ECMA-404 (2a edizione, dicembre 2017), mantenuto in sincronia con la spec IETF. JSON non ha escape ottali (\012) o esadecimali (\x41), quelli sono solo JavaScript; JSON supporta solo gli otto escape nominati sopra più \uXXXX.
L'escape \uXXXX e la trappola della coppia surrogata
Le sequenze \uXXXX di JSON codificano unità di codice UTF-16, non code point Unicode. Questo è importante per emoji e caratteri del piano supplementare. Un singolo emoji come 😀 (U+1F600) non si fa l'escape come \u1F600 (non è nemmeno una forma legale a quattro cifre esadecimali), ma come coppia surrogata: \uD83D\uDE00, due escape consecutivi che codificano i surrogati alto e basso. L'intervallo del surrogato alto è U+D800–U+DBFF; il basso è U+DC00–U+DFFF; insieme coprono U+10000 fino a U+10FFFF (i piani supplementari).
Questa è la fonte più comune di bug di escape di emoji. La sezione 7 di RFC 8259 dice esplicitamente: «Per fare l'escape di un carattere esteso che non è nel piano multilingue di base, il carattere è rappresentato come una sequenza di 12 caratteri, codificando la coppia surrogata UTF-16.» Un emoji famiglia di quattro come 👨👩👧👦, che tecnicamente è quattro emoji base più tre giunzioni a larghezza zero, viene fatto l'escape come 30+ caratteri in una stringa JSON. Il conteggio dei byte si gonfia proporzionalmente: 25 byte UTF-8 grezzi, ~58 byte dopo l'escape JSON.
JSON dentro HTML, URL, SQL e CSV
L'escape JSON da solo non è sufficiente quando il JSON è incorporato in un altro formato. Ogni contesto aggiunge il proprio livello.
JSON dentro HTML. La trappola classica è <script>const data = {{ payload | json }};</script> quando il payload contiene la sottostringa letterale </script>. Il parser HTML chiude il tag script a metà stringa e il resto del JSON viene reso come testo visibile sulla pagina. La correzione è l'escape opzionale \/: <\/script> è JSON-valido e HTML-sicuro. Il cheat sheet di cross-site scripting di OWASP raccomanda di fare sempre l'escape di <, >, & e ' in JSON destinato all'embedding HTML.
JSON dentro una stringa di query URL. Due livelli: prima escape JSON, poi percent-encoding. {"name":"Bob"} diventa %7B%22name%22%3A%22Bob%22%7D. Dimenticare il percent-encoding è la causa n. 1 dei bug JSON-in-URL malformati.
JSON dentro SQL. Memorizzato in una colonna PostgreSQL jsonb il valore viene analizzato nativamente, nessun ulteriore escape necessario. Ma JSON incorporato in un letterale stringa SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) necessita di escape di stringa SQL sopra JSON: virgolette singole raddoppiate (''), o meglio, usa query parametrizzate.
JSON dentro celle CSV. Il quoting di CSV differisce da quello di JSON (CSV usa virgolette raddoppiate "", non sequenze con backslash). Incorporare JSON in una cella CSV necessita di entrambi i livelli: escape JSON della stringa, poi escape CSV del risultato (avvolgere in "...", raddoppiare qualsiasi " interno).
API di runtime tra linguaggi
| Linguaggio | Codifica | Decodifica | Note |
|---|---|---|---|
| JavaScript | JSON.stringify | JSON.parse | Nativo da IE 8 (2009). Disponibile in ogni browser e Node. |
| Python | json.dumps | json.loads | ensure_ascii=False rinuncia all'escape \uXXXX per non-ASCII. |
| PHP | json_encode | json_decode | Nativo da PHP 5.2 (nov 2006). Flag JSON_UNESCAPED_UNICODE dal 5.4. |
| Java | ObjectMapper.writeValueAsString | readTree | Jackson è lo standard de facto da ~2009. |
| Go | json.Marshal | json.Unmarshal | Libreria standard encoding/json. |
| Rust | serde_json::to_string | serde_json::from_str | Il crate serde_json, onnipresente. |
Da dove viene JSON, e cosa ha lasciato fuori Crockford
JSON è stato formalizzato per la prima volta da Douglas Crockford nel 2001 presso State Software, originariamente per serializzare oggetti JavaScript per scambio dati asincrono. La prima menzione pubblica è stata sul sito JSON.org nel 2003. Crockford lo ha specificato formalmente come RFC 4627 nel luglio 2006, in parte per combattere un tentativo di brevetto concorrente nello stesso periodo. Lo standard è passato allo status STD 90 con RFC 8259 nel dicembre 2017.
La decisione di design più grande di JSON è stata renderlo un sottoinsieme di JavaScript, in modo che qualsiasi documento JSON potesse essere eval'd in un interprete JS e produrre il valore corretto. Questo ha reso l'adozione nel browser senza attriti ma ha bloccato permanentemente alcune peculiarità di JS: nessun tipo intero (tutti i numeri sono double IEEE 754), nessun tipo data, nessun NaN o Infinity. Gli interi grandi sopra 2⁵³−1 necessitano di serializzazione come stringa ("id": "9007199254740993") per evitare perdita silenziosa di precisione.
Crockford ha deliberatamente lasciato fuori cose che potresti perdere: commenti («Ho rimosso i commenti da JSON perché ho visto persone che li usavano per contenere direttive di parsing, una pratica che avrebbe distrutto l'interoperabilità», maggio 2012), virgole finali, e linguaggio di schema (aggiunto dopo come JSON Schema, mantenuto separatamente, bozza attuale 2020-12). La variante comunitaria JSON5 ripristina commenti e virgole finali ma non è RFC-conforme; è usata principalmente in file di configurazione (.babelrc, .swcrc) che gli umani editano.
Casi d'uso comuni
- Incorporare dati in attributi HTML, incollare una stringa con
",<,>, ottenere una forma sicura per attributidata-*o tagscriptinline. - Comporre corpi di richiesta API a mano, quando si fa curl di un endpoint e il payload contiene virgolette o newline.
- Costruire payload di righe log dove il messaggio deve sopravvivere al quoting shell più il parsing JSON dall'altra parte.
- Migrare dati legacy da CSV / XML / TSV a JSON, passaggio manuale di escape delle virgolette.
- Eseguire il debug di risposte server dove il valore contiene sequenze
\u, fare unescape per vedere cos'è davvero. - Scrivere test, incollare l'output JSON atteso e farne l'escape per includerlo in un'asserzione di test.
- Motori di templating (Jinja2, Nunjucks, Liquid, ERB) che incorporano JSON in JavaScript o HTML.
Errori comuni
- Usare escape JavaScript che non sono JSON-validi.
\x41per «A» e\012per newline sono validi nei letterali stringa JS ma non validi in JSON. JSON consente solo gli otto escape nominati più\uXXXX. - Usare virgolette singole per stringhe JSON.
'hello'funziona in JavaScript ma è JSON non valido. Le stringhe JSON DEVONO usare virgolette doppie. - Chiavi oggetto senza virgolette.
{name: "Bob"}funziona in JavaScript ma è JSON non valido. Le chiavi DEVONO essere letterali stringa in virgolette doppie. - Virgole finali.
[1,2,3,]funziona in JS ma è JSON non valido. RFC 8259 le proibisce esplicitamente. - Commenti inline.
// fooe/* foo */non sono validi in JSON standard. Usa JSON5 se hai bisogno di commenti; aspettati che non tutti i parser lo accettino. - Fare manualmente l'escape di un emoji come singolo
\uXXXX. Emoji sopra U+FFFF necessitano di una coppia surrogata UTF-16, due\uXXXXconsecutivi.
Altre domande frequenti
Devo sempre fare l'escape dello slash /?
No, lo slash / è permesso senza escape in JSON; l'escape \/ è opzionale. L'eccezione è quando JSON è incorporato dentro un tag HTML <script>: fare l'escape di / come \/ impedisce che la sottostringa letterale </script> chiuda il tag prematuramente. Alcuni encoder (JSON_HEX_TAG in PHP, sostituzioni JS personalizzate) lo fanno; la maggior parte no.
Perché JSON.stringify fa l'escape dei miei caratteri non-ASCII?
Non lo fa, di default. JSON.stringify("café") in JavaScript produce "café" con il letterale é. Quello che potresti vedere è una libreria diversa: json.dumps di Python ha di default ensure_ascii=True e fa l'escape di tutto fuori da ASCII come \uXXXX; json_encode di PHP si comporta similarmente a meno che non passi JSON_UNESCAPED_UNICODE. Entrambi i comportamenti sono JSON valido, ma la dimensione del file e la leggibilità differiscono.
JSON può memorizzare dati binari?
Non direttamente. Le stringhe JSON sono sequenze di caratteri Unicode, non byte. Il workaround standard è prima codificare in Base64 il binario, poi memorizzare la stringa ASCII risultante come valore JSON normale. I dati codificati sono ~33% più grandi dei byte grezzi. Per binari molto grandi, usa un formato binario come BSON, MessagePack o CBOR, o memorizza i byte separatamente e referenziali per URL.
Perché alcuni strumenti mostrano \u00e9 invece di é?
Entrambi sono JSON validi per lo stesso carattere. "caf\u00e9" e "café" decodificano in stringhe identiche. Alcuni encoder fanno l'escape di non-ASCII per la massima sicurezza cross-encoding (l'output è ASCII puro quindi la codifica del consumatore non importa), altri preservano l'UTF-8 originale per la leggibilità. Scegli in base a cosa consuma il tuo JSON.
Il mio testo viene caricato da qualche parte?
No. Lo strumento usa le API native JSON.stringify e JSON.parse del browser interamente lato client. Non ci sono chiamate di rete, analytics, logging. Sicuro per fare l'escape di token API, dati interni, o qualsiasi cosa tu non incollassi in uno strumento di escape lato server.