Artikel
Konvertera mellan CSV, XML, JSON och YAML: en praktisk guide
CSV, JSON, XML och YAML är de fyra format som utvecklare möter oftast i datapipelines, konfigurationsfiler och API:er. Konvertering mellan dem är enkel när datamodellerna stämmer överens, och förvånansvärt förstörande när de inte gör det. Den här guiden tar upp vad varje format kan och inte kan representera, var information försvinner vid konvertering och de kodningsfällor som orsakar tyst korruption. Verktyget data-converter på den här sajten hanterar tre av de fyra (CSV, JSON och YAML) helt i webbläsaren; XML-avsnitten här är bakgrund för när du flyttar data för hand eller med ett separat verktyg.
De fyra formaten och deras datamodeller
CSV organiserar data som ett platt rutnät av rader och kolumner. Den första raden namnger typiskt kolumnerna; varje efterföljande rad är en post. Det finns ingen nästling, ingen typinformation och ingen standard för något utöver vanlig text i celler. Varje värde är en sträng om inte den konsumerande applikationen tillämpar en typ. JSON modellerar data som ett träd av objekt (nyckel-värde-kartor) och arrayer. Värden kan vara strängar, tal, booleaner, null, nästlade objekt eller arrayer i valfritt djup. Detta gör att ett enda JSON-dokument kan representera en kundpost med inbäddade adressobjekt, artikelradsarrayer och typade numeriska summor. XML modellerar data som ett träd av element. Varje element kan bära namngivna attribut och innehålla underordnade element eller textinnehåll. Det finns ingen inbyggd numerisk eller boolesk typ; allt är text. Scheman som XSD kan tvinga fram typer vid valideringstillfället, men trådformatet är alltid teckendata. YAML använder indragning för att uttrycka samma objekt-och-array-modell som JSON, med renare läsbar syntax. YAML är en supermängd av JSON: ett giltigt JSON-dokument är också giltigt YAML. Det lägger till flerradiga strängar, kommentarer och ankar-alias-referenser för upprepade block. YAML är vanligt i konfigurationsfiler; JSON är vanligt i API-svar.
Förstörande konverteringar: tillplattning och XML:s tvetydighet
Den vanligaste förstörande konverteringen är att platta ut nästlad JSON eller XML till CSV. Ett JSON-objekt med ett nästlat adressfält kan inte mappas rent till en CSV-rad. Den typiska lösningen är kolumnnamn med punktnotation: customer.address.city blir sin egen kolumn. Detta fungerar för ett nästlingsnivå men går helt sönder när en array dyker upp. En kund med tre telefonnummer kräver antingen tre separata kolumner (med hårdkodad maxräkning), uppdelning i en andra CSV-fil eller kodning av arrayen som en avgränsad sträng inuti en enda cell. Inget av dessa alternativ kan tur-returneras tillbaka till ursprunglig JSON utan extra metadata. XML introducerar en separat tvetydighet: valet mellan attribut och underordnat element. Värdet Paris kan lagras som ett attribut (<city name="Paris">) eller som ett underordnat element (<city><name>Paris</name></city>). När en konverterare läser XML och producerar JSON måste den bestämma hur attribut ska mappas. Vanliga konventioner inkluderar att prefixera attributnycklar med @ eller placera dem under en "_attributes"-nyckel. Valet är inte standardiserat, vilket innebär att två konverterare som läser samma XML kan producera strukturellt olika JSON. Om du planerar att tur-returnera data genom XML och JSON, bestäm en konvention innan du börjar.
CSV-fällor: avgränsare, citering och kodning
CSV har ingen enskild formell standard, bara RFC 4180 som en ofta citerad referens. Den vanligaste avgränsaren är ett kommatecken, men semikolon (vanligt i europeiska länder där kommatecken används som decimaltecken), tabbar (TSV) och lodstreck förekommer alla i praktiken. En fil som heter .csv kan använda vilket som helst av dessa utan att signalera vilket. När ett fältvärde innehåller avgränsaren själv kräver RFC 4180 att fältet omsluts i dubbla citattecken: "San Francisco, CA". Ett dubbelt citattecken inuti ett citerat fält måste undantas genom att dubbleras: "He said ""hello""". Ett fält som innehåller ett bokstavligt radbryt måste också citeras. Tolkare som hoppar över det här steget producerar radräkningsfel som är svåra att spåra. Kodning är en separat fälla. CSV-filer från Windows-verktyg bär ofta ett UTF-8 BOM (byte order mark: de tre byten EF BB BF i början av filen). BOM hjälper Excel att identifiera kodningen, men många programspråkstolkare behandlar BOM som en del av det första kolumnnamnet och producerar en kolumn med namnet "id" istället för "id". Detta bryter all nedströms kod som slår upp kolumner efter namn. När du läser en CSV-fil programmatiskt, ta bort BOM innan du tolkar, eller använd ett bibliotek som hanterar det explicit.
Välja format: konfiguration, utbyte och kalkylblad
Formatval bestäms vanligen av sammanhanget, inte preferens. JSON är standard för REST API:er och webbläsare-till-server-utbyte. Det är kompakt, tolkas inbyggt i alla programmeringsspråk och bär typinformation för tal och booleaner. Dess svaghet är avsaknaden av kommentarer, vilket gör det olämpligt för filer som utvecklare läser och redigerar för hand. YAML föredras för konfigurationsfiler (Kubernetes-manifest, CI-pipeline-definitioner, Ansible-spelböcker) eftersom det tillåter inline-kommentarer och är lättare att läsa än JSON med många indragnivåer. Dess huvudsakliga risk är att indragningsfel är tysta: en felindragen nyckel hamnar i ett annat scope utan något tolkningsfel. XML förblir standard i äldre företagssystem, SOAP-webbtjänster, dokumentformat (DOCX, SVG, RSS) och sammanhang som kräver schemavalidering eller namnområdesprecisering. Det är verbose, men XPath- och XSLT-verktyg är mogna. CSV är rätt val när data är genuint platt och konsumenten är ett kalkylbladsprogram eller en dataanalytiker. Det lämpar sig inte för konfiguration eller API-utbyte eftersom det saknar typsystem och nästling.
Gör det lokalt med data-converter
Verktyget data-converter på den här webbplatsen tolkar och konverterar mellan CSV, JSON och YAML helt inuti webbläsaren; det läser eller skriver inte XML. Ingen data överförs till en server vid något tillfälle. Konverteringen körs i din lokala JavaScript-miljö och utdata finns tillgänglig för nedladdning eller kopiering utan att något lämnar din enhet. Detta spelar roll för data som inte är din att dela: API-svar som innehåller personlig information, konfigurationsfiler med interna värdnamn eller CSV-exporter från interna databaser. Att klistra in den datan i en webbaserad konverterare som körs på en server innebär att innehållet skickas över nätverket och bearbetas på hårdvara du inte kontrollerar. Med data-converter är webbläsarfliken bearbetningsmiljön. Verktyget tillämpar RFC 4180-citering vid läsning eller skrivning av CSV, och förväntar sig en platt array av objekt för JSON eller YAML som konverteras till CSV: ett nästlat objekt- eller array-värde under en nyckel får ingen automatisk punktnotationstillplattning, så platta till de fälten själv före konvertering om du behöver dem som separata kolumner. Om du behöver flytta data till eller från XML, konvertera den till JSON eller YAML med ett dedikerat XML-verktyg först, och ta sedan resultatet hit.
Verktyg i den här artikeln
Vanliga frågor
Kan jag tur-returnera JSON genom CSV och få tillbaka originalet?
Bara om JSON är en platt array av objekt utan nästlade fält och utan arrayer som värden. Så snart du har ett nästlat objekt eller ett arrayvärde kräver CSV-representationen ett strukturellt beslut (punktnotationskolumner, flera rader eller kodade strängar) som inte kan vändas automatiskt. Om din data har nästling kommer JSON, XML eller YAML att tur-returneras rent; CSV gör det inte.
Varför ser min CSV fel ut i Excel efter export från ett europeiskt program?
Europeiska länder använder ofta semikolon som CSV-avgränsare eftersom kommatecken är reserverade för decimalnotation. Excel på ett europeiskt språk förväntar sig semikolon. Om filen använder kommatecken behandlar Excel hela raden som en enda kolumn. Lösningen är antingen att ändra avgränsaren i exportinställningarna, eller att använda Excels dataimportguide som låter dig ange avgränsaren manuellt. UTF-8 BOM-problemet är separat: utan ett BOM kan Excel också feltolka accentuerade tecken som skräptext.
Vad är skillnaden mellan YAML och JSON i praktiken?
Båda representerar samma underliggande datamodell: objekt, arrayer, strängar, tal, booleaner och null. YAML lägger till kommentarer (rader som börjar med #), flerradiga strängbokstavliga och ankarreferenser för upprepade block. JSON är strikt en delmängd av giltig YAML, men JSON-tolkare läser inte YAML. Den praktiska regeln: använd JSON för API-nyttolaster och datalagring; använd YAML för konfigurationsfiler som människor redigerar och som drar nytta av inline-kommentarer.