Formattatore e minificatore XML

Una guida pratica all'XML

XML 1.0 è diventato una W3C Recommendation il 10 febbraio 1998, edito da Tim Bray, Jean Paoli e C. M. Sperberg-McQueen, con un gruppo di lavoro presieduto da Jon Bosak di Sun. La citazione di lancio di Tim Bray ha catturato l'intento progettuale: «XML è estensibile, internazionalizzato, robusto, semplice e costruito per il Web.» La versione canonica attuale è la Quinta Edizione, pubblicata il 26 novembre 2008, edita da Bray, Paoli, Sperberg-McQueen, Eve Maler e François Yergeau. XML discende direttamente da SGML (ISO 8879:1986), un formato di documenti molto più grande e difficile da implementare, da cui XML ha eliminato la maggior parte delle parti raramente utilizzate mantenendo intatto il modello di documento.

Dove vive ancora l'XML nel 2026

JSON ha dominato i payload delle REST API per oltre un decennio, ma l'XML rimane radicato ovunque la rigidità dello schema, la semantica dei documenti o gli standard consolidati lo rendano necessario. Sapere dove lo si incontrerà in un dato giorno è metà del valore di un buon formatter:

• Formati di documenti Office: .docx, .xlsx e .pptx di Microsoft sono archivi zip pieni di parti XML, standardizzate come ECMA-376 e ISO/IEC 29500. .odt, .ods e .odp di OpenDocument (ISO/IEC 26300) seguono lo stesso pattern. Anche gli ebook EPUB sono in pacchetti XML.
• Vocabolari web: SVG (grafica vettoriale), MathML (notazione matematica), feed Atom, RSS 2.0 e il protocollo sitemap.xml che Google e Bing analizzano per la pianificazione della scansione.
• SOAP e messaggistica enterprise: i back-end di banche, telecomunicazioni, assicurazioni e amministrazioni pubbliche espongono ancora endpoint SOAP, spesso dietro una facciata REST. Gli standard di settore basati su XML includono FpML per i derivati, XBRL per i depositi SEC, ACORD per le assicurazioni e ISO 20022 per la messaggistica dei pagamenti.
• File di build e configurazione: pom.xml di Maven, i bean Spring legacy, ogni risorsa Android (AndroidManifest.xml, res/values/strings.xml, res/layout/*.xml) e Info.plist di Apple nella sua variante XML.
• Interscambio per domini verticali: KML per Google Earth, GPX per le tracce GPS, MusicXML per gli spartiti musicali (4.0 pubblicato nel 2021), XLIFF per la localizzazione (2.1 standardizzato come ISO 21720 nel luglio 2024), HL7 v3/CDA per i documenti clinici.

Corretto (well-formed) vs valido: non sono la stessa cosa

L'XML usa due livelli di conformità diversi ed è facile confonderli:

• Corretto (well-formed) significa che il documento rispetta la grammatica XML: esattamente un elemento radice, tutti i tag bilanciati e correttamente annidati, i valori degli attributi tra virgolette, i riferimenti ad entità chiusi con un punto e virgola, nessun < o & non escaped nel contenuto testuale.
• Valido significa che un documento corretto è inoltre conforme a un DTD, XSD (XML Schema 1.1), RELAX NG o schema Schematron dichiarato: gli elementi giusti nei posti giusti, con valori di attributo dei tipi corretti e nelle cardinalità corrette.

Questo formatter verifica solo la correttezza (well-formedness). Il DOMParser integrato nel browser segnala il primo errore di analisi tramite un elemento parsererror, che lo strumento mostra nella casella di errore rossa. La validazione rispetto a uno schema richiede uno strumento diverso (Saxon per XSD, libxml2 con xmllint --schema, il servizio di validazione W3C, ecc.).

I cinque riferimenti ad entità predefinite

Per W3C XML 1.0 §4.6, «i documenti well-formed non devono dichiarare nessuna delle seguenti entità»: amp, lt, gt, apos, quot. Il punto e virgola finale è obbligatorio; l'XML, a differenza di alcuni usi HTML, non accetterà mai &amp senza un ; finale.

Sezioni CDATA, commenti e istruzioni di elaborazione

Tre caratteristiche sintattiche speciali che chiunque formatti XML incontra prima o poi:

• Sezioni CDATA: i blocchi <![CDATA[ … ]]> consentono di incorporare testo arbitrario senza effettuare l'escape di < e &. L'unica sequenza che non è possibile inserire in un CDATA è il delimitatore di chiusura letterale ]]>. Utile per incorporare campioni di codice, pattern regex o frammenti HTML all'interno della documentazione XML.
• Commenti: <!-- … -->. La stringa -- è illegale all'interno di un commento.
• Istruzioni di elaborazione: <?target …?>. La dichiarazione XML non è tecnicamente un'istruzione di elaborazione, ma la maggior parte degli strumenti la tratta allo stesso modo: <?xml version="1.0" encoding="UTF-8"?> è la prima riga consigliata.

Namespace

Il meccanismo dei namespace dell'XML consente a più vocabolari di coesistere in un unico documento: Atom con un'estensione personalizzata, SOAP con intestazioni WS-Security, la parte principale del documento OOXML che referenzia relazioni, disegni e immagini da namespace associati. La sintassi è xmlns="…" per un namespace predefinito e xmlns:prefix="…" per uno prefissato; il formatter preserva entrambi invariati. Gli URI dei namespace sono identificatori, non URL: non devono necessariamente essere risolvibili.

Due famosi problemi di sicurezza dell'XML

L'attacco Billion Laughs. Un piccolo file XML con entità che si espandono ricorsivamente può gonfiarsi fino a miliardi di caratteri nella memoria del parser:

<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!-- … nine more layers later, the document expands to 10^9 lols -->

I parser moderni limitano l'espansione delle entità per contrastarlo. Gli attacchi XXE (XML External Entity) sfruttano un parser che risolve entità esterne per leggere file locali (<!ENTITY xxe SYSTEM "file:///etc/passwd">) o innescare richieste SSRF dal server. Il foglio informativo OWASP sulla prevenzione XXE è inequivocabile: «il modo più sicuro per prevenire XXE è sempre disabilitare completamente i DTD (Entità esterne).» È esattamente quello che fa il DOMParser del browser: ignora completamente le dichiarazioni di entità DOCTYPE, motivo per cui questo formatter lato client è sicuro anche quando si inserisce XML non attendibile.

Formattazione vs minificazione

• Formattazione/abbellimento: indenta gli elementi annidati, posiziona i tag di apertura e chiusura su righe proprie e produce un output molto più facile da leggere, ma tipicamente del 30-50% più grande dell'equivalente minificato. Usare questa opzione durante il debug, la revisione dei diff o l'apprendimento di uno schema non familiare.
• Minificazione: rimuove tutti gli spazi bianchi tra gli elementi preservando gli spazi bianchi nel contenuto testuale (l'XML definisce gli spazi bianchi nel contenuto degli elementi come significativi per impostazione predefinita, a meno che non vengano sovrascritti da xml:space="default"). Usare questa opzione per i payload di produzione e per qualsiasi caso in cui il numero di byte trasmessi sia importante.

L'attributo xml:space è la via d'uscita quando gli spazi bianchi sono davvero importanti, ad esempio per il codice sorgente verbatim incorporato nella documentazione. Impostare xml:space="preserve" su un elemento antenato e un processore conforme preserverà ogni spazio e carattere newline nei discendenti byte per byte.

Errori XML comuni che un formatter intercetta

1. & non escaped nel contenuto testuale. Un ampersand puro è sempre non valido; usare &.
2. Tag non corrispondenti o non chiusi. L'errore di analisi più comune. Ogni <tag> necessita di un </tag> corrispondente (oppure usare la forma auto-chiudente <tag/>).
3. Elementi radice multipli. Un documento XML deve avere esattamente un elemento più esterno. Se ci sono due elementi fratelli al livello superiore, è necessario racchiuderli in un elemento genitore.
4. Mancata corrispondenza della codifica. Una dichiarazione <?xml version="1.0" encoding="UTF-8"?> deve corrispondere alla codifica dei byte effettiva del file. Un BOM UTF-16 con una dichiarazione UTF-8 è la versione classica di questo bug.
5. Caratteri riservati nei valori degli attributi. <tag attr="a<b"> non è valido anche se < sembra innocuo tra le virgolette.
6. BOM anomalo davanti alla dichiarazione XML. Alcuni editor di testo inseriscono silenziosamente un BOM UTF-8 che confonde i parser rigorosi.
7. Terminazioni di riga miste all'interno delle regioni xml:space="preserve". CR/LF/CRLF incoerenti possono produrre artefatti di spazio bianco visibili durante il round-trip attraverso piattaforme diverse.

Altre domande frequenti

Perché la formattazione del mio XML non produce output?

Nella maggior parte dei casi perché l'input non è well-formed. La casella di errore sopra l'output mostra il primo errore di analisi riscontrato dal DOMParser del browser: di solito un tag mancante o non corrispondente, un & non escaped o un elemento radice mancante. Correggere l'errore e rieseguire.

Il mio XML viene caricato su un server?

No. Formattazione e minificazione vengono entrambe eseguite all'interno del DOMParser integrato nel browser e di un piccolo serializzatore JavaScript. Il proprio XML non lascia mai la pagina, il che è importante per i payload SOAP, i file di configurazione e qualsiasi altra cosa che possa contenere credenziali, URL interni o dati sensibili dei clienti.

Lo strumento può validare rispetto a uno schema XSD o DTD?

No. La validazione dello schema richiede il caricamento del file di schema e la risoluzione dei suoi riferimenti, che è un problema diverso dal controllo di well-formedness eseguito dal browser. Per la validazione XSD, usare Saxon o xmllint --schema dalla riga di comando, oppure il servizio di validazione XML Schema del W3C.

L'XML è ancora rilevante nel 2026, o dovrei semplicemente usare JSON?

Dipende da cosa si sta facendo. Per le nuove REST API, JSON è quasi sempre la scelta giusta. Ma l'XML è ancora il formato predefinito per i documenti Office (.docx, .xlsx), la messaggistica enterprise (SOAP, standard finanziari), le risorse Android, EPUB, RSS/Atom, SVG e la maggior parte degli interscambi in settori regolamentati. Saper leggere, formattare e validare l'XML è ancora una competenza di base; semplicemente non è il primo strumento di ogni giornata come lo è JSON.

Cosa significa «preservare tutti i tipi di nodo» per il formatter?

Le sezioni CDATA, i commenti e le istruzioni di elaborazione vengono mantenuti esattamente come appaiono nell'input; il formatter modifica solo gli spazi bianchi tra gli elementi. Quindi un blocco <![CDATA[ if (a < b) { … } ]]> viene preservato byte per byte anche se il suo contenuto contiene caratteri < che altrimenti richiederebbero l'escape.