Artikkel
Konvertere mellom CSV, XML, JSON og YAML: en praktisk guide
CSV, JSON, XML og YAML er de fire formatene utviklere oftest møter i databehandlingspipelines, konfigurasjonsfiler og API-er. Konvertering mellom dem er grei når datamodellene samsvarer, og overraskende tapsbringende når de ikke gjør det. Denne guiden dekker hva hvert format kan og ikke kan representere, hvor informasjon forsvinner under konvertering, og kodingsfellene som forårsaker stille korrupsjon. Data-converter-verktøyet på dette nettstedet håndterer tre av de fire (CSV, JSON og YAML) helt inne i nettleseren; XML-avsnittene her er bakgrunnsstoff for når du flytter data for hånd eller med et separat verktøy.
De fire formatene og deres datamodeller
CSV organiserer data som et flatt rutenett av rader og kolonner. Den første raden navngir vanligvis kolonnene; hver påfølgende rad er én post. Det er ingen nesting, ingen typeinformasjon og ingen standard for noe utover ren tekst i celler. Alle verdier er strenger med mindre den forbrukende applikasjonen pålegger en type. JSON modellerer data som et tre av objekter (nøkkelverdi-kart) og matriser. Verdier kan være strenger, tall, booleanere, null, nestede objekter eller matriser i vilkårlig dybde. Dette gjør at et enkelt JSON-dokument kan representere en kundepost med innebygde adresseobjekter, varelinjematriser og typede numeriske totaler. XML modellerer data som et tre av elementer. Hvert element kan ha navngitte attributter og inneholde underordnede elementer eller tekstinnhold. Det er ingen innebygd numerisk eller boolsk type; alt er tekst. Skjemaer som XSD kan håndheve typer ved valideringstidspunktet, men ledningsformatet er alltid tegndata. YAML bruker innrykk for å uttrykke den samme objekt-og-matrise-modellen som JSON, med renere menneskelig lesbar syntaks. YAML er et supersett av JSON: ethvert gyldig JSON-dokument er også gyldig YAML. Det legger til flerlinjestrenger, kommentarer og anker-alias-referanser for gjentatte blokker. YAML er vanlig i konfigurasjonsfiler; JSON er vanlig i API-responser.
Tapsbringende konverteringer: utflating og XML-tvetydigheten
Den vanligste tapsbringende konverteringen er å flate ut nestet JSON eller XML til CSV. Et JSON-objekt med et nestet adressefelt kan ikke kartlegges rent til en CSV-rad. Den typiske løsningen er kolonnenavn med punktnotasjon: customer.address.city blir sin egen kolonne. Dette fungerer for ett nivå av nesting, men bryter fullstendig når en matrise dukker opp. En kunde med tre telefonnumre krever enten tre separate kolonner (hardkoding av maksimalt antall), deling i en andre CSV-fil, eller koding av matrisen som en avgrenset streng inne i én celle. Ingen av disse alternativene kan konverteres tilbake til den opprinnelige JSON-en uten ekstra metadata. XML introduserer en separat tvetydighet: valget mellom attributt og underordnet element. Verdien Paris kan lagres som et attributt (<city name="Paris">) eller som et underordnet element (<city><name>Paris</name></city>). Når en konverterer leser XML og produserer JSON, må den bestemme hvordan attributter skal kartlegges. Vanlige konvensjoner inkluderer å prefikse attributtnøkler med @ eller plassere dem under en "_attributes"-nøkkel. Valget er ikke standardisert, noe som betyr at to konverterere som leser den samme XML-en kan produsere strukturelt forskjellig JSON. Hvis du planlegger å sende data frem og tilbake mellom XML og JSON, fastsett en konvensjon før du starter.
CSV-fallgruver: skilletegn, anførselstegn og koding
CSV har ingen enkelt formell standard, bare RFC 4180 som en mye sitert referanse. Det vanligste skilletegnet er et komma, men semikolon (vanlig i europeiske lokaliteter der komma brukes som desimalskilletegn), tabulatorer (TSV) og rørstreker forekommer alle i praksis. En fil kalt .csv kan bruke hvilken som helst av disse uten å signalisere hvilken. Når en feltverdi inneholder skilletegnet selv, krever RFC 4180 at feltet pakkes inn i doble anførselstegn: "San Francisco, CA". Et dobbelt anførselstegn inne i et felt med anførselstegn må escapes ved å doble det: "He said ""hello""". Et felt som inneholder et bokstavelig linjeskift må også siteres. Parsere som hopper over dette trinnet produserer radetellefeil som er vanskelige å spore. Koding er en separat felle. CSV-filer fra Windows-verktøy har ofte en UTF-8 BOM (byte order mark: de tre bytene EF BB BF i begynnelsen av filen). BOM-en hjelper Excel med å identifisere kodingen, men mange programmeringsspråkparsere behandler BOM-en som en del av det første kolonnenavnet, noe som produserer en kolonne kalt "\uFEFFid" i stedet for "id". Dette bryter eventuell nedstrøms kode som slår opp kolonner etter navn. Når du leser en CSV-fil programmatisk, fjern BOM-en før parsing, eller bruk et bibliotek som håndterer det eksplisitt.
Velge format: konfigurasjon, utveksling og regneark
Formatvalg bestemmes vanligvis av kontekst, ikke preferanse. JSON er standarden for REST API-er og utveksling mellom nettleser og server. Det er kompakt, nativt parset i alle programmeringsspråk og bærer typeinformasjon for tall og booleanere. Svakheten er fraværet av kommentarer, noe som gjør det uegnet for filer som utviklere leser og redigerer for hånd. YAML foretrekkes for konfigurasjonsfiler (Kubernetes-manifester, CI-pipelinedefinisjoner, Ansible-playbooks) fordi det tillater innebygde kommentarer og er lettere å lese enn JSON med mange nivåer av innrykk. Den største risikoen er at innrykksfeil er stille: en feilinnrykket nøkkel flyttes til et annet omfang uten noen parsefeil. XML er fortsatt standard i eldre bedriftssystemer, SOAP-webtjenester, dokumentformater (DOCX, SVG, RSS) og kontekster som krever skjemavalidering eller navneromsdisambiguering. Det er ordrik, men XPath- og XSLT-verktøy er modne. CSV er det riktige valget når dataene er genuint flate og forbrukeren er et regnearkprogram eller en dataanalytiker. Det er ikke egnet for konfigurasjon eller API-utveksling fordi det ikke har noe typesystem og ingen nesting.
Gjør det lokalt med data-converter
Data-converter-verktøyet på dette nettstedet parser og konverterer mellom CSV, JSON og YAML helt inne i nettleseren; det leser eller skriver ikke XML. Ingen data overføres til en server på noe tidspunkt. Konverteringen kjører i ditt lokale JavaScript-kjøretidsmiljø, og utdataene er tilgjengelige for nedlasting eller kopiering uten at noe forlater enheten din. Dette er viktig for data som ikke er dine å dele: API-responser som inneholder personlig informasjon, konfigurasjonsfiler med interne vertsnavn, eller CSV-eksporter fra interne databaser. Å lime inn disse dataene i en nettbasert konverterer som kjører på en server betyr at innholdet sendes over nettverket og behandles på maskinvare du ikke kontrollerer. Med data-converter er nettleserfanen behandlingsmiljøet. Verktøyet bruker RFC 4180-anføring ved lesing eller skriving av CSV, og forventer en flat liste av objekter for JSON eller YAML til CSV: en nestet objekt- eller matriseverdi under en nøkkel får ingen automatisk punktnotasjonsutflating, så flat ut disse feltene selv før konvertering hvis du trenger dem som separate kolonner. Hvis du trenger å flytte data til eller fra XML, konverter det til JSON eller YAML med et dedikert XML-verktøy først, og ta med resultatet hit.
Verktøy i denne artikkelen
Ofte stilte spørsmål
Kan jeg sende JSON gjennom CSV og få det opprinnelige tilbake?
Bare hvis JSON-en er en flat matrise av objekter uten nestede felt og ingen matriser som verdier. I det øyeblikket du har et nestet objekt eller en matriseverdi, krever CSV-representasjonen en strukturell beslutning (punktnotasjonskolonner, flere rader eller kodede strenger) som ikke kan reverseres automatisk. Hvis dataene dine har nesting, vil JSON, XML eller YAML konvertere rent frem og tilbake; CSV vil ikke.
Hvorfor ser CSV-en min feil ut i Excel etter eksport fra en europeisk applikasjon?
Europeiske lokaliteter bruker ofte semikolon som CSV-skilletegn fordi komma er reservert for desimalnotasjon. Excel på en europeisk lokalitet forventer semikolon. Hvis filen bruker komma, behandler Excel hele raden som én enkelt kolonne. Løsningen er enten å endre skilletegnet i eksportinnstillingene, eller å bruke Excels dataimportveiviser, som lar deg spesifisere skilletegnet manuelt. UTF-8 BOM-problemet er separat: uten en BOM kan Excel også feillesere aksenttegn som uleselig tekst.
Hva er forskjellen mellom YAML og JSON i praksis?
Begge bygger på den samme underliggende datamodellen: objekter, matriser, strenger, tall, boolske verdier og null. YAML legger til kommentarer (linjer som starter med #), flerlinjestrengsliteraler og ankerreferanser for gjentatte blokker. JSON er strengt et subsett av gyldig YAML, men JSON-parsere leser ikke YAML. Den praktiske regelen: bruk JSON for API-nyttelast og datalagring; bruk YAML for konfigurasjonsfiler som mennesker redigerer for hånd og som drar nytte av innebygde kommentarer.