JSON è un sottoinsieme di YAML?

YAML 1.2 è stato esplicitamente progettato per essere un superset rigoroso di JSON, quindi qualsiasi documento JSON valido è anche YAML valido. YAML 1.1, che è ancora il default in una quantità sorprendente di strumenti (incluso il vecchio PyYAML), non lo è — analizza alcune stringhe valide JSON in modo diverso. Se hai bisogno della garanzia del superset, conferma che il tuo parser sia YAML 1.2.

Perché YAML analizza ‘no’ come false?

Le regole booleane di YAML 1.1 trattano ‘yes’, ‘no’, ‘on’, ‘off’, ‘true’, ‘false’, ‘y’, ‘n’ (e varie maiuscole) come booleani. Un elenco di paesi con ‘NO’ (codice ISO della Norvegia) diventa [false, ...]. YAML 1.2 ha risolto questo — solo ‘true’ e ‘false’ sono booleani. Se sei bloccato su un parser YAML 1.1, metti tra virgolette le stringhe ambigue.

JSON può avere commenti?

Non nello standard. RFC 8259 esclude esplicitamente i commenti. Soluzioni alternative: JSON5 e JSONC aggiungono il supporto ai commenti ma non sono interoperabili con parser JSON rigorosi, oppure includono una chiave sorella come ‘_comment’ che il codice downstream ignora. Se i commenti sono non negoziabili, usa YAML, TOML o HCL.

YAML è davvero insicuro?

I loader YAML predefiniti in alcuni linguaggi (in particolare yaml.load di Python prima del 2020, Psych di Ruby) possono istanziare classi arbitrarie dall’input, il che è un rischio di esecuzione di codice remoto se l’input è controllato da un attaccante. La correzione è usare il loader ‘safe’ (yaml.safe_load in Python, YAML.safe_load in Ruby) che emette solo tipi primitivi.

Cosa c’è di TOML o HCL?

Entrambi sono eccellenti per la configurazione. TOML è il formato che Cargo di Rust e pyproject.toml di Python usano — prevedibile, compatibile con i commenti e più difficile da leggere male di YAML. HCL è il formato di HashiCorp (Terraform). Per i nuovi progetti in cui controlli gli strumenti, TOML è spesso il migliore dei tre.

Perché i miei grandi numeri tornano sbagliati da JSON?

I numeri JSON non hanno un limite di precisione nella specifica, ma JavaScript (e molti parser JSON) li deserializza in doppi IEEE 754, che perdono precisione sopra 2^53 - 1 (circa 9,007 * 10^15). Un ID snowflake di Twitter o un ID oggetto Stripe oltre quella soglia verrà arrotondato. Codifica i grandi interi come stringhe, o usa un parser che supporti BigInt.

Guide

JSON vs YAML: scegliere il formato di configurazione giusto

Uno è verboso e prevedibile. L’altro è conciso e ha opinioni sulla Norvegia. Scegli per il motivo giusto.

By Buğra SözeriPublished May 31, 2026

JSON e YAML sembrano la stessa cosa in costumi diversi finché non provi a mantenere un file di configurazione di mille righe in entrambi. Le differenze contano, e la maggior parte di esse non riguarda la sintassi — riguarda ciò che ogni formato fa quando sei leggermente sbagliato.

Lo stesso esempio in entrambi

Il modo più breve per percepire la differenza è leggere dati identici fianco a fianco.

JSON

{
  "name": "convertitive",
  "version": "1.4.0",
  "ports": [80, 443],
  "features": {
    "darkMode": true,
    "telemetry": false
  },
  "owners": ["[email protected]", "[email protected]"]
}

YAML

name: convertitive
version: 1.4.0
ports:
  - 80
  - 443
features:
  darkMode: true
  telemetry: false
owners:
  - [email protected]
  - [email protected]

Il YAML è circa il 30% più breve e probabilmente più leggibile per un essere umano che non ne ha mai visto nessuno dei due prima. Il JSON è inequivocabile per una macchina, compatibile con i parser, e sopravvive al copia-incolla attraverso qualsiasi editor di testo su qualsiasi sistema operativo senza danni da caratteri invisibili.

Dove YAML vince

Commenti

YAML supporta # commenti di rigaovunque. JSON non lo fa — RFC 8259 li esclude deliberatamente. Per un file di configurazione che gli esseri umani leggeranno e modificheranno, i commenti non sono un optional; sono come si documenta perché un flag è disattivato o quale intervallo di valori un’impostazione accetta effettivamente.

Stringhe multiriga

YAML ha due stili di scalare a blocchi per le stringhe multiriga. | preserva le newline, > le piega in spazi. Entrambi ti permettono di scrivere valori della lunghezza di un paragrafo senza il caos dei caratteri di escape.

Ancore e alias

YAML ti permette di etichettare un nodo con & e di riferirlo altrove con *. Le chiavi di merge (<<) estendono un mapping con un altro. Il risultato è un vero DRY in un file di configurazione.

Scansionabilità visiva

L’indentazione come struttura è il singolo motivo principale per cui i team scelgono YAML. Un documento profondamente annidato si legge dall’alto in basso; non perdi il filo contando le parentesi graffe. Ecco perché ogni manifest Kubernetes è YAML e ogni playbook Ansible è YAML.

Dove JSON vince

Parsing inequivocabile

JSON ha una grammatica di cinque pagine. Due parser corretti concorderanno su ogni documento. YAML ha una grammatica di novanta pagine con multiple interpretazioni valide dello stesso documento a seconda della versione del parser. La rigidità di JSON è la caratteristica.

Ubiquità degli strumenti

Ogni linguaggio include un parser JSON nella sua libreria standard. YAML richiede una dipendenza di terze parti nella maggior parte degli ambienti — PyYAML, js-yaml, snakeyaml, go-yaml. Per un file di configurazione incorporato in uno strumento che deve funzionare ovunque, la storia senza dipendenze di JSON conta.

Il problema della Norvegia — letteralmente

L’errore più famoso di YAML: in YAML 1.1, la stringa NO viene analizzata come il booleano false. Gli elenchi di paesi che includono il codice ISO della Norvegia (NO) diventano [false, ...] a meno che non siano tra virgolette. Lo stesso accade con YES, ON, OFF e varie capitalizzazioni. YAML 1.2 risolve questo trattando solo true e false minuscoli come booleani, ma una quantità sorprendente di strumenti usa per impostazione predefinita la 1.1 nel 2026.

Sicurezza predefinita

La specifica YAML include tag di tipo che permettono a un documento di istruire il parser a istanziare classi arbitrarie. Diversi binding linguistici l’hanno onorato per impostazione predefinita per anni, il che significa che il caricamento di un documento YAML controllato da un attaccante potrebbe eseguire codice arbitrario. La correzione è usare un loader “safe” (yaml.safe_load in Python, YAML.safe_load in Ruby) che emette solo tipi primitivi.

Insidie condivise

Precisione numerica JSON

La specifica JSON dice che i numeri possono avere magnitudine e precisione arbitrarie. JSON.parse di JavaScript e la maggior parte delle implementazioni non-JS li deserializzano effettivamente in doppi IEEE 754, che possono rappresentare gli interi esattamente solo fino a 2^53 - 1 (circa 9,007 * 10^15). Un ID snowflake di Twitter, un ID di addebito Stripe o qualsiasi intero a 19 cifre verrà arrotondato silenziosamente. La correzione è codificare i grandi interi come stringhe o usare un parser con supporto BigInt.

Un albero decisionale

Per i nuovi progetti in cui controlli il consumer:

Formato wire da macchina a macchina? Usa JSON. Ogni linguaggio lo analizza, i commenti non contano, e la rigidità elimina un’intera classe di bug di integrazione.
Configurazione modificata da esseri umani sotto le 100 righe? Usa YAML se il consumer si aspetta YAML, TOML altrimenti. Entrambi supportano i commenti; TOML è meno sorprendente.
Configurazione modificata da esseri umani oltre le 100 righe, profondamente annidata? Le ancore e gli scalari a blocchi di YAML iniziano a pagare a quella dimensione. Fissa a YAML 1.2 nella documentazione.
Input non affidabile? JSON è più sicuro per impostazione predefinita. Se devi accettare YAML, usa il loader safe e uno schema.
Il consumer è fisso (Kubernetes, npm)? Corrisponde al consumer. Non combattere l’ecosistema.

Conversione tra i due

La conversione è meccanica perché YAML 1.2 è un superset JSON. JSON in, YAML fuori è sempre senza perdita. YAML in, JSON fuori è senza perdita solo se il YAML usa tipi primitivi e nessuna ancora/alias che richiederebbe espansione.

Il nostro convertitore JSON ↔ YAML gestisce entrambe le direzioni nel browser e ti mostra la riga in cui l’analisi fallisce se l’input non è valido. Per il lavoro JSON puro — formattazione, validazione, minimizzazione — il formattatore JSON è uno strumento più preciso.

Il punto fermo onesto

JSON è il default giusto per qualsiasi cosa su cui due programmi devono concordare. YAML è il default giusto per qualsiasi cosa che un essere umano modificherà a lungo. La maggior parte dei sistemi in produzione finisce con entrambi: YAML al confine umano (chart Helm, workflow GitHub Actions, configurazione dell’applicazione), JSON sul filo e a riposo nei database.

La risposta sbagliata è scegliere qualunque formato hai visto per primo e usarlo per tutto. JSON per una configurazione di mille righe senza commenti è ostile. YAML per un corpo di risposta HTTP invita ogni insidia in questo articolo. Abbina il formato al consumer e all’editor, e rileggi la storia della Norvegia una volta al trimestre per rimanere paranoico.

Frequently asked questions

JSON è un sottoinsieme di YAML?: YAML 1.2 è stato esplicitamente progettato per essere un superset rigoroso di JSON, quindi qualsiasi documento JSON valido è anche YAML valido. YAML 1.1, che è ancora il default in una quantità sorprendente di strumenti (incluso il vecchio PyYAML), non lo è — analizza alcune stringhe valide JSON in modo diverso. Se hai bisogno della garanzia del superset, conferma che il tuo parser sia YAML 1.2.
Perché YAML analizza ‘no’ come false?: Le regole booleane di YAML 1.1 trattano ‘yes’, ‘no’, ‘on’, ‘off’, ‘true’, ‘false’, ‘y’, ‘n’ (e varie maiuscole) come booleani. Un elenco di paesi con ‘NO’ (codice ISO della Norvegia) diventa [false, ...]. YAML 1.2 ha risolto questo — solo ‘true’ e ‘false’ sono booleani. Se sei bloccato su un parser YAML 1.1, metti tra virgolette le stringhe ambigue.
JSON può avere commenti?: Non nello standard. RFC 8259 esclude esplicitamente i commenti. Soluzioni alternative: JSON5 e JSONC aggiungono il supporto ai commenti ma non sono interoperabili con parser JSON rigorosi, oppure includono una chiave sorella come ‘_comment’ che il codice downstream ignora. Se i commenti sono non negoziabili, usa YAML, TOML o HCL.
YAML è davvero insicuro?: I loader YAML predefiniti in alcuni linguaggi (in particolare yaml.load di Python prima del 2020, Psych di Ruby) possono istanziare classi arbitrarie dall’input, il che è un rischio di esecuzione di codice remoto se l’input è controllato da un attaccante. La correzione è usare il loader ‘safe’ (yaml.safe_load in Python, YAML.safe_load in Ruby) che emette solo tipi primitivi.
Cosa c’è di TOML o HCL?: Entrambi sono eccellenti per la configurazione. TOML è il formato che Cargo di Rust e pyproject.toml di Python usano — prevedibile, compatibile con i commenti e più difficile da leggere male di YAML. HCL è il formato di HashiCorp (Terraform). Per i nuovi progetti in cui controlli gli strumenti, TOML è spesso il migliore dei tre.
Perché i miei grandi numeri tornano sbagliati da JSON?: I numeri JSON non hanno un limite di precisione nella specifica, ma JavaScript (e molti parser JSON) li deserializza in doppi IEEE 754, che perdono precisione sopra 2^53 - 1 (circa 9,007 * 10^15). Un ID snowflake di Twitter o un ID oggetto Stripe oltre quella soglia verrà arrotondato. Codifica i grandi interi come stringhe, o usa un parser che supporti BigInt.

Published May 31, 2026