YAML vs JSON: forskjeller, eksempler og når du bør bruke hva

YAML vs JSON, kort fortalt: Begge er tekstformater for de samme typene data (objekter, lister, strenger, tall, boolske verdier og null). JSON er strengt, bruker krøllparenteser og anførselstegn og er standard for web-API-er. YAML bruker innrykk, tillater kommentarer, ankere og flere dokumenter per fil, og er populært til konfigurasjon. YAML 1.2 er nesten et supersett av JSON.

Prøv gratis: YAML til JSON-konverterer Gratis å bruke, ingen konto nødvendig.

JSON (JavaScript Object Notation, definert i RFC 8259) ble laget for programmer som utveksler data. Så hva er YAML? Navnet står for «YAML Ain't Markup Language», og formatet ble laget for at mennesker skal kunne lese og redigere data for hånd. Denne veiledningen viser de samme dataene i begge formatene, sammenligner dem og går gjennom fallgruvene i hvert av dem. Vil du se hvordan en fil ser ut i det andre formatet, kan du lime den inn i den gratis YAML til JSON-konvertereren eller JSON til YAML-konvertereren.

De samme dataene i JSON og YAML

Her er en liten applikasjonskonfigurasjon i JSON:

{
  "name": "web-app",
  "version": "2.4.1",
  "replicas": 3,
  "debug": false,
  "database": {
    "host": "db.example.com",
    "port": 5432
  },
  "features": ["login", "search"],
  "maintainer": null
}

Og de samme dataene i YAML, pluss en kommentar, noe JSON ikke kan inneholde:

# Settings for the web app
name: web-app
version: 2.4.1
replicas: 3
debug: false
database:
  host: db.example.com
  port: 5432
features:
  - login
  - search
maintainer: null

Begge parses til nøyaktig det samme objektet. JSON markerer struktur med {}, [], kommaer og anførselstegn; YAML markerer den med innrykk, key: value-par og - for listeelementer. De fleste strenger i YAML trenger ingen anførselstegn i det hele tatt, og derfor leses det mer som en innstillingsfil enn som kode.

YAML vs JSON: de viktigste forskjellene

Enkelte formater godtar begge: OpenAPI-beskrivelser kan skrives i begge, og kubectl apply leser JSON-manifester så vel som YAML-manifester. Generelt vinner JSON når programmer skriver og leser dataene; YAML vinner når mennesker vedlikeholder dem for hånd og trenger kommentarer.

Er YAML et supersett av JSON?

Nesten. YAML 1.2-spesifikasjonen (2009) hadde som mål å gjøre YAML til et strengt supersett av JSON, og i praksis leser en YAML 1.2-parser nesten ethvert JSON-dokument og returnerer de samme dataene. To forbehold:

• Dupliserte nøkler. RFC 8259 sier bare at objektnøkler bør være unike, men YAML krever det, så {"a": 1, "a": 2} avvises av en streng YAML-parser.
• YAML 1.1-parsere. Mange mye brukte biblioteker følger fortsatt de eldre YAML 1.1-reglene. PyYAML gjenkjenner for eksempel bare flyttall som inneholder et punktum, så JSON-tallet 1e3 kommer tilbake som strengen "1e3".

Det motsatte gjelder ikke: Det meste av YAML er ikke gyldig JSON.

YAML-fallgruver du bør kjenne til

Norge-problemet (Norway problem): NO blir false

I YAML 1.1 er ordene yes, no, on og off uten anførselstegn (med små bokstaver, stor forbokstav eller bare store bokstaver) boolske verdier, sammen med true og false. Denne listen med landkoder

countries:
  - GB
  - NO
  - SE

lastes derfor som ["GB", false, "SE"] i en YAML 1.1-parser som PyYAML. Den samme regelen gjør on:-nøkkelen i en GitHub Actions-arbeidsflyt til den boolske verdien True når du laster filen med PyYAML. Kjerneskjemaet (core schema) i YAML 1.2 løste dette: Bare true og false (også skrevet True eller TRUE) er boolske verdier, så en 1.2-parser beholder NO som streng. Siden du sjelden styrer hvilken parser som leser filen din, er den trygge vanen å sette slike verdier i anførselstegn: - "NO".

Tall som ikke er ment å være tall

• Innledende nuller. YAML 1.1 leser 0755 som et oktaltall, 493. YAML 1.2 leser det som desimaltallet 755 og skriver oktaltall som 0o755. Et postnummer som 01234 blir 668 eller 1234, avhengig av parseren. Sett det i anførselstegn.
• Versjonsnumre. python-version: 3.10 er flyttallet 3.1, ikke «3.10». Skriv "3.10".
• Etterfølgende nuller. 1.0 er et flyttall, så det blir 1 når det konverteres til JSON i JavaScript.

Tabulatorer og meningsbærende mellomrom

YAML-spesifikasjonen forbyr tabulatortegn til innrykk, så en tabulator i starten av en linje er en syntaksfeil, ikke et stilspørsmål. Innrykk har også betydning: Flytter du en nøkkel to mellomrom til venstre, havner den i et annet overordnet objekt, og filen kan fortsatt være helt gyldig samtidig som den betyr noe annet.

Strenger over flere linjer: | og >

En literal blokk (|) beholder linjeskift; en foldet blokk (>) slår sammen linjer med mellomrom:

literal: |
  Line one
  Line two
folded: >
  This long sentence is
  folded into one line.

literal blir "Line one\nLine two\n", og folded blir "This long sentence is folded into one line.\n". Begge beholder ett avsluttende linjeskift; skriv |- eller >- for å fjerne det.

Ankere, aliaser og merge-nøkler

YAML kan definere en blokk én gang og gjenbruke den:

defaults: &defaults
  adapter: postgres
  port: 5432
production:
  <<: *defaults
  host: db.example.com

&defaults navngir blokken, *defaults refererer til den, og << fletter inn nøklene, så production ender opp med adapter, port og host. JSON har ingen tilsvarende mekanisme: Ved konvertering til JSON kopieres verdiene inn på hvert sted de brukes. Merge-nøkler kommer fra YAML 1.1 og er ikke en del av kjerneskjemaet i 1.2, men de fleste mye brukte parsere støtter dem fortsatt.

JSON-fallgruver du bør kjenne til

JSON er strengt, og tre regler står for de fleste feilene:

• Ingen kommentarer. // og /* */ er syntaksfeil.
• Ingen etterfølgende kommaer. ["a", "b",] er ugyldig.
• Bare doble anførselstegn. Nøkler må stå i anførselstegn, og enkle anførselstegn er ikke tillatt.

Denne filen feiler derfor med JSON.parse:

{
  // port for local development
  'port': 8080,
  "tags": ["api", "v2",],
}

For håndskrevne filer finnes det mer tilgivende varianter: JSONC («JSON with comments») brukes av innstillingene i VS Code og av tsconfig.json, og JSON5 tillater i tillegg enkle anførselstegn, nøkler uten anførselstegn og etterfølgende kommaer. Ingen av dem godtas av en standard JSON-parser. Verktøyet JSON-formater godtar JSON5-inndata, merker dem som «Gyldig JSON5 — konvertert til streng JSON» og gir deg standard JSON tilbake.

.yaml vs .yml

YAML vs YML er ikke et formatspørsmål: Begge filendelsene betyr det samme formatet, og parsere bryr seg ikke om hvilken du bruker. RFC 9512, som registrerte medietypen application/yaml i 2024, kaller .yaml den foretrukne endelsen og påpeker at .yml fortsatt brukes. YAML-prosjektets FAQ anbefalte også .yaml, og Docker Compose ser etter compose.yaml før compose.yml. GitHub Actions godtar begge i .github/workflows. Velg én per prosjekt, og ikke ha config.yaml og config.yml liggende side om side.

Sikkerhet: last inn YAML fra ukjente kilder på en trygg måte

Fullstendige YAML-lastere kan bygge språkspesifikke objekter ut fra tagger. I Python kan yaml.load(data, Loader=yaml.UnsafeLoader) opprette vilkårlige Python-objekter og, med en manipulert fil, kjøre kode. Bruk alltid yaml.safe_load() for filer du ikke har skrevet selv; den bygger bare vanlige dicts, lister, strenger, tall, boolske verdier og null. Siden PyYAML 6.0 nekter yaml.load() å kjøre uten en eksplisitt Loader. Vær også forsiktig med dypt nestede aliaser («billion laughs»-filer) som ekspanderer til enorme strukturer. JSON har verken tagger eller aliaser, så JSON.parse og Pythons json.loads returnerer alltid bare rene data.

Konvertere mellom YAML og JSON

Begge konvertererne kjører helt i nettleseren din og bruker yaml, et bibliotek med åpen kildekode for JavaScript.

YAML til JSON-konvertereren parser YAML 1.2, ekspanderer ankere og aliaser, bruker <<-merge-nøkler og gjør en fil med flere ----dokumenter om til en JSON-array. Du kan velge 2, 3 (standard) eller 4 mellomrom, tabulatorer eller minifisert utdata, sortere nøkler alfabetisk og laste ned resultatet som converted.json. Syntaksfeil, for eksempel en tabulator brukt til innrykk, vises med linje og kolonne. Kommentarer går tapt, fordi JSON ikke kan lagre dem.

JSON til YAML-konvertereren leser standard JSON og JSON5, så kommentarer og etterfølgende kommaer i inndataene godtas, men blir ikke med videre. Den skriver YAML med to mellomroms innrykk og har ingen innstillinger. Utdataene følger YAML 1.2: Strenger som "0755" og "true" settes i anførselstegn, men NO, yes eller on forblir uten anførselstegn fordi de er vanlige strenger i 1.2. Hvis et YAML 1.1-verktøy som PyYAML skal lese filen, må du selv sette anførselstegn rundt disse verdiene.

På kommandolinjen konverterer Mike Farahs yq begge veier, og jq validerer og formaterer JSON:

yq -o json config.yaml
yq -P -oy config.json
jq . config.json

Når du bør bruke YAML, og når du bør bruke JSON

Valget JSON vs YAML handler som regel om hvem som skriver filen:

• Bruk JSON for data som programmer utveksler: API-forespørsler og -svar, meldinger mellom tjenester, logger, lagring i nettleseren og alt som genereres av kode. Det er entydig og støttes overalt.
• Bruk YAML for konfigurasjon som mennesker redigerer og går gjennom: deploymentmanifester, CI-pipelines, Compose-filer. Kommentarer og en lettere syntaks gjør diffene lettere å lese.
• Følg verktøyet. Hvis en plattform forventer YAML (GitHub Actions) eller JSON (package.json), bruker du det formatet i stedet for å konvertere.

Hvis du velger YAML, hold det kjedelig: to mellomroms innrykk, anførselstegn rundt alt som kan leses som en boolsk verdi eller et tall, og en linter som yamllint i CI.

FAQ

Er YAML bedre enn JSON?

Ingen av dem er bedre generelt. JSON er enklere og strengere, noe som gjør det til det tryggere valget for data som utveksles mellom programmer. YAML er lettere for mennesker å lese og redigere og støtter kommentarer, og derfor bruker så mange konfigurasjonsfiler det.

Kan jeg bruke JSON i en YAML-fil?

Ja. YAMLs flytstil (flow style) bruker de samme parentesene som JSON, så ports: [80, 443] eller db: {"host": "localhost"} fungerer i en YAML-fil, og en YAML 1.2-parser godtar nesten ethvert komplett JSON-dokument. Dupliserte nøkler er det viktigste unntaket.

Kan JSON ha kommentarer?

Ikke i standard JSON: RFC 8259 har ingen kommentarsyntaks, og JSON.parse feiler på // eller /* */. Noen verktøy godtar JSONC eller JSON5, som tillater kommentarer, men du må fjerne kommentarene før du sender filen til en streng parser.

Hva er forskjellen på YAML og YML?

Innholdsmessig ingen: .yaml og .yml er to filendelser for det samme formatet. RFC 9512 oppgir .yaml som den foretrukne endelsen, men YAML-parsere bryr seg ikke om filendelsen.

Hvorfor gjør YAML NO eller on om til false eller true?

Fordi YAML 1.1 behandler yes, no, on og off som boolske verdier. YAML 1.2 behandler bare true og false som boolske verdier, men mange parsere, blant annet PyYAML, bruker fortsatt 1.1-reglene. Sett anførselstegn rundt slike verdier, for eksempel country: "NO", så leser alle parsere dem som strenger.

Prøv gratis: YAML til JSON-konverterer Gratis å bruke, ingen konto nødvendig.