Det korta svaret: JSON är det säkrare valet för datautbyte mellan maskiner, medan YAML är säkrare för konfigurationer som redigeras manuellt. Allt kokar ner till ett designbeslut: var formaten placerar sin struktur. JSON fäster byggställningen på utsidan med klamrar och parenteser som syns. YAML gömmer den inuti väggarna med hjälp av blanksteg som inte syns. Båda är format för serialisering av data som utför samma uppgift, vilket är anledningen till att valet ofta görs av gammal vana snarare än medvetet, och varför så många team till slut underhåller båda. Så här fattar du beslutet.
JSON står för JavaScript Object Notation och, som namnet antyder, härstammar det från JavaScript-dataformat. Det är en öppen standard: lättviktig, textbaserad och med en medvetet begränsad uppsättning datatyper. Kort syntax, enkel struktur och mycket lättläst.
Det används för att skicka data till en server och tillbaka till klienten, som ett kuvert som håller datan när den skickas mellan parter. Programmerare använder det i mobilappar, i dokumentdatabaser som MongoDB (som lagrar ett binärt, JSON-liknande format som kallas BSON), i meddelandeköer och loggpipelines, samt i användarvända REST-API:er som ett smidigare alternativ till XML. Det är standardformatet för nyttolast i REST-API:er, och alla webbläsare tolkar det inbyggt.
Enligt JSON-utvecklaren Douglas Crockford användes ett språk med samma principer redan på Netscape 1996, men JSON etablerades som en vanlig syntax först omkring 2001. Det är språkoberoende, så det fungerar med alla programmeringsspråk, och den portabiliteten är den främsta anledningen till att det spreds som det gjorde.
En .json -fil är en ren textfil som innehåller ett enskilt JSON-dokument, sparad med filändelsen .json och läsbar i alla textredigerare. Den använder en kort lista med datatyper: strängar, tal, objekt, arrayer, booleska värden och null. Syntaxen lånar konventioner som är bekanta för programmerare av C-familjens språk: C, C++, C#, Java, JavaScript, Perl, Python och så vidare. Som den officiella JSON-webbplatsen uttrycker det är ett objekt en oordnad uppsättning namn/värde-par som börjar med en vänsterklammer och slutar med en högerklammer, där varje namn följs av ett kolon och paren separeras med kommatecken.
Den fungerande grammatiken får plats på den där enda sidan på json.org: inte en sammanfattning av specifikationen, utan själva specifikationen. Formatet är också formellt standardiserat som ECMA-404 (2:a utgåvan, 2017) och IETF RFC 8259 (2017), men grammatiken som dessa dokument fastställer är densamma kompakta. Kom ihåg det när YAML-specifikationen dyker upp senare.
Samma data, först i JSON, med information om heavy metal-bandet Metallica:
{
"band": "Metallica",
"formed": 1981,
"origin": "Los Angeles, California",
"genres": ["thrash metal", "heavy metal"],
"active": true,
"members": [
{ "name": "James Hetfield", "role": "vocals, rhythm guitar", "joined": 1981 },
{ "name": "Lars Ulrich", "role": "drums", "joined": 1981 },
{ "name": "Kirk Hammett", "role": "lead guitar", "joined": 1983 },
{ "name": "Robert Trujillo", "role": "bass", "joined": 2003 }
],
"disbanded": null
}Klammerparenteser avgränsar objektet och arrayerna; varje post omges av citattecken; ett kolon separerar varje namn från dess värde, och ett kommatecken separerar paren från varandra. All struktur finns där på utsidan så att du enkelt kan räkna den.
Det fungerar eftersom syntaxen är kompakt och läsbar för människor, uppmärkningen är minimal, parsning går snabbt i alla språk och stödet är i princip universellt.
Det brister på tre punkter. Datatyperna stannar vid strängar, tal, objekt, arrayer, booleska värden och null, så allt mer komplext måste kodas som en sträng och avkodas manuellt i andra änden. Det finns inget stöd för namnrymder, kommentarer eller attribut, och avsaknaden av kommentarer är något man märker i en konfigurationsfil. Dessutom är strukturen medvetet enkel, vilket gör att komplex konfiguration tenderar att bygga på egna konventioner ovanpå den.
YAML stod tidigare för Yet Another Markup Language, tills betydelsen ändrades till YAML Ain't Markup Language för att lägga betoningen på data snarare än dokument. Det är ett mycket lättläst och lättviktigt format som oftast används för att lagra konfigurationer för DevOps-verktyg som Elasticsearch, Docker, Kubernetes, Prometheus och Ansible.
Som den officiella webbplatsen, som själv är skriven i YAML, uttrycker det: YAML är ett användarvänligt dataserialiseringsspråk för alla programmeringsspråk. Det är ett dataserialiseringsspråk, även om det lika ofta används för konfigurationsfiler. Vi kommer att betrakta det ur ett dataserialiseringsperspektiv.
YAML presenterades första gången 2001. Grundarna är Ingy dot Net, Clark Evans och Oren Ben-Kiki, som gick samman för att skapa något enklare än XML. Sedan dess har det blivit standardformatet för konfiguration i nästan hela DevOps-verktygskedjan, vilket innebär att valet ofta redan är gjort åt dig när du börjar.
En YAML-fil är en ren textfil som sparas som .yaml eller .yml, och som innehåller ett eller flera YAML-dokument. En fil kan innehålla flera dokument separerade av en rad med tre bindestreck, vilket är hur ett Kubernetes-manifest buntar ihop en deployment och en tjänst. Det har stöd för kommentarer, vilket i sig gör det smidigt att redigera.
YAML är en superset av JSON: alla giltiga JSON-dokument är även giltig YAML, så en YAML-fil kan innehålla JSON-objekt och en YAML-tolk läser en .json -fil utan ändringar. Det hanterar komplexa datatyper utan problem och kan nästla objekt så djupt du vill. Samma flexibilitet är anledningen till att vissa system begränsar vilka YAML-funktioner de accepterar.
#).|) behåller radbrytningar, medan större än-tecknet (>) slår ihop dem till en enda rad.Samma data igen, nu i YAML:
band: Metallica
formed: 1981
origin: Los Angeles, California
genres:
- thrash metal
- heavy metal
active: true
members:
- name: James Hetfield
role: vocals, rhythm guitar
joined: 1981
- name: Lars Ulrich
role: drums
joined: 1981
- name: Kirk Hammett
role: lead guitar
joined: 1983
- name: Robert Trujillo
role: bass
joined: 2003
disbanded: nullTre skillnader märks direkt. Klamrar och parenteser är borta, och indentering anger hierarkin. Citationstecknen är också borta, eftersom YAML härleder typen från värdet. Och medlemmarna är en sekvens av bindestreck istället för en kommaseparerad array, så att lägga till en femte innebär ett nytt block snarare än en ändring av skiljetecknen runt omkring.
Snyggare, ja. Men titta igen på var strukturen hamnade. I JSON-versionen är den uttrycklig. I YAML-versionen härleds den från blanksteg, ett helt annat löfte.
Det fungerar eftersom syntaxen är lättläst, indentering anger struktur utan skiljetecken, kommentarer stöds, komplexa strukturer kan uttryckas och ankare gör att ett block kan återanvändas istället för att kopieras. Den återanvändningen är en anledning till att YAML används för att beskriva infrastruktur, till exempel Kubernetes-stackar, där samma inställningar återkommer i dussintals objekt.
Det brister precis där flexibiliteten finns. Felaktig indragning eller blanksteg genererar valideringsfel, eller ännu värre, en fil som tolkas korrekt men till något du inte avsåg. Dess deklarativa natur gör felsökning svårare: det finns inget att stega igenom, så felet uppstår först när filen tolkas eller tillämpas. Och typinferens har sina fällor, där den mest kända är landskoden för Norge, NO, som läses som det booleska värdet false om du inte sätter det inom citattecken. Strikt talat hör det beteendet till YAML 1.1: den nuvarande specifikationen, YAML 1.2, revision 1.2.2 (oktober 2021), begränsar booleska värden till endast true och false. Fällan lever kvar i praktiken eftersom en stor mängd tolkar fortfarande använder 1.1-semantik som standard, så i praktiken sätter du citattecken runt NO och går vidare.
YAML och JSON är två populära format som liknar varandra i struktur och användbarhet. Deras skillnader i design, syntax och funktionalitet gör att valet mellan dem beror på syftet.
| Funktion | JSON | YAML |
|---|---|---|
| Syntax | Måsvingar, hakparenteser, citattecken och kommatecken | Indrag, kolon och bindestreck |
| Kommentarer | Stöds ej | Stöds med # |
| Datatyper | Strängar, tal, objekt, matriser, boolean, null | Detsamma, samt datum och tidsstämplar |
| Tolkningshastighet | Snabbare: en liten, entydig grammatik | Långsammare: en betydligt större specifikation |
| Mänsklig läsbarhet | Bra, när man väl ser förbi skiljetecknen | Bättre för manuell redigering, svårare för att överblicka struktur |
| Återanvändning | Ingen | Ankare och alias |
| Verktygsstöd | Inbyggt i webbläsare och nästan alla standardbibliotek | Kräver ett externt bibliotek i de flesta språk |
| Typisk användning | API:er, datautbyte, maskingenererade filer | Konfigurationsfiler, CI-pipeliner, infrastruktur |
En grundläggande skillnad ligger till grund för allt detta. JSON utformades för att maskiner ska kunna skriva och läsa det, så det anger sin struktur tydligt och lämnar inget utrymme för feltolkningar av en parser. YAML utformades för människor, så det flyttar strukturen till blanksteg, vilket gör att filen ser ut som en disposition snarare än kod.
Skillnaden i parsning beror på specifikationerna, inte på några prestandatester. JSON-grammatiken ryms på en enda sida på json.org. YAML 1.2-specifikationen omfattar dussintals sidor som täcker ankare, taggar, blockskalärer, flera dokument och implicit typning: mer arbete för parsern och fler sätt för den att göra fel. Betrakta hastighetsskillnaden som en skillnad i karaktär snarare än ett mätvärde: irrelevant för en fil som läses en gång vid uppstart, men mätbar för en tjänst som deserialiserar data hela dagen.
Det är också därför de felar på olika sätt. En felaktig JSON-fil orsakar oftast ett tydligt och omedelbart avbrott i parsningen. En felaktig YAML-fil parsas ofta utan problem men får en helt annan innebörd, eftersom ett indrag flyttat en nyckel under fel förälder, eller för att ett värde utan citattecken tolkats som fel datatyp. Tysta fel är de som kostar mest.
Inget av dem, rent abstrakt. Frågan får sitt svar först när du vet vad uppgiften är, så låt funktionen styra: vad behöver du formatet till?
JSON är det bättre valet för datautbyte. Det går snabbt att tolka, stöds överallt utan beroenden och varje objekt är tydligt avgränsat, vilket förhindrar att en tolk läser strukturen fel. Nackdelen är det begränsade urvalet av datatyper, vilket gör att mer komplexa värden måste kodas som strängar och avkodas vid behov. Om du designar sådana utbyten, väger vår jämförelse av GraphQL vs REST de två dominerande API-stilarna mot varandra.
YAML är det bättre valet för konfigurationer som underhålls av människor. Det tillåter kommentarer, kan nästlas djupt utan att det blir en röra av skiljetecken, och ankare gör att delade inställningar bara behöver skrivas en gång. Nackdelen är att strukturen bygger på blanksteg, vilket innebär att en fil kan vara korrekt formaterad men ändå innehålla fel, och att tolken har mer arbete att utföra.
Kort sagt: om ett program skriver filen, använd JSON. Om en människa skriver filen, använd YAML och lägg till en validerare framför.
Den här uppdelningen är inte abstrakt för oss. När vi flyttade FlippedNormals, en marknadsplats för datorgrafik som vuxit ur WordPress, från Heroku till AWS, var utlösaren precis den avvägning som nämns ovan: Herokus hanterade dynos gav oss liten kontroll över skalningen i takt med att katalogen växte, så vi migrerade plattformen till AWS och slutförde den första etappen på två månader, parallellt med en databasflytt från MySQL till PostgreSQL. En infrastrukturmigrering av det slaget är där YAML-halvan av den här artikeln slutar vara teori: driftsättningen beskrivs, granskas och versionshanteras i konfigurationsfiler som redigeras manuellt.
JSON-halvan dök upp i samma miljö, i de nyttolaster som marknadsplatsens tjänster skickade mellan varandra: maskinskrivna, lästa tusentals gånger, aldrig redigerade för hand. Samma system, båda formaten, där varje format gör det det är bäst på.
För de flesta team är detta inte ett estetiskt beslut. Notan landar på fem områden.
Konfigurationsfel som når produktion. YAML:s känslighet för blanksteg och typinferens innebär att en fil kan vara giltig men ändå felaktig. Ingen parser fångar den typen av fel: det krävs en schemakontroll, eller att driftsättningen misslyckas klockan tre på eftermiddagen. Alla arkiv där YAML styr infrastrukturen behöver schemavalidering och en formaterare i kontinuerlig integration, och det kräver ingenjörstid att sätta upp och underhålla.
Säkerhet vid parsning. YAML:s fullständiga inläsare kan skapa godtyckliga objekt från ett dokument, vilket i tysthet förvandlar en begäran om att tolka en fil till en licens att köra vad filen än beskriver, så fort indatan inte är betrodd. Det är därför bibliotek exponerar en säker inläsning, där PyYAML:s safe_load är det mest kända, och varför det bör vara standard i alla kodbaser som läser YAML som de inte själva skapat. JSON har ingen motsvarande sårbarhet, eftersom formatet inte kan beskriva en typ som ska instansieras.
Introduktionstid. JSON är bekant för alla som har använt ett API. YAML har ankare, alias, blockskalärer och flera dokument per fil, och en nyanställd möter allt detta under sin första vecka i en Kubernetes-miljö. Budgetera för upplärning, eller standardisera på en dokumenterad delmängd och skriv ner det.
Parsningskostnad i stor skala. För en konfigurationsfil som läses en gång vid uppstart är parsningstiden oväsentlig. För en tjänst som deserialiserar tusentals nyttolaster i sekunden är den inte det, och den mindre JSON-grammatiken är billigare att bearbeta.
Miljöer med blandade format. Det dyra resultatet är inget av formaten i sig. Det är kombinationen: konfiguration i YAML, fixturer i JSON, ett konverteringslager inklämt däremellan, och två uppsättningar valideringsregler som driver isär under arton månader. Välj ett format per syfte, skriv ner beslutet och validera varje del med ett schema: JSON Schema för JSON-sidan och ett av YAML-schemaverktygen för den andra.
Fyra frågor vi går igenom innan vi bestämmer oss för ett serialiseringsformat för ett projekt.
Oftast pekar svaren inte på ett enda format för hela systemet. På de flesta plattformar vi bygger hamnar uppdelningen på samma ställe: YAML för det människor underhåller, pipelines, manifest och miljökonfiguration, och JSON för det tjänster skickar mellan varandra. Det misstag vi ser oftast är inte att man väljer fel format, utan att man låter båda sprida sig till samma uppgift utan att någon bestämmer vad som hör hemma var.
Nej. JSON parsas snabbare eftersom dess grammatik är begränsad till en enda sida och inte tillåter någon tvetydighet, medan YAML-specifikationen är betydligt mer omfattande och kräver typinferens. Skillnaden är försumbar för en konfigurationsfil som läses in en gång vid uppstart, men den spelar roll för en tjänst som kontinuerligt parsar nyttolaster.
Ja. YAML är en övermängd av JSON, så alla giltiga JSON-dokument är även giltiga YAML-dokument, och en YAML-parser läser en .json -fil utan ändringar. Det omvända gäller inte: en JSON-parser kan inte läsa YAML.
.json -fil?En vanlig textfil som innehåller ett enskilt JSON-dokument och som sparats med filändelsen .json . Den innehåller ett objekt eller en array i roten, använder citattecken för nycklar och värden, och kan öppnas i vilken textredigerare som helst.
En vanlig textfil som sparats som .yaml eller .yml och som innehåller ett eller flera YAML-dokument. Den använder indrag istället för klammerparenteser, har stöd för kommentarer och är standardformatet för konfiguration i verktyg som Kubernetes, Docker Compose och Ansible.
YAML, eftersom det är vad ekosystemet är skrivet i, och manifest redigeras och granskas av människor. Kubernetes accepterar JSON-motsvarigheten, men varje exempel, handledning och genererat manifest du stöter på kommer att vara i YAML.
I alla arkiv där fler än en person redigerar YAML, ja. En formaterare tillsammans med en linter i CI fångar upp indenterings- och typinferensfel som en parser glatt accepterar men som ett kluster senare avvisar.
Endast med en säker inläsare (safe loader). Den fullständiga inläsaren kan instansiera godtyckliga objekt som beskrivs i dokumentet, så att parsa en otillförlitlig fil kan köra kod. Använd den säkra varianten som ditt bibliotek tillhandahåller, till exempel PyYAML:s safe_load, närhelst filen inte kommer från ditt eget arkiv.
Närhelst ett program skriver eller läser filen istället för en människa: API-nyttolaster, meddelandeköer, loggrader, testfixturer, webbläsarlagring. Välj YAML när en människa underhåller filen och behöver kommentarer och struktur som är lätt att överblicka.
Ja, och de flesta YAML-bibliotek gör det med en enda kodrad. Att konvertera YAML till JSON innebär att kommentarer och ankare går förlorade, så betrakta YAML som källan och JSON som den genererade artefakten, aldrig tvärtom.
Att välja ett serialiseringsformat är ett litet beslut med långsiktiga konsekvenser, och oftast den minst intressanta delen av en mycket större arkitekturfråga. Om du väger hur dina tjänster ska utbyta och lagra data, så hjälper vårt teknikteam dig gärna att gå igenom det.
Innehållsförfattare och digital medieproducent med intresse för det symbiotiska förhållandet mellan teknik och samhälle. Böcker, musik, och gitarrer är en konstant.
Alexandra Mendes är Senior Growth Specialist på Imaginary Cloud med 3+ års erfarenhet av att skriva om mjukvaruutveckling, AI och digital transformation. Efter att ha avslutat en frontend-utvecklingskurs tog Alexandra upp några praktiska kodningskunskaper och arbetar nu nära med tekniska team. Alexandra brinner för hur ny teknik formar affärer och samhälle och tycker om att förvandla komplexa ämnen till tydligt och användbart innehåll för beslutsfattare.
People who read this post, also found these interesting:
.webp)
