Convertitore da JSON a XML

JSON vs XML

XML (Extensible Markup Language) è stato standardizzato dal W3C come Recommendation il 10 febbraio 1998, la specifica W3C XML 1.0, curata da Tim Bray, Jean Paoli e C.M. Sperberg-McQueen. XML è cresciuto da SGML (il più vecchio "Standard Generalised Markup Language", ISO 8879:1986) eliminando le funzionalità più complesse e producendo qualcosa che il web potesse usare realisticamente. Per circa il primo decennio del XXI secolo, XML era il formato presupposto per qualsiasi scambio di dati strutturati, web service SOAP, feed RSS (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), i formati Open XML di Microsoft Office (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), layout XML Android, file di proprietà Java, configurazione in quasi tutti i framework server. I punti di forza di XML sono i namespace, gli attributi, il contenuto misto (testo ed elementi figlio intercalati) e un ricco ecosistema di schemi (DTD, XML Schema 1.1, Relax NG). Il suo punto debole è la verbosità, ogni valore porta un tag di apertura e uno di chiusura.

JSON (JavaScript Object Notation) è stato specificato da Douglas Crockford nel 2001, il sito json.org e il suo saggio originale "JSON: The Fat-Free Alternative to XML". JSON è intenzionalmente un sottoinsieme della sintassi degli oggetti letterali JavaScript: oggetti, array, stringhe, numeri, true/false/null. Standardizzato come RFC 4627 nel luglio 2006, raffinato come RFC 7159 (marzo 2014) e RFC 8259 (dicembre 2017, attuale standard STD 90, pubblicato anche da ECMA come ECMA-404). Il sorpasso di JSON su XML nelle web API è avvenuto all'incirca tra il 2008 e il 2014, il timing combacia con l'ascesa delle single-page app e dell'era delle API mobile. Oggi quasi tutte le API pubbliche si documentano come JSON; XML sopravvive perlopiù nell'integrazione enterprise, nei formati di documento, nei file di configurazione e nei formati di feed. I due formati restano in uso attivo perché codificano bene cose diverse: JSON è giusto per dati strutturati con tipi semplici e forma prevedibile; XML è giusto per documenti con contenuto misto, attributi, namespace e schemi rigorosi.

Quando ti serve davvero convertire JSON in XML

• Chiamare un web service SOAP da un client solo JSON. SOAP è basato su XML per design (la busta SOAP, la descrizione del servizio WSDL, gli schemi XSD). Se hai dati in forma JSON e devi costruire un body di richiesta SOAP, JSON-a-XML è il ponte. Comune nell'integrazione enterprise quando microservizi moderni devono parlare con endpoint SOAP legacy (banche, governo, assicurazioni, sistemi di interscambio sanitario).
• Generare documenti Office Open XML da dati JSON. I formati .docx, .xlsx e .pptx sono archivi ZIP di file XML. Per generare o modificare programmaticamente documenti Office da dati JSON, la conversione JSON-a-XML avviene al confine tra il livello dati della tua applicazione e la libreria di generazione documenti.
• Produrre un feed RSS o Atom da contenuto JSON. Blog, siti di news e piattaforme podcast emettono feed RSS/Atom per la sindacazione. Se il tuo CMS conserva gli articoli come JSON, lo step di generazione feed converte le voci JSON nel formato XML che l'ecosistema dei feed reader si aspetta.
• Generare file di configurazione XML per applicazioni legacy. Molte applicazioni enterprise più vecchie (application server Java, file di configurazione .NET, Spring XML application context) consumano la loro configurazione come XML. Lo strumento moderno di infrastructure-as-code lavora tipicamente in YAML o JSON, quindi una conversione JSON-a-XML siede nella pipeline di deploy.
• Alimentare dati in una trasformazione XSLT. XSLT (XSL Transformations, la specifica di Michael Kay, W3C Recommendation) è il linguaggio standard di trasformazione XML e consuma input XML. Se i tuoi dati partono in JSON e il tuo motore di reporting è basato su XSLT, la conversione avviene al confine di input.
• Generare file di risorsa Android. strings.xml, colors.xml, dimens.xml e i file di layout di Android sono XML. Le pipeline di localizzazione che conservano le stringhe in JSON per facilità di modifica si convertono in XML al momento della build.

La mappatura della conversione, dove l'informazione sopravvive e dove si perde

JSON e XML hanno primitive strutturali diverse, quindi qualsiasi conversione deve fare scelte. La mappatura JSON-a-XML standard che la maggior parte dei convertitori (questo incluso) segue:

• Gli oggetti JSON diventano elementi XML. Ogni chiave diventa un elemento figlio con la chiave come nome del tag. {"name": "Alice"} diventa <name>Alice</name>.
• Gli array JSON diventano elementi figli ripetuti. {"items": [1, 2, 3]} diventa tre figli <item>1</item><item>2</item><item>3</item> dentro il wrapper <items>. (Diversi convertitori usano convenzioni diverse per il nome dell'elemento dell'array, alcuni usano il nome del genitore al singolare, altri usano un fisso <item>.)
• Stringhe, numeri, booleani diventano contenuto testuale dell'elemento. L'informazione sul tipo non viene preservata, XML tratta tutto il testo come dati di carattere, quindi un round-trip XML → parse → serializza di nuovo a JSON emetterebbe i numeri come stringhe tra apici a meno che il consumatore non applichi inferenza di tipo.
• null diventa un elemento vuoto auto-chiuso. {"middle_name": null} diventa <middle_name/>. Alcuni convertitori usano invece xsi:nil="true".
• L'elemento radice avvolge tutto. JSON permette un array o uno scalare al livello superiore; XML richiede esattamente un elemento radice. Il wrapper <root> (configurabile qui) è la soluzione convenzionale.

Informazione persa nella conversione: la distinzione di JSON tra numeri e stringhe, la distinzione di JSON tra true/false e le stringhe "true"/"false", la distinzione di JSON tra array e oggetto (quando un array diventa elementi ripetuti non puoi capire dall'XML solo se la sorgente avesse un array di un elemento o un singolo valore). Informazione potenzialmente guadagnata ma non usata da convertitori semplici: gli attributi XML (un oggetto JSON potrebbe mappare le chiavi in attributi invece che elementi figli), i namespace XML (JSON non ha equivalente), le sezioni CDATA (per incorporare testo con caratteri speciali XML). Per una conversione JSON-a-XML round-trip safe che preservi le informazioni di tipo, la convenzione BadgerFish o la convenzione Parker codificano i tipi JSON come attributi XML namespaced, questo strumento produce la forma più semplice e leggibile invece di quella round-trip safe.

Vincoli sui nomi di tag XML che le chiavi JSON non hanno

Le chiavi degli oggetti JSON sono stringhe arbitrarie, qualsiasi Unicode è ammesso. I nomi di elemento XML sono molto più ristretti: devono iniziare con una lettera o un underscore (non una cifra, un trattino o un punto), possono contenere lettere, cifre, trattini, underscore e punti (niente spazi, niente la maggior parte della punteggiatura), sono case-sensitive e non possono iniziare con il prefisso riservato xml in qualsiasi combinazione di caso. Chiavi JSON con spazi ("first name": "Alice"), chiavi che iniziano con cifre ("3rd_choice") o chiavi con caratteri speciali ("@type", "$value") non possono essere usate direttamente come nomi di elemento XML. La maggior parte dei convertitori (questo incluso) trasforma silenziosamente i caratteri non validi, sostituisce gli spazi con underscore, antepone un underscore alle chiavi che iniziano con cifre, elimina la maggior parte della punteggiatura. Sii consapevole di questo quando fai round-trip: un documento JSON con chiavi non XML-safe non farà round-trip in modo identico attraverso XML.

Dove XML regna ancora nel 2026

XML non è in ritirata nel 2026, si è solo stabilizzato in nicchie specifiche. Formati di documento: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), ebook EPUB, SVG (W3C Recommendation 4 settembre 2001), MathML, XHTML. Configurazione: application server Java, contesti Spring XML, POM Maven, risorse XML Android, file app.config e web.config di .NET. Feed: RSS 2.0, Atom 1.0 (RFC 4287), feed podcast (le estensioni RSS di iTunes). Interscambio sanitario e governativo: HL7 v3, FHIR (che ora offre JSON come alternativa ma la forma XML resta in uso pesante), DocBook, NewsML, ISO 20022 bancario. Enti di standardizzazione: quasi ogni esempio nelle specifiche IETF e W3C usa XML. La verbosità di XML è una caratteristica in quei domini: è autodescrittivo, validare contro uno schema è ben stabilito, e le trasformazioni XSLT tra dialetti XML sono un toolkit maturo. Il formato non sta andando da nessuna parte; la conversione JSON-a-XML è il ponte tra lo strumento dati moderno e questi sistemi consolidati XML-nativi.

Privacy: conversione solo nel browser

Il JSON incollato in un convertitore spesso contiene dati di produzione reali, risposte API con identificatori utente, ID di entità interni che rivelano la tassonomia di business, valori di configurazione che includono URL di endpoint e feature flag, token, contenuto di bozza non ancora pubblicato. I convertitori lato server prendono una copia di ogni input nei loro log. Questo convertitore analizza il tuo JSON con il JSON.parse() integrato del browser, attraversa l'albero di oggetti risultante in JavaScript ed emette XML come stringa, tutto dentro la tua scheda del browser. Verifica nel pannello Network di DevTools mentre clicchi Converti (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento e il convertitore continua a funzionare. Sicuro per risposte API di produzione, configurazione interna, contenuto di bozza o qualsiasi JSON che non vorresti vedere copiato sul disco rigido di uno sconosciuto.

Domande frequenti

Come vengono convertiti gli array JSON?

Gli array JSON sono convertiti in elementi XML ripetuti racchiusi in un tag <item>. Per esempio, [1, 2, 3] diventa tre elementi <item> all'interno del genitore.

Funziona con file JSON grandi?

Sì, poiché tutto avviene nel tuo browser, il soffitto pratico è la memoria disponibile del tuo dispositivo. Decine di migliaia di righe di JSON si convertono in molto meno di un secondo su un laptop moderno. Input molto grandi (multi-MB) possono congelare brevemente la scheda mentre il parser cammina nell'albero. Per la conversione in batch di grandi dataset, è più appropriato uno script che usa un convertitore lato server (xml2js in Node, dicttoxml in Python).

Il mio JSON viene caricato su un server?

No. La conversione avviene interamente nel tuo browser, il JSON incollato non lascia mai il tuo dispositivo. Verifica nel pannello Network di DevTools mentre clicchi Converti (nessuna richiesta parte) o metti la pagina offline (modalità aereo) dopo il caricamento. Sicuro per risposte API di produzione, configurazione interna o qualsiasi dato che non vorresti condividere esternamente.

Posso fare in modo che alcune chiavi JSON diventino attributi XML invece che elementi figli?

Questo convertitore emette tutte le chiavi JSON come elementi figli, non attributi. La convenzione che alcuni convertitori usano, chiavi con prefisso @ diventano attributi ("@id": 5 → id="5" sul genitore), è la convenzione BadgerFish. Se il tuo consumatore a valle richiede valori specifici come attributi, avrai bisogno di un convertitore personalizzato che capisca la convenzione o di modificare a mano l'XML risultante.

Cosa succede alle chiavi JSON che contengono spazi o caratteri XML non validi?

I nomi di elemento XML hanno regole più severe delle chiavi JSON: devono iniziare con una lettera o un underscore, non possono contenere spazi e non ammettono la maggior parte della punteggiatura. Le chiavi con caratteri non validi vengono ripulite, gli spazi diventano underscore, le cifre iniziali ricevono un prefisso underscore, i caratteri speciali vengono eliminati. Questo significa che un round-trip JSON → XML → JSON potrebbe non produrre i nomi di chiave originali esattamente. Se i tuoi dati hanno chiavi insolite, ispeziona l'output per assicurarti che la modifica non abbia rotto qualcosa di importante.

Strumenti correlati