Artikel
Omzetten tussen CSV, XML, JSON en YAML: een praktische handleiding
CSV, JSON, XML en YAML zijn de vier formaten die ontwikkelaars het vaakst tegenkomen in datapijplijnen, configuratiebestanden en API's. Converteren tussen deze formaten is eenvoudig wanneer de datamodellen overeenkomen, en verrassend verliesgevend wanneer dat niet het geval is. Deze handleiding behandelt wat elk formaat wel en niet kan weergeven, waar informatie verloren gaat tijdens conversie, en de coderingsvalkuilen die stille corruptie veroorzaken. De data-converter tool op deze site verwerkt drie van de vier formaten (CSV, JSON en YAML) volledig in de browser; de XML-secties hier zijn achtergrondinformatie voor wanneer u data handmatig of met een aparte tool verplaatst.
De vier formaten en hun datamodellen
CSV organiseert data als een plat raster van rijen en kolommen. De eerste rij bevat doorgaans de kolomnamen; elke volgende rij is één record. Er is geen nesting, geen type-informatie en geen standaard voor iets anders dan platte tekst in cellen. Elke waarde is een string, tenzij de ontvangende applicatie een type oplegt. JSON modelleert data als een boom van objecten (sleutel-waardeparen) en arrays. Waarden kunnen strings, getallen, booleans, null, geneste objecten of arrays van elke diepte zijn. Dit stelt een enkel JSON-document in staat een klantenrecord te vertegenwoordigen met ingebedde adresobjecten, regelitem-arrays en getypeerde numerieke totalen. XML modelleert data als een boom van elementen. Elk element kan benoemde attributen hebben en onderliggende elementen of tekst bevatten. Er is geen ingebouwd numeriek of booleaans type; alles is tekst. Schema's zoals XSD kunnen typen afdwingen tijdens validatie, maar het draadformaat is altijd tekendata. YAML gebruikt inspringing om hetzelfde object-en-array-model als JSON uit te drukken, met schonere voor mensen leesbare syntaxis. YAML is een superset van JSON: elk geldig JSON-document is ook geldig YAML. Het voegt meerregelige strings, commentaar en anker-alias-verwijzingen toe voor herhaalde blokken. YAML is gangbaar in configuratiebestanden; JSON is gangbaar in API-reacties.
Verliesconversies: afvlakken en de XML-dubbelzinnigheid
De meest voorkomende verliesconversie is het afvlakken van geneste JSON of XML naar CSV. Een JSON-object met een genest adresveld kan niet netjes worden omgezet naar een CSV-rij. De typische oplossing is kolomnamen met puntnotatie: customer.address.city wordt een eigen kolom. Dit werkt voor één nestniveau, maar werkt helemaal niet wanneer er een array verschijnt. Een klant met drie telefoonnummers vereist ofwel drie afzonderlijke kolommen (het maximale aantal hard gecodeerd), splitsen in een tweede CSV-bestand, of de array coderen als een begrensd string in één cel. Geen van deze opties geeft het originele JSON terug zonder extra metadata. XML introduceert een aparte dubbelzinnigheid: de keuze tussen attribuut en onderliggend element. De waarde Paris kan worden opgeslagen als attribuut (<city name="Paris">) of als onderliggend element (<city><name>Paris</name></city>). Wanneer een converter XML leest en JSON produceert, moet het beslissen hoe attributen worden gemapt. Gangbare conventies zijn het voorvoegsel @ bij attribuutsleutels of ze plaatsen onder een "_attributes"-sleutel. De keuze is niet gestandaardiseerd, wat betekent dat twee converters die dezelfde XML lezen structureel verschillende JSON kunnen produceren. Als u data via XML en JSON heen en weer wilt sturen, spreek dan van tevoren een conventie af.
CSV-valkuilen: scheidingstekens, aanhalingstekens en codering
CSV heeft geen enkele formele standaard, alleen RFC 4180 als breed geciteerde referentie. Het meest gebruikte scheidingsteken is een komma, maar puntkomma's (gangbaar in Europese taalinstellingen waar komma's als decimaalscheidingsteken dienen), tabs (TSV) en pipes komen ook voor in de praktijk. Een bestand met de extensie .csv kan elk van deze gebruiken zonder aan te geven welk het is. Wanneer een veldwaarde het scheidingsteken zelf bevat, vereist RFC 4180 dat het veld in dubbele aanhalingstekens wordt gewikkeld: "San Francisco, CA". Een dubbel aanhalingsteken in een geciteerd veld moet worden ontsnapt door het te verdubbelen: "He said ""hello""". Een veld met een letterlijke regelafbreking moet ook worden geciteerd. Parsers die deze stap overslaan, produceren rij-telfouten die moeilijk te traceren zijn. Codering is een aparte valkuil. CSV-bestanden van Windows-tools bevatten vaak een UTF-8 BOM (byte order mark: de drie bytes EF BB BF aan het begin van het bestand). De BOM helpt Excel de codering te identificeren, maar veel parsers in programmeertalen behandelen de BOM als onderdeel van de eerste kolomnaam, wat een kolom genaamd "id" oplevert in plaats van "id". Dit breekt elke downstream code die kolommen opzoekt op naam. Verwijder bij programmatisch lezen van een CSV-bestand de BOM voor het parseren, of gebruik een bibliotheek die dit expliciet afhandelt.
Een formaat kiezen: configuratie, uitwisseling en spreadsheets
Formaatkeuze wordt doorgaans bepaald door context, niet door voorkeur. JSON is de standaard voor REST API's en browser-naar-server-uitwisseling. Het is compact, in elke programmeertaal native geparseerd, en bevat type-informatie voor getallen en booleans. De zwakte is het ontbreken van commentaar, waardoor het ongeschikt is voor bestanden die ontwikkelaars handmatig lezen en bewerken. YAML is de voorkeur voor configuratiebestanden (Kubernetes-manifests, CI-pijplijndefinities, Ansible-playbooks) omdat het inline commentaar toestaat en gemakkelijker te lezen is dan JSON met veel inspringniveaus. Het grootste risico is dat inspringfouten stil zijn: een verkeerd ingesprongen sleutel verplaatst naar een ander bereik zonder parseerfout. XML blijft standaard in oudere enterprise-systemen, SOAP-webservices, documentformaten (DOCX, SVG, RSS) en contexten die schemavalidatie of naamruimte-onderscheiding vereisen. Het is uitgebreid, maar XPath- en XSLT-tooling is volwassen. CSV is de juiste keuze wanneer de data werkelijk plat is en de ontvanger een spreadsheettoepassing of data-analist is. Het is niet geschikt voor configuratie of API-uitwisseling omdat het geen typesysteem en geen nesting heeft.
Lokaal doen met data-converter
De data-converter tool op deze site parseert en converteert tussen CSV, JSON en YAML volledig in de browser; XML lezen of schrijven doet hij niet. Er worden geen gegevens naar een server verstuurd. De conversie draait in uw lokale JavaScript-omgeving, en de uitvoer is beschikbaar voor download of kopiëren zonder dat er iets uw apparaat verlaat. Dit is belangrijk voor data die u niet mag delen: API-reacties met persoonlijke informatie, configuratiebestanden met interne hostnamen, of CSV-exports uit interne databases. Als u die data in een webconverter plakt die op een server draait, wordt de inhoud over het netwerk verzonden en verwerkt op hardware die u niet beheert. Met data-converter is het browsertabblad de verwerkingsomgeving. De tool past RFC 4180-aanhalingstekens toe bij het lezen of schrijven van CSV, en verwacht een platte array van objecten wanneer JSON of YAML naar CSV gaat: een geneste object- of arraywaarde onder een sleutel krijgt geen automatische puntnotatie-afvlakking, dus vlak die velden zelf af vóór het converteren als u ze als aparte kolommen nodig heeft. Moet u data naar of van XML verplaatsen, converteer die dan eerst naar JSON of YAML met een speciale XML-tool en breng het resultaat daarna hierheen.
Tools in dit artikel
Veelgestelde vragen
Kan ik JSON via CSV heen sturen en het origineel terugkrijgen?
Alleen als de JSON een platte array van objecten is zonder geneste velden en zonder arrays als waarden. Zodra u een genest object of een array-waarde heeft, vereist de CSV-representatie een structurele beslissing (puntnotatie-kolommen, meerdere rijen of gecodeerde strings) die niet automatisch ongedaan kan worden gemaakt. Als uw data nesting heeft, zullen JSON, XML of YAML foutloos heen en weer gaan; CSV niet.
Waarom ziet mijn CSV er na het exporteren vanuit een Europese applicatie verkeerd uit in Excel?
Europese taalinstellingen gebruiken vaak puntkomma's als CSV-scheidingsteken omdat komma's zijn gereserveerd voor de decimaalnotatie. Excel met een Europese taalinstelling verwacht puntkomma's. Als het bestand komma's gebruikt, behandelt Excel de hele rij als één kolom. De oplossing is ofwel het scheidingsteken in de exportinstellingen te wijzigen, ofwel de wizard Gegevens importeren van Excel te gebruiken, waarmee u het scheidingsteken handmatig kunt opgeven. Het UTF-8 BOM-probleem staat hier los van: zonder BOM kan Excel ook tekens met accenten verkeerd weergeven als onleesbare tekst.
Wat is het verschil tussen YAML en JSON in de praktijk?
Beide vertegenwoordigen hetzelfde onderliggende datamodel: objecten, arrays, strings, getallen, booleans en null. YAML voegt commentaar toe (regels die beginnen met #), meerregelige stringliterals en ankerverwijzingen voor herhaalde blokken. JSON is strikt een subset van geldig YAML, maar JSON-parsers lezen geen YAML. De praktische regel: gebruik JSON voor API-payloads en dataopslag; gebruik YAML voor configuratiebestanden die mensen bewerken en die baat hebben bij inline commentaar.