Artikel
Konvertering mellem CSV, XML, JSON og YAML: en praktisk guide
CSV, JSON, XML og YAML er de fire formater, som udviklere oftest møder i datapipelines, konfigurationsfiler og API'er. Konvertering mellem dem er ligetil, når datamodellerne passer sammen, og overraskende tabsgivende, når de ikke gør. Denne guide gennemgår, hvad hvert format kan og ikke kan repræsentere, hvor information forsvinder under konvertering, og de indkodningsfælder, der forårsager lydløs korruption. Værktøjet data-converter på dette site håndterer tre af de fire (CSV, JSON og YAML) helt i browseren; XML-afsnittene her er baggrundsviden til, når du flytter data manuelt eller med et separat værktøj.
De fire formater og deres datamodeller
CSV organiserer data som et fladt gitter af rækker og kolonner. Den første række navngiver typisk kolonnerne; alle efterfølgende rækker er én post. Der er ingen indlejring, ingen typeinformation og ingen standard for andet end almindelig tekst i celler. Alle værdier er strenge, medmindre den forbrugende applikation påtvinger en type. JSON modellerer data som et træ af objekter (nøgle-værdi-kort) og arrays. Værdier kan være strenge, tal, booleaner, null, indlejrede objekter eller arrays af vilkårlig dybde. Det giver et enkelt JSON-dokument mulighed for at repræsentere en kundepost med indlejrede adresseobjekter, linjeelementarrays og indtastede numeriske totaler. XML modellerer data som et træ af elementer. Hvert element kan indeholde navngivne attributter og underordnede elementer eller tekstindhold. Der er ingen indbygget numerisk eller boolesk type; alt er tekst. Skemaer som XSD kan håndhæve typer ved valideringstidspunktet, men trådformatet er altid karakterdata. YAML bruger indrykning til at udtrykke den samme objekt-og-array-model som JSON med renere menneskelæsbar syntaks. YAML er et supersæt af JSON: ethvert gyldigt JSON-dokument er også gyldigt YAML. Det tilføjer flerlinjestrenge, kommentarer og anker-alias-referencer til gentagne blokke. YAML er almindeligt i konfigurationsfiler; JSON er almindeligt i API-svar.
Tabsgivende konverteringer: fladtrykning og XML-tvetydigheden
Den mest almindelige tabsgivende konvertering er fladtrykning af indlejret JSON eller XML til CSV. Et JSON-objekt med et indlejret adressefelt kan ikke mappes rent til en CSV-række. Den typiske løsning er punktnotationskolonnenavne: customer.address.city bliver sin egen kolonne. Det fungerer for ét indlejringsniveau, men bryder fuldstændigt sammen, når et array optræder. En kunde med tre telefonnumre kræver enten tre separate kolonner (med hardkodet maksimalt antal), opdeling i en anden CSV-fil eller indkodning af arrayet som en afgrænset streng inde i en enkelt celle. Ingen af disse muligheder vender tilbage til den originale JSON uden ekstra metadata. XML introducerer en separat tvetydighed: valget mellem attribut og underordnet element. Værdien Paris kan lagres som en attribut (<city name="Paris">) eller som et underordnet element (<city><name>Paris</name></city>). Når en konverter læser XML og producerer JSON, skal den beslutte, hvordan attributter skal mappes. Almindelige konventioner inkluderer at præfikse attributnøgler med @ eller placere dem under en "_attributes"-nøgle. Valget er ikke standardiseret, hvilket betyder, at to konvertere, der læser den samme XML, kan producere strukturmæssigt forskellig JSON. Hvis du planlægger at round-triple data gennem XML og JSON, fastsæt en konvention inden start.
CSV-fælder: afgrænsningstegn, angivelse og indkodning
CSV har ingen enkelt formel standard, kun RFC 4180 som en bredt citeret reference. Det mest almindelige afgrænsningstegn er et komma, men semikoloner (almindelige i europæiske lokaliteter, hvor kommaer bruges som decimalseparatorer), tabulatorer (TSV) og lodrette streger optræder alle i praksis. En fil kaldet .csv kan bruge et af disse uden at angive hvilket. Når en feltværdi indeholder selve afgrænsningstegnet, kræver RFC 4180, at feltet omsluttes i dobbelte anførselstegn: "San Francisco, CA". Et dobbelt anførselstegn inde i et angivet felt skal escapes ved at fordoble det: "He said ""hello""". Et felt, der indeholder et bogstaveligt linjeskift, skal også angives. Parsere, der springer dette trin over, producerer rækkeantalsfejl, der er svære at spore. Indkodning er en separat fælde. CSV-filer fra Windows-værktøjer bærer ofte en UTF-8 BOM (byte order mark: de tre bytes EF BB BF i starten af filen). BOM hjælper Excel med at identificere indkodningen, men mange programmeringssprogparsere behandler BOM som en del af det første kolonnenavn og producerer en kolonne med navnet "id" i stedet for "id". Dette bryder enhver downstream-kode, der slår kolonner op efter navn. Når du læser en CSV-fil programmatisk, fjern BOM inden parsing, eller brug et bibliotek, der håndterer det eksplicit.
Valg af format: konfiguration, udveksling og regneark
Formatvalget bestemmes normalt af kontekst, ikke præference. JSON er standarden for REST API'er og browser-til-server-udveksling. Det er kompakt, natligt parset i alle programmeringssprog og bærer typeinformation for tal og booleaner. Dets svaghed er fraværet af kommentarer, hvilket gør det uegnet til filer, som udviklere læser og redigerer i hånden. YAML foretrækkes til konfigurationsfiler (Kubernetes-manifester, CI-pipeline-definitioner, Ansible-playbooks), fordi det tillader inline-kommentarer og er lettere at læse end JSON med mange indryningsniveauer. Den største risiko er, at indrykningsfejl er lydløse: en fejlindrykket nøgle flyttes til et andet omfang uden nogen parsefejl. XML forbliver standard i ældre virksomhedssystemer, SOAP-webtjenester, dokumentformater (DOCX, SVG, RSS) og kontekster, der kræver skemavalidering eller navnerumsdisambiguering. Det er ordret, men XPath og XSLT-værktøjet er modent. CSV er det rigtige valg, når dataene er genuint flade, og forbrugeren er et regnearksprogram eller en dataanalytiker. Det er ikke egnet til konfiguration eller API-udveksling, fordi det ikke har noget typesystem og ingen indlejring.
Gør det lokalt med data-converter
Værktøjet data-converter på dette websted parser og konverterer mellem CSV, JSON og YAML helt inde i browseren; det læser eller skriver ikke XML. Ingen data overføres til en server på noget tidspunkt. Konverteringen kører i dit lokale JavaScript-runtime, og outputtet er tilgængeligt til download eller kopiering uden at noget forlader din enhed. Det betyder noget for data, der ikke er dit at dele: API-svar, der indeholder personoplysninger, konfigurationsfiler med interne værtsnavne eller CSV-eksporter fra interne databaser. Indsætning af disse data i en webbaseret konverter, der kører på en server, betyder, at indholdet sendes over netværket og behandles på hardware, du ikke kontrollerer. Med data-converter er browserfanen behandlingsmiljøet. Værktøjet anvender RFC 4180-angivelse, når det læser eller skriver CSV, og forventer et fladt array af objekter, når JSON eller YAML konverteres til CSV: en indlejret objekt- eller array-værdi under en nøgle får ingen automatisk punktnotationsfladtrykning, så du skal selv fladtrykke de felter, før du konverterer, hvis du har brug for dem som separate kolonner. Har du brug for at flytte data til eller fra XML, så konverter det til JSON eller YAML med et dedikeret XML-værktøj først, og bring så resultatet herhen.
Værktøjer i denne artikel
Ofte stillede spørgsmål
Kan jeg round-triple JSON gennem CSV og få det originale tilbage?
Kun hvis JSON er et fladt array af objekter uden indlejrede felter og ingen arrays som værdier. I det øjeblik du har et indlejret objekt eller en arrayværdi, kræver CSV-repræsentationen en strukturbeslutning (punktnotationskolonner, flere rækker eller indkodede strenge), der ikke automatisk kan vendes om. Hvis dine data har indlejring, vil JSON, XML eller YAML round-triple rent; CSV vil ikke.
Hvorfor ser min CSV forkert ud i Excel efter eksport fra et europæisk program?
Europæiske lokaliteter bruger ofte semikoloner som CSV-afgrænsningstegn, fordi kommaer er reserveret til decimalnotation. Excel i en europæisk lokalitet forventer semikoloner. Hvis filen bruger kommaer, behandler Excel hele rækken som en enkelt kolonne. Løsningen er enten at ændre afgrænsningstegnet i eksportindstillingerne eller bruge Excels guiden til dataimport, som lader dig angive afgrænsningstegnet manuelt. UTF-8 BOM-problemet er separat: uden en BOM kan Excel også fejllæse accenterede tegn som forvansket tekst.
Hvad er forskellen mellem YAML og JSON i praksis?
Begge repræsenterer den samme underliggende datamodel: objekter, arrays, strenge, tal, booleaner og null. YAML tilføjer kommentarer (linjer der begynder med #), flerlinjestrenge og ankerreferencer til gentagne blokke. JSON er strengt taget et undersæt af gyldig YAML, men JSON-parsere læser ikke YAML. Den praktiske regel: brug JSON til API-nyttelaster og datalagring; brug YAML til konfigurationsfiler, som mennesker redigerer, og som drager fordel af inline-kommentarer.