JSON vs YAML — Skillnaderna förklarade

Du har säkert märkt att vissa projekt använder .json-filer för konfiguration medan andra använder .yaml eller .yml. Båda formaten representerar strukturerad data. Båda är läsbara för människor. Vad är den faktiska skillnaden, och när ska du välja det ena framför det andra?

Jag har använt båda flitigt — JSON är min dagliga driver för API:er och datautbyte, YAML är mitt förstahandsval för Kubernetes-manifest, GitHub Actions och Docker Compose. De löser liknande problem men har väldigt olika karaktär.

Sida vid sida: samma konfiguration i båda formaten

Här är ett databaskonfigurationsobjekt skrivet i JSON:

{
  "database": {
    "host": "localhost",
    "port": 5432,
    "name": "myapp",
    "ssl": true,
    "pool": {
      "min": 2,
      "max": 10
    },
    "replicas": ["replica1.db", "replica2.db"]
  }
}

Och här är samma konfiguration i YAML:

database:
  host: localhost
  port: 5432
  name: myapp
  ssl: true
  pool:
    min: 2
    max: 10
  replicas:
    - replica1.db
    - replica2.db

YAML är märkbart renare. Inga citattecken runt de flesta strängar, inga klammerparenteser, inga kommatecken. För en konfigfil som människor redigerar regelbundet adderar den tydligheten upp sig. Men YAML uppnår detta genom att vara betydligt mer komplex under huven.

Där YAML lyser

• Konfigfiler som redigeras av människor. CI/CD-pipelines (GitHub Actions, GitLab CI), Kubernetes-manifest, Docker Compose, Ansible playbooks — allt YAML. Ingen slump — det är filer som människor skriver för hand.
• Kommentarer. YAML stöder kommentarer med #. Det är enormt för konfigfiler där du vill förklara varför en inställning är som den är. JSON stöder inte kommentarer alls.
• Flerradsssträngar. YAML har block scalars för flertradigt innehåll som läses naturligt. JSON kräver \n-escape-sekvenser.
• Mindre visuellt brus. Inget krav på att citera de flesta strängar, inga avslutande parenteser, inga problem med avslutande kommatecken.
• Ankare och alias. YAML låter dig definiera ett värde en gång och referera till det på andra ställen med &anchor och *alias — smidigt för DRY-konfigfiler.

Där JSON vinner

• Strikthet. JSON har en enda giltig representation för en given datastruktur. YAML har ett dussin sätt att skriva samma sak, vilket skapar inkonsistens mellan team.
• Inga indragsfällor. JSON använder klammerparenteser och hakparenteser. YAML använder indragning, vilket innebär att ett enda felplacerat blanksteg tyst kan bryta hela din konfiguration.
• Parsningsprestanda. JSON-parsers är snabba och enkla. YAML-parsers är komplexa — YAML 1.1 har notoriskt knepiga regler för implicit typtvång.
• Universellt biblioteksstöd. Varje språk har en stridstestad, zero-dependency JSON-parser. YAML-bibliotek varierar i kvalitet och specifikationsöverensstämmelse.
• Verktyg. Linters, formatterare, schemavalidatorer — JSON-verktygen är mer mogna och allmänt tillgängliga.
• API-payloads. JSON är det universella språket för webb-API:er. Att skicka YAML över HTTP vore okonventionellt och orsaka friktion.

YAML-fallgroparna som kommer bränna dig

YAML har några genuint förvånande beteenden som orsakat riktiga produktionsincidenter. De flesta av dem kommer från de implicita typreglerna i YAML 1.1, som YAML 1.2 stramade åt. Lär dig dessa innan du förlitar dig på YAML för något kritiskt:

# YAML 1.1 implicit type coercion — all of these become booleans:
enabled: yes   # → true
disabled: no   # → false
country: NO    # → false (!)  ← the Norway Problem

# Safe practice: quote strings that look like booleans
country: "NO"
enabled: "yes"

• Oktala heltal. I YAML 1.1 tolkas 010 som 8 (oktalt), inte 10. Relevant för saker som filrättigheter.
• Tabbar vs blanksteg. YAML förbjuder tabbar för indragning. Blanda in en tabb från en kodredigerare och din fil går sönder tyst eller kastar ett kryptiskt fel.
• Implicita nullvärden. Ett tomt värde i YAML blir null. Lätt att missa när man redigerar för hand.
• String vs tal-tvetydighet. port: 8080 ger dig ett heltal. version: 1.0 kan ge ett float. Ibland vill du ha strängen "1.0". Citera alltid när det spelar roll.

Praktisk beslutsguide

Välj YAML när du:

• Skriver konfigfiler som människor redigerar direkt: CI/CD, Kubernetes, Docker Compose, Ansible
• Filen ska ha kommentarer som förklarar inställningarna
• Flerradssträngvärden är vanliga
• Ekosystemet du jobbar i redan använder YAML (kämpa inte mot konventionen)

Välj JSON när du:

• Skickar eller tar emot data via ett API
• Data genereras och konsumeras programmatiskt (ingen mänsklig redigering)
• Du behöver garanterad parskonsistens över olika verktyg och språk
• Jobbar i ett ekosystem som standardiserar på JSON: npm (package.json), VS Code (settings.json), Angular, TypeScript

Konvertera mellan de två

Behöver du konvertera YAML-konfiguration till JSON för ett verktyg som inte förstår YAML? Använd YAML till JSON-konverteraren. Vill du åt andra hållet? JSON till YAML-konverteraren löser det. YAML Formatter är också praktisk när du klistrar in YAML som blivit snett. Och om din YAML inte parsas berättar YAML Validator exakt var problemet är.

Slutsatsen

JSON och YAML kompletterar varandra — de konkurrerar inte. Använd JSON för datautbyte — API:er, programmatisk datalagring, serialisering. Använd YAML för konfigfiler som människor läser och redigerar. De flesta mogna projekt använder båda: package.json för beroenden, .github/workflows/*.yml för CI. När du förstår vad varje format är optimerat för blir valet självklart.