Convertire tra JSON e YAML
- Dashboard
- Documentazione
- API
A cosa serve questo convertitore JSON / YAML?
Questo strumento trasforma un documento YAML in JSON e viceversa, preservando la struttura dei dati (oggetti, array, tipi scalari). La conversione JSON verso YAML, o YAML verso JSON, è un'operazione comune in sviluppo: si genera un file OpenAPI YAML a partire da una spec JSON, si converte l'output di un'API REST in YAML per committarla in un repository di configurazione, si traduce un manifest Kubernetes YAML in JSON per passarlo a kubectl --dry-run=client -o json, o si allinea un workflow GitHub Actions con uno schema JSON. Più ampiamente, è il ponte tra il mondo dello scambio di dati (JSON) e quello della configurazione modificabile a mano (YAML).
YAML vs JSON: confronto diretto
JSON e YAML rispondono a esigenze simili ma a casi d'uso diversi. La tabella seguente riassume le differenze tecniche principali, utili per scegliere tra i due a seconda del contesto.
| Criterio | JSON | YAML |
|---|---|---|
| Leggibilità umana | Media (graffe, virgolette ovunque) | Alta (indentazione, poca punteggiatura) |
| Verbosità | Più verboso | Più conciso |
| Commenti | Non supportati | Supportati (# commento) |
| Multi-documenti in un solo file | No | Sì, tramite il separatore --- |
| Anchor e alias (riutilizzo) | No | Sì (&anchor e *anchor) |
| Sistema di tipi | Stretto (string, number, bool, null, array, object) | Coercizione implicita (yes, no, null, date, scalari interpretati) |
| Performance di parsing | Molto rapida, parser nativi ovunque | Più lenta, grammatica molto più ampia |
| Adozione per le API REST | Standard di fatto | Rara |
| Adozione per la configurazione | Rara (tranne package.json, tsconfig.json) |
Standard di fatto (Kubernetes, CI/CD, Ansible) |
Quando usare JSON?
JSON si impone non appena un programma parla a un altro programma. I suoi casi d'uso tipici:
- API REST e GraphQL: payload di richiesta e risposta.
- Scambio di dati tra microservizi e code di messaggi.
- Codice JavaScript nativo:
JSON.parseeJSON.stringifysenza dipendenze. - Storage lato browser:
localStorage,sessionStorage, IndexedDB. - Richieste AJAX e
fetch. - Varianti binarie o orientate al flusso: BSON (MongoDB), JSON Lines (log, dataset ML), MessagePack.
- Configurazione di strumenti JS / TS:
package.json,tsconfig.json,composer.json.
Quando usare YAML?
YAML si impone non appena un umano modifica regolarmente il file. I suoi casi d'uso tipici:
- Docker Compose (
docker-compose.yml) e profili di stack. - Manifest Kubernetes (Deployment, Service, Ingress, Helm chart).
- Playbook Ansible e inventari.
- Pipeline CI/CD: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines.
- Specifiche OpenAPI / Swagger e AsyncAPI.
- Configurazione applicativa annotata (Symfony, Spring Boot, Rails) dove i commenti sono utili.
- File modificati frequentemente a mano, dove concisione e leggibilità contano più della velocità di parsing.
Trappole comuni in YAML
YAML è più permissivo di JSON, il che ne fa un formato potente ma infido. Le trappole più frequenti:
- Indentazione: le tabulazioni sono vietate dalla specifica, solo gli spazi sono validi. Mescolare i due o cambiare il numero di spazi in uno stesso blocco rompe il parsing.
- Coercizione automatica degli scalari:
yes,no,on,off,true,false,null,None,~sono parsati in booleani o null. Esempio trappola: un codice postale01234non quotato diventa l'intero1234, e un nome di paeseNO(Norvegia) diventafalse. Mettere sempre tra virgolette le stringhe ambigue. - Stringhe multiriga:
|(block literal) conserva i ritorni a capo così come sono, mentre>(folded) sostituisce i ritorni a capo con spazi. Gli indicatori di chomping-e+regolano il comportamento sul salto finale. - YAML 1.1 vs 1.2: la 1.1 (ancora molto diffusa, per esempio tramite PyYAML per default) tratta
yes/no/on/offcome booleani, cosa che la 1.2 ha rimosso. I comportamenti differiscono anche sui numeri in base 8. - Date implicite:
2024-01-15senza virgolette è interpretato come un oggetto data da alcuni parser, non come una stringa.
Esempi affiancati
Lo stesso documento, espresso in JSON poi in YAML. Configurazione semplice di un'applicazione con le sue dipendenze e il suo ambiente:
Versione JSON
{
"name": "cdrn-app",
"version": "1.14.2",
"environment": "production",
"dependencies": {
"php": "^8.3",
"symfony/framework-bundle": "^7.0",
"doctrine/orm": "^3.0"
},
"features": ["cache", "mailer", "queue"],
"debug": false
}
Versione YAML equivalente
# Configuration de l'application
name: cdrn-app
version: 1.14.2
environment: production
dependencies:
php: '^8.3'
symfony/framework-bundle: '^7.0'
doctrine/orm: '^3.0'
features:
- cache
- mailer
- queue
debug: false
La versione YAML è più corta di circa il 25% in caratteri, accetta un commento in testa e si legge come un elenco di proprietà senza rumore sintattico.
Come usare il convertitore
Passaggi per convertire i vostri dati:
- Incollate il vostro documento sorgente (JSON o YAML) nel campo di input.
- Selezionate il senso di conversione desiderato (JSON verso YAML, o YAML verso JSON).
- Cliccate sul pulsante di conversione: il risultato formattato appare nella zona di output.
- Verificate la resa, poi usate il pulsante di copia per recuperare il risultato negli appunti.
La conversione viene effettuata localmente nel browser o tramite una rotta server dedicata a seconda del tooling: nessun dato sensibile viene conservato.
Domande frequenti
JSON o YAML per i miei file di configurazione?
Se l'ecosistema impone un formato (Kubernetes in YAML, package.json in JSON), seguite la convenzione. Altrimenti, privilegiate YAML per configurazioni lunghe e annotate che modificate a mano, e JSON per configurazioni generate da un programma o consumate da codice. La presenza di commenti utili è spesso l'argomento decisivo a favore di YAML.
Come conservare i commenti durante un round-trip YAML verso JSON verso YAML?
Non potete. JSON non supporta i commenti: non appena si converte da YAML a JSON, i commenti vengono persi definitivamente. Per preservare i commenti durante modifiche programmatiche, usate un parser che conservi la formattazione, come ruamel.yaml in Python in modalità round-trip, o evitate completamente il passaggio attraverso JSON.
Perché il mio file YAML fa il parsing correttamente in locale ma fallisce in prod?
Cause frequenti: versioni di parser diverse (YAML 1.1 vs 1.2), tabulazioni introdotte da un editor, valori non quotati che assomigliano a booleani (NO, off) o a numeri (01234), encoding del file (UTF-8 BOM mal gestito). Quotate sistematicamente le stringhe ambigue e fissate la versione del parser nel vostro progetto.
JSON è un sottoinsieme di YAML?
Da YAML 1.2, sì in pratica: ogni documento JSON valido è un documento YAML 1.2 valido. L'inverso è falso: un documento YAML che usa commenti, anchor, date implicite o più documenti in un file non può essere espresso direttamente in JSON senza perdita di informazioni.
Quali alternative a JSON e YAML conoscere?
TOML: popolare per la config (Cargo, pyproject.toml), buon compromesso tra leggibilità e tipizzazione esplicita. INI: molto semplice, ma senza struttura nidificata standard. XML: verboso, ma resta pertinente per SOAP e alcune config Java legacy. HCL: usato da Terraform. JSON5 e JSONC: estensioni di JSON che autorizzano commenti e virgole finali.
Qual è il peso di YAML vs JSON?
A struttura equivalente, YAML è generalmente dal 15 al 30% più corto in byte, grazie all'assenza di virgolette intorno alle chiavi e alla maggior parte delle stringhe, e all'assenza di graffe. Sul wire (trasporto HTTP), JSON minificato resta comparabile, ma YAML resta più compatto in versione leggibile. Per la performance pura lato parsing, JSON è molte volte più veloce, il che giustifica il suo uso per le API ad alto traffico.
Esempio di richiesta
curl -X POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute \
-H "Content-Type: application/json" \
-d '{"json":"...","space_tabulation":1}'
Schema di input
| Campo | Tipo | Richiesto | Predefinito |
|---|---|---|---|
json |
text | ✓ | – |
space_tabulation |
integer | ✓ | – |
Endpoint
GET https://cdrn.fr/api/v1/tools- elenca tutti gli strumenti disponibiliGET https://cdrn.fr/api/v1/tools/json-yaml-converter- recupera lo schema di questo strumentoPOST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute- esegue questo strumento con un payload JSON