JSON naar XLSX omzetten

Dat is het hele verschil met omzetten naar CSV, en het bepaalt de rest. Een programma wil CSV: het streamt, elke importroutine leest het, en het draagt geen opmaak mee die in de weg zit. Een mens wil een werkmap die opent met de kolommen op de juiste breedte, de koppen al als koprij en de types al correct.

Gaan de gegevens naar een database, een script of een analysepijplijn, dan is CSV het betere antwoord en is dit de verkeerde pagina. Gaan ze naar een collega die ernaar kijkt, sorteert en er een kolom bij zet, dan is dit de juiste.

Een CSV heeft geen types. Excel opent er een door voor elke kolom te gokken, en die gok is waar de bekende schade ontstaat: voorloopnullen verdwijnen uit postcodes en productcodes, alles wat op een datum lijkt wordt een datum, en identificatienummers vanaf vijftien cijfers verliezen hun laatste cijfers door drijvendekommaproblemen.

Een XLSX legt vast wat elke cel is, zodat er niets wordt afgeleid en niets herschreven bij het openen. Dat ene verschil voorkomt een hele categorie support-vragen, en is de reden om die extra stap te zetten in plaats van een CSV met uitleg te sturen.

Elk record wordt een rij en elke sleutel een kolom, met de koprij afkomstig uit de sleutels zelf. Records die niet dezelfde sleutels delen worden verenigd door over het hele bestand de volledige set kolommen op te bouwen en cellen leeg te laten waar een record niets heeft.

Dat verklaart een veelvoorkomende verrassing: het omzetten van tien records voor een test kan een smaller blad opleveren dan het hele bestand, gewoon omdat de steekproef de zeldzamere velden toevallig niet bevatte.

JSON beschrijft een boom en een spreadsheet is een raster, dus een genest object wordt platgeslagen door de sleutelnamen samen te voegen in de kolomkop. Eén niveau levert een blad op dat iedereen kan lezen; twee niveaus is meestal nog prima.

Daarboven wordt het snel onoverzichtelijk: koppen worden lang, het blad wordt erg breed, en de meeste cellen in de meeste rijen zijn leeg omdat records verschillend genest zijn. Levert een omzetting zestig kolommen op uit wat een simpele export leek, dan is dat de vorm van de data en geen fout — en een teken dat de JSON eigenlijk JSON moet blijven.

Een bestelling met vijf regels, een bericht met een lijst tags, een persoon met meerdere vorige adressen — geen van deze heeft een goede weergave in één rij. De drie mogelijke antwoorden zijn één kolom per positie, één kolom met samengevoegde waarden, of één rij per element, en elk daarvan breekt iets.

Draagt een array de betekenis, doe dan wat een database zou doen: maak één blad voor de hoofdrecords en één voor de onderliggende, gekoppeld via een identificatienummer. Dat kost meer werk dan één omzetting en is de enige versie die een spreadsheetgebruiker echt kan doorgronden.

Het archief dat ChatGPT, Claude of een API-dashboard aflevert is JSON omdat een machine dat leest, en de meeste ontvangers hebben geen tool die daar iets nuttigs mee doet. Een spreadsheet is dan het praktische antwoord: XLSX legt de types vast, dus tijdstempels blijven tijdstempels en lange numerieke ID’s worden niet stiekem in wetenschappelijke notatie herschreven zoals een in Excel geopende CSV dat zou doen.

Het werkt goed voor de platte onderdelen — gebruikslogboeken, factuurregels, berichtenlijsten met één rij per item. Het werkt slecht voor het gespreksarchief zelf, dat een boom van berichtknopen is en geen tabel, en het platslaan daarvan levert kolommen op met paden die niemand wil lezen. Zet alleen het deel om dat je echt nodig hebt.

Loop kort door het blad. Twee dingen zijn steeds de moeite waard: dat identificatiekolommen als tekst worden gelezen in plaats van omgezet in getallen, en dat datumkolommen eruitzien als datums en niet als getallen van vijf cijfers.

En kijk wat er werkelijk in staat. Een JSON-export van een API bevat elk veld dat de API teruggeeft, inclusief interne identifiers, vlaggen en soms velden waarvan niemand wist dat ze bestonden. Een spreadsheet maakt dat allemaal zichtbaar op een manier die een JSON-bestand niet doet — beter om dat te ontdekken voordat het bestand je organisatie verlaat dan erna.

De omzetting draait in het browsertabblad op je eigen processor. Het bestand wordt nooit ergens naartoe gestuurd, er is geen account en geen daglimiet, en de grens ligt op 100 MB per bestand.

Dat is hier relevanter dan bij de meeste omzettingen. Een JSON-export is vrijwel altijd ruwe systeemuitvoer — klantgegevens, bestellingen, formulierinzendingen, gebruikersaccounts — en die aan een externe converter geven betekent precies de data afstaan waar een organisatie verantwoordelijk voor is. Niets versturen is de eenvoudigste manier om niemand te hoeven vertrouwen.