JSON naar XML omzetten

Een XML-document heeft één buitenste element. Een JSON-document kan een object met vijftien sleutels zijn, of een array, of een kaal getal, en geen daarvan heeft een naam voor de container. De omzetting hanteert dus een regel: een object met precies één sleutel gebruikt die sleutel als root; al het andere wordt in een element genaamd root gewikkeld. De uitzondering: houdt die ene sleutel een array in, {"items": [1, 2]}, dan zou die sleutel als root tweemaal <items> schrijven — daarom komt <root> om het paar heen.

Het eerste geval is waar je naartoe wilt werken, en het is een kleine aanpassing aan de JSON als je de bron beheert. Je payload in één sleutel wikkelen die benoemt wat het is — factuur, bestelling, zending — betekent dat de XML met de elementnaam komt die het ontvangende systeem verwacht.

XML heeft geen array-type en had er ook nooit een nodig: een lijst is dezelfde tag meerdere keren in dezelfde ouder geschreven. Een object met drie tags levert dus drie <tags>-elementen achter elkaar op — precies de vorm die elke XML-consument al aankan.

Dit is de ene plek waar XML beter bij JSON past dan de tabelformaten. Dezelfde array naar CSV omzetten dwingt een keuze tussen extra kolommen, een samengevoegde string en extra rijen. In XML is de herhaling native, dus een bestelling met vijf orderregels zet zonder enige beslissing om.

XML heeft twee manieren om een waarde aan een element te hangen — een attribuut in de tag of een kindelement — en schema’s vinden dat verschil belangrijk. JSON kent er maar één. De conventie hier overbrugt dat: een sleutel die met @ begint, wordt als attribuut geschreven, en een sleutel #text levert de eigen tekst van het element.

Die conventie is niet willekeurig; het is wat de XML-lezer van deze site in de andere richting produceert. Een document omgezet naar JSON, bewerkt en teruggezet, geeft de attributen terug als attributen. Verwacht de ontvanger id als attribuut en heeft je JSON het als gewone sleutel, dan is die sleutel hernoemen naar @id de hele oplossing.

JSON-sleutels kunnen elke string zijn: spaties, schuine strepen, emoji, een leidend cijfer. XML-elementnamen niet. De schrijver herschrijft in plaats van te falen, en doet dat tegen een bewust smalle lijst — A-Z, a-z, 0-9, underscore, punt en koppelteken blijven staan, de rest wordt een underscore, en een naam die met een cijfer begint krijgt er één voor. «2024 report» wordt dus <_2024_report>.

Die lijst is smaller dan die van XML 1.0 zelf, en dat is het geval dat je het snelst te pakken krijgt: XML-elementnamen mogen letters met accenten, Grieks, Cyrillisch en CJK bevatten, en deze schrijver behoudt er geen enkele van. Een sleutel café komt aan als <caf_>. Hernoem die sleutels in de JSON, of herstructureer zodat het variabele deel een waarde wordt in plaats van een sleutel.

XML brengt naamruimten, XSD-schema’s, DTD’s, verwerkingsinstructies, CDATA-secties en digitale handtekeningen — het register noemt handtekeningondersteuning als een van de eigenschappen, en dat is de reden dat het formaat nog altijd de ruggengraat is van bankieren en overheidsuitwisseling. Niets daarvan is uit een JSON-bestand af te leiden.

In de praktijk: de uitvoer is welgevormd, niet gevalideerd. Valideert de ontvangende kant tegen een XSD, verwacht dan een naamruimtedeclaratie op het root-element toe te moeten voegen en mogelijk elementen te herordenen, want XSD-volgorde is gevoelig en JSON-objectvolgorde niet betekenisvol.

Ampersands, punthaken en dubbele aanhalingstekens in een waarde worden bij het schrijven ontsnapt, wat voorkomt dat een productomschrijving met «Tom & Jerry <special>» het document voortijdig beëindigt. Al het andere, inclusief apostrofs en elk niet-ASCII-teken, wordt als UTF-8 doorgeschreven.

Een JSON null wordt een leeg element: de tag staat er, zonder iets tussen opening en sluiting. Dat is een bewuste keuze — XML kent ook xsi:nil voor precies dit geval, en sommige schema’s eisen dat. Is dat bij jou zo, dan is de vervanging een zoek-en-vervang op de lege elementen.

Het document is geschreven met inspringing van twee spaties en één element per regel, wat het leesbaar maakt en een diff tussen twee payloads te volgen. Het begint niet met de regel <?xml version="1.0"?>. XML 1.0 maakt die declaratie optioneel en definieert UTF-8 als standaardcodering.

Sommige oudere ontvangende systemen zijn het daarmee oneens en falen met een onduidelijke melding als de regel ontbreekt. Het is één regel om bovenaan toe te voegen — de moeite van weten waard vóór de eerste indiening.

Elke waarde wordt in een openings- en sluitingstag gewikkeld, dus veldnamen verschijnen twee keer per record in plaats van één keer. Bij kleine waarden met lange veldnamen kan het document twee tot drie keer de grootte van de JSON zijn, en de inspringing telt daar nog bij op.

Dat is een echte kostenpost op een wachtrij met een berichtgrootte-limiet en geen kostenpost op een bestandsoverdracht, waar de meeste van deze leveringen naartoe gaan. Telt het wel, dan is compressie het antwoord: XML is zeer repetitieve tekst en comprimeert uitstekend met gzip.

Twee controles, in volgorde. Welgevormdheid eerst: elke XML-editor, browser of commandoregel-parser vertelt binnen een seconde of het document ontleedbaar is, en dat zou hier altijd moeten kloppen.

Validatie tegen het schema daarna, en verwacht dat die de eerste keer faalt. De fouten zijn informatief — een ontbrekende naamruimte, een element in de verkeerde volgorde — en elk is een kleine aanpassing in de JSON of in de uitvoer.

De omzetting is JavaScript in dit tabblad: de browser ontleedt de JSON, een kleine schrijver produceert de XML, en geen verzoek draagt het document ergens naartoe. Geen aanmelding, geen wachtrij, geen daglimiet, en het gratis niveau accepteert tot 100 MB.

Voor dit publiek is dat vaak de doorslag in plaats van een leuk extraatje. De payloads die XML moeten worden zijn betalingen, claims, aangiften en patiënt- of klantgegevens — precies de categorieën waarbij een bestand naar een onbekende webdienst plakken een meldingsplichtig incident is.