Convertitore JSON XML

JSON e XML come alberi intercambiabili

JSON e XML rappresentano entrambi dati gerarchici, ma nascono da tradizioni diverse. JSON è un modello leggero oggetto/array usato dalla maggior parte delle API web. XML è un modello di documento etichettato con elementi, attributi, namespace e contenuto misto, ancora centrale per messaggistica enterprise, publishing e molti formati di configurazione.

Convertire tra i due è un mapping strutturale, non un semplice restyling della sintassi. Nomi, annidamento e indizi di tipo vanno scelti con cura perché i due modelli non sono isomorfi. Questo hub spiega quella famiglia di mapping. Per un percorso di conversione diretto, apri Da JSON a XML.

Subtool di questa famiglia

• Da JSON a XML — prende un valore JSON ed emette un documento XML che riflette oggetti come elementi e array come figli ripetuti (secondo le regole del convertitore).
• Da XML a JSON — analizza XML e produce una rappresentazione JSON di elementi, testo e attributi.
• Formatta JSON — pretty-print o minifica JSON quando serve controllo del layout nello stesso flusso della conversione.

Usa i convertitori quando i sistemi ai due lati di un’integrazione non concordano sulla codifica. Usa format-json quando il payload è già JSON e ti serve solo forma leggibile o compatta prima o dopo una trasformazione.

Dove i modelli divergono

Oggetti vs elementi. Gli oggetti JSON sono mappe non ordinate da chiavi stringa a valori. Gli elementi XML sono ordinati nell’ordine del documento e possono ripetersi con lo stesso nome. Un array JSON di oggetti diventa spesso elementi fratelli ripetuti; un oggetto JSON diventa un insieme di elementi figlio con nomi univoci — finché una chiave non è illegale come nome XML.

Attributi vs proprietà. Gli attributi XML sono solo stringhe, non ordinati sull’elemento e non annidabili. JSON non ha un canale attributi separato; i convertitori tipicamente mappano gli attributi su chiavi con un prefisso convenzionale (ad esempio @id) o li annidano sotto un oggetto riservato. I round-trip devono concordare quella convenzione, altrimenti attributi ed elementi figlio scambiano significato.

Tipi. JSON distingue numeri, booleani, null, stringhe, array e oggetti. Il testo XML resta testo finché uno schema (XSD) o una convenzione non lo reinterpretano. Senza metadati di tipo, true, 1 e "true" possono sopravvivere come stringhe — oppure un convertitore può applicare euristiche sorprendenti.

Namespace. I namespace XML (xmlns) disambiguano i vocabolari. JSON non ha un nodo namespace nativo; i prefissi possono essere appiattiti nelle chiavi o scartati. Perdere informazioni di namespace è un fallimento silenzioso comune quando XML→JSON→XML è usato come pipeline di «pulizia».

Contenuto misto. XML consente testo ed elementi intervallati (<p>Ciao <em>mondo</em></p>). Gli alberi JSON di solito memorizzano o una stringa o i figli, non entrambi, a meno che il convertitore non usi un array di contenuto esplicito. L’XML document-centric spesso richiede un mapping più ricco di quello data-centric.

JSON → XML (pipeline concettuale)

1. Analizzare il JSON; rifiutare sintassi non valida prima di costruire XML.
2. Scegliere un nome di elemento radice (JSON non richiede una radice unica per un array di primo livello; i convertitori inventano un wrapper).
3. Mappare ogni chiave oggetto su un elemento figlio o attributo secondo le regole di naming.
4. Mappare gli array su elementi ripetuti con lo stesso tag.
5. Fare escape dei caratteri speciali (&, <, >, virgolette) in testo e attributi.
6. Serializzare con o senza dichiarazione XML e indentazione.

I nomi XML illegali (chiavi che iniziano con cifre, contengono spazi o collidono con prefissi riservati xml) devono essere sanificati o rifiutati. Preferisci fallire in modo evidente nelle pipeline dati piuttosto che emettere markup non ben formato.

XML → JSON (pipeline concettuale)

1. Analizzare come XML ben formato (e opzionalmente validare contro uno schema altrove).
2. Rappresentare ogni elemento come oggetto JSON o come valore quando ha solo testo.
3. Decidere come codificare attributi, figli ripetuti ed elementi vuoti ("" vs null vs {}).
4. Collassare o preservare i nodi testo secondo la policy sul contenuto misto.
5. Emmettere testo JSON; opzionalmente pretty-print per ispezione via Formatta JSON.

Elementi fratelli con lo stesso nome diventano di solito un array JSON. Un solo figlio con quel nome può diventare un oggetto nudo — altro rischio di round-trip se il codice assume sempre array.

Formattare JSON in un flusso di conversione

Gli errori di conversione si diagnosticano meglio su JSON indentato. Il JSON minificato è meglio per incorporarlo in log o trasporto dopo aver finito di editare. Format-json in questa famiglia è il fratello di layout: non sposta dati in XML; prepara JSON per consumo umano o macchina intorno ai convertitori.

Assenza di perdita e quando smettere i round-trip

I round-trip sono lossy di default a meno che entrambe le direzioni non condividano un set di convenzioni documentato (prefissi attributo, wrapping array, coercizione tipi, gestione namespace). Pattern sicuri:

• Convertire una volta al confine di sistema e mantenere un unico sistema di record.
• Conservare l’XML originale quando conta la fedeltà legale/archivistica; trattare JSON come proiezione di lavoro.
• Preferire tooling schema-aware (XSD + data binding) per messaggi enterprise rispetto a passeggiate ad hoc sull’albero.

Pattern non sicuri: usare JSON come editor XML (XML→JSON, modifica a mano, JSON→XML) per documenti firmati, namespace o contenuto misto senza golden test.

Caratteri, encoding e dimensione

I documenti XML spesso dichiarano l’encoding nel prologo; il testo JSON nelle API è quasi sempre UTF-8. In conversione, assicurati che la stringa Unicode in memoria sia corretta prima della serializzazione. I caratteri di controllo illegali in XML 1.0 vanno rimossi o escapati secondo policy — possono comparire in stringhe JSON e rompere writer XML ingenui.

Documenti molto grandi stressano la memoria del browser. Per export multi-megabyte preferisci convertitori streaming nell’ecosistema standard del tuo linguaggio; gli strumenti browser sono ideali per campioni, fixture e fette di debug.

Esempi pratici di integrazione

• Servizio SOAP/XML legacy, client JSON moderno: mappare XML di risposta in JSON per la UI; tenere i template di richiesta in XML quando il contratto remoto lo richiede.
• Ponte di configurazione: mantenere la config interna come JSON; emettere XML per tool che leggono solo XML.
• Costruzione di fixture: scrivere i dati come JSON, convertire in XML per un harness del parser — tenere coppie golden input/output sotto le stesse regole di mapping della produzione.

Limitazioni

Questi tool non validano contro XSD o JSON Schema, non eseguono XSLT e non implementano XML Canonicalization (C14N) per le firme. Si concentrano sulla proiezione pratica degli alberi. Per XML firmato digitalmente usa librerie di firma dedicate.

Tooling correlato

Controlli di sintassi: Valida JSON, Valida XML. Layout JSON puro: Pretty-print JSON. Converti quando il modello deve cambiare; formatta o valida quando resta uguale.