JSON naar CSV omzetten

Dit is het ene ding om te begrijpen voor je iets omzet. JSON beschrijft een boom: een object kan een ander object bevatten, dat weer een reeks objecten kan bevatten, tot elke diepte. Een CSV beschrijft een raster: rijen en kolommen, en niets binnen een cel.

De omzetting is dus geen vertaling tussen twee schrijfwijzen van hetzelfde, maar een projectie, en er moet iets wijken. Voor data die echt een lijst platte records is — de meeste exports — gaat niets verloren. Voor diep gestructureerde data is de CSV een leesbare benadering en blijft de JSON het echte bestand.

Een genest object wordt platgeslagen door de sleutelnamen samen te voegen, dus een record met een klant met een woonplaats erin levert een kolom op die beide namen combineert. Eén niveau nesting geeft een tabel die iedereen kan lezen. Twee is meestal nog prima.

Daarboven verslechtert het snel: kolomnamen worden lang, de tabel wordt erg breed, en de meeste cellen in de meeste rijen zijn leeg omdat verschillende records anders genest zijn. Levert een omzetting zestig kolommen op uit wat een simpele export leek, dan is dat de vorm van de data die doorschemert.

Een record met drie tags, vier orderregels of een lijst vorige adressen heeft geen correcte weergave in een tabel. Er zijn drie gangbare antwoorden en elk is ergens fout: één kolom per positie, wat breekt als een record er vijf heeft; één kolom met waarden aan elkaar geplakt met een scheidingsteken, wat onleesbaar is als de waarden dat teken bevatten; of één rij per array-element, wat het ouderrecord dupliceert.

Dragen arrays de betekenis — een bestelling met orderregels, een bericht met reacties — dan is het eerlijke antwoord niet om te converteren. Bewaar de JSON, of maak twee tabellen zoals een database dat zou doen: één voor bestellingen en één voor orderregels, gekoppeld via een id.

Records in een JSON-export hoeven niet dezelfde sleutels te hebben. Een API retourneert velden die bestaan en laat velden weg die dat niet doen, dus honderd records kunnen tachtig verschillende vormen tonen.

De omzetting lost dat op door over alle records te kijken en de volledige set kolommen te bouwen, met een lege cel waar een record geen waarde heeft. Dat is meestal wat je wilt, en het verklaart een veelvoorkomende verrassing: een steekproef van tien records omzetten levert minder kolommen op dan het hele bestand.

Een correcte CSV produceren beschermt niet tegen wat daarna gebeurt. Excel opent een bestand door per kolom een type te raden, wat voorloopnullen uit codes strijpt, alles wat op een datum lijkt omzet, en id’s boven vijftien cijfers afkapt.

De remedie is als altijd: importeren in plaats van openen — Gegevens, dan Uit tekst/CSV — en id-kolommen op Tekst zetten voor het laden. Is de ontvanger een mens in plaats van een programma, dan neemt omzetten naar XLSX het raden helemaal weg.

Zet om als de data platte records zijn en de bestemming een spreadsheet, databaseimport of collega is. Dat dekt de meeste exports uit analyseplatforms, CRM’s en rapportage-API’s, en de CSV is voor al die gevallen makkelijker dan de JSON.

Zet niet om als de structuur de inhoud is — een configuratiebestand, een geneste API-respons waar je programmatisch mee wilt werken. Bewaar de JSON hoe dan ook: het is het bestand dat nog alles bevat, en een CSV eruit opnieuw genereren kost seconden.

Data-exports van AI-diensten zijn tegenwoordig een van de meest voorkomende redenen om een JSON-bestand te openen, en het ChatGPT-archief is het gangbare geval. Het bestand conversations.json is geen lijst rijen: het is een verzameling berichtenbomen, elke node wijzend naar zijn ouder, wat vertakte en bewerkte gesprekken weergeeft. Er zit geen eerlijk raster in.

Omzetten naar CSV levert iets technisch geldigs en praktisch onbruikbaars op — één rij per node, met de gespreksstructuur verdwenen. Wil je je gesprekken lezen, open dan het HTML-bestand in hetzelfde archief. CSV is het juiste doel voor de plattere exports ernaast, zoals gebruiks- en factuurgegevens.

Een JSON-array moet compleet zijn voor hij ontleed kan worden, want het sluithaakje maakt hem pas geldig. Een zeer groot bestand moet dus in zijn geheel gelezen worden, een eigenschap van het formaat, niet van een specifiek hulpmiddel.

Bepaal je zelf hoe de data geproduceerd wordt, vraag dan om NDJSON — één compleet JSON-object per regel — in plaats van één grote array. Elke regel wordt apart ontleed: een beschadigde of afgekapte regel faalt met zijn eigen regelnummer in plaats van het hele document ongeldig te maken.

De omzetting draait in je browser op je eigen processor. Het bestand wordt nergens naartoe gestuurd, er is geen account en geen daglimiet, en bestanden tot 100 MB worden in het tabblad verwerkt.

Dat weegt hier zwaarder dan bij de meeste omzettingen. Een JSON-export is bijna altijd de ruwe uitvoer van een API — klantgegevens, bestelgeschiedenis, formulierinzendingen — en bevat vaak velden waar niemand bij stilstond. Niets versturen is het eenvoudige antwoord.