Convertitore JSON in YAML

Come funziona

1. Incolla JSON: inserisci qualsiasi JSON valido, da coppie chiave-valore piatte a oggetti e array profondamente annidati.
2. Conversione istantanea: lo strumento trasforma il JSON in YAML con un'indentazione corretta, rimuove le virgolette dalle chiavi stringa e traduce i tipi null, booleano e numerico.
3. Configura l'output: definisci la larghezza di indentazione (2 o 4 spazi) e scegli tra lo stile blocco o flusso per le collezioni.
4. Copia lo YAML: il risultato è pronto da incollare in file di configurazione, pipeline CI/CD o manifest Kubernetes.

Perché convertire JSON in YAML?

Lo YAML è il formato di configurazione preferito per gli strumenti di infrastruttura come Kubernetes, Docker Compose, GitHub Actions, Ansible e i chart Helm, più leggibile del JSON, supporta i commenti e non richiede virgolette attorno a ogni stringa. Convertire risposte API, sezioni di package.json o strutture di dati da JSON a YAML è un compito frequente in DevOps e nello sviluppo back-end. La struttura basata sull'indentazione dello YAML è più leggibile per gli umani, mentre il JSON è preferito per le API e la generazione programmatica, questo convertitore fa da ponte tra i due.

Corrispondenza dei tipi

• Stringhe → senza virgolette se possibile, tra virgolette se contengono caratteri speciali
• Numeri → scalari numerici YAML così come sono
• Booleani → true / false in YAML
• null → null o ~ in YAML
• Array → sequenze a blocchi YAML con prefisso -
• Oggetti → mapping YAML con coppie chiave: valore

Cos'è la conversione JSON a YAML?

La conversione JSON a YAML traduce un albero di coppie chiave-valore da un formato di serializzazione a un altro preservando i dati sottostanti. Entrambi i formati descrivono la stessa forma di dati (stringhe, numeri, booleani, null, array, oggetti), ma JSON usa parentesi graffe e quadre mentre YAML usa indentazione e trattini. La stessa configurazione name: app, version: 1, ports: 80, 443 può essere espressa in uno o nell'altro, e i convertitori si muovono tra loro senza perdere significato.

JSON, inventato da Douglas Crockford intorno al 2001 e standardizzato come RFC 4627 nel 2006 e ECMA-404 nel 2013, è la lingua franca delle API web. YAML 1.0 (2001), 1.1 (2005) e 1.2 (2009) di Clark Evans, Ingy doet Net e Oren Ben-Kiki è stato progettato come superinsieme di JSON ottimizzato per la leggibilità umana, con supporto per commenti, stringhe multi-riga, ancore e alias. Il tooling DevOps moderno (Kubernetes, Docker Compose, GitHub Actions, Ansible, Helm) è di default YAML perché le config sono scritte e revisionate dagli umani.

Questo convertitore appaia entrambi i formati fianco a fianco. Incolla JSON a sinistra, clicca JSON a YAML e il pannello destro si aggiorna con YAML valido alla tua profondità di indentazione scelta (2 o 4 spazi). Il pulsante inverso esegue lo stesso processo all'indietro. La conversione usa la libreria js-yaml (Vitaly Puzrin, 2011) caricata da jsDelivr, che implementa la specifica YAML 1.2 abbastanza accuratamente da fare round-trip su manifest Kubernetes, chart Helm e spec OpenAPI.

Cosa c'è dentro il convertitore

L'interfaccia usa un layout a griglia a due pannelli: JSON a sinistra, YAML a destra. Su schermi più stretti di 768 pixel il layout si impila verticalmente. Sopra i pannelli, un selettore di indentazione ti permette di scegliere 2 o 4 spazi per livello. La scelta attiva è evidenziata e l'indentazione si applica a entrambe le direzioni di conversione.

Ogni pannello ha i propri pulsanti di azione. Il pannello JSON offre JSON a YAML (convert) e Clear. Il pannello YAML offre YAML a JSON (reverse), Copy (clipboard) e Download .yaml (salva come file con estensione .yaml e codifica UTF-8). Il banner di errore sotto il convertitore mostra errori di parsing con il numero di riga e un messaggio breve, così puoi correggere input non validi senza lasciare lo strumento.

Sotto il cofano, la conversione JSON a YAML usa JSON.parse più la funzione dump di js-yaml. La direzione YAML a JSON usa la funzione load di js-yaml più JSON.stringify con indent di 2 spazi. Entrambe le direzioni sono funzioni pure dell'input, nessuno stato viene portato tra conversioni e ricaricare la pagina ripristina tutto.

Storia e contesto

Douglas Crockford specifica JSON (2001)

Douglas Crockford documentò la sintassi JSON in aprile 2001 mentre era a State Software, dopo aver realizzato che la sintassi degli oggetti letterali JavaScript poteva servire come formato dati indipendente dal linguaggio. La spec era deliberatamente minima: sei tipi, due collezioni, nessun commento, nessuno schema. RFC 4627 seguì nel 2006 e ECMA-404 nel 2013. Il minimalismo è esattamente ciò che ha reso JSON ubiquo sul web.

YAML 1.0 pubblicato (2001)

Clark Evans, Ingy doet Net e Oren Ben-Kiki rilasciarono YAML 1.0 nel maggio 2001, lo stesso anno di JSON. L'acronimo era originariamente Yet Another Markup Language ma è stato retconnato a YAML Ain't Markup Language per chiarire che YAML mira ai dati di configurazione, non al markup di documenti. La spec 1.0 era ambiziosa, supportando ancore, alias, stream multi-documento, tag personalizzati e commenti.

YAML 1.1 e il problema della Norvegia (2005)

YAML 1.1 (gennaio 2005) ha stretto la spec ma ha mantenuto il famoso comportamento di coercizione booleana dove le stringhe yes, no, on, off, y, n, true, false, più le loro varianti capitalizzate, diventano tutte booleane. Questo è il Problema Norvegia: il codice paese ISO non quotato NO diventa il booleano false. Il bug ha morso i primi utenti Kubernetes finché YAML 1.2 (2009) non ha rimosso le ortografie booleane alternative.

YAML 1.2 dichiara JSON come sottoinsieme (2009)

YAML 1.2 (ottobre 2009) ha esplicitamente fatto di JSON un sottoinsieme stretto di YAML, quindi qualsiasi documento JSON valido è anche un documento YAML valido. Questa è stata una grande vittoria di design: gli strumenti che gestivano YAML 1.2 potevano parsare JSON gratis, semplificando l'implementazione di convertitori e validatori. La versione ancora in uso nella maggior parte del tooling oggi è 1.2 o un profilo compatibile con 1.1.

Kubernetes spedisce manifest YAML (2015)

Kubernetes 1.0, rilasciato da Google nel luglio 2015, ha definito le risorse cluster (Pod, Deployment, Service) usando manifest YAML. La scelta è stata guidata dalla leggibilità per i team ops abituati a editor di testo e controllo versione. Helm (2016) ha aggiunto il templating in cima, GitHub Actions (2018) ha adottato YAML per i workflow e i playbook Ansible (2012-2018) hanno cementato YAML come il linguaggio di config DevOps dominante.

js-yaml diventa la libreria JavaScript de facto (dal 2011)

Vitaly Puzrin pubblicò js-yaml nel 2011 come port JavaScript puro di PyYAML. Le versioni successive (2.0 nel 2014, 3.0 nel 2015, 4.0 nel 2021) hanno tracciato la spec YAML 1.2, aggiunto schemi per disattivare funzionalità pericolose e raggiunto oltre 50 milioni di download settimanali npm. La libreria è impacchettata da webpack, parcel ed esbuild per qualsiasi lavoro YAML lato browser, ed è ciò che questo convertitore usa sotto il cofano.

Flussi di lavoro pratici

Scrittura di manifest Kubernetes

Quando generi un Pod o Deployment tramite kubectl run --dry-run=client -o json, ottieni JSON. Incollalo qui, clicca JSON a YAML e hai un manifest pronto da committare in git. La conversione preserva le spec annidate, le variabili d'ambiente e i limiti delle risorse esattamente come Kubernetes li leggerà.

Definizioni di servizio Docker Compose

Un compagno di team ti invia uno snippet JSON per un nuovo servizio. Incollalo, converti e fai cadere lo YAML nel tuo docker-compose.yml. L'indent a 2 spazi è il default Compose, quindi lascia l'opzione indent a 2.

Workflow GitHub Actions

Quando crei lo scaffolding di un workflow da un generatore di template basato su JSON o copi uno step da una risposta API JSON, incollalo qui e converti. L'output si inserisce direttamente in .github/workflows/*.yml. Tieni presente che GitHub Actions accetta anche JSON in alcuni campi, ma YAML è la forma canonica.

Playbook Ansible

Gli inventari Ansible spesso iniziano la vita come JSON esportato da un CMDB o database di asset. Incolla, converti in YAML e hai un file hosts o intestazione di playbook che si adatta allo stile previsto da Ansible. Usa indent a 2 spazi per corrispondere alla guida di stile della community Ansible.

Valori di chart Helm

Un vendor spedisce configurazioni di esempio JSON per il suo chart Helm. Converti in YAML e fai cadere in values.yaml. La conversione rispetta le chiavi annidate (image.repository, image.tag, resources.limits.memory) esattamente come Helm si aspetta.

Spec OpenAPI 3

Swagger Editor esporta spec OpenAPI sia come JSON che YAML. Quando uno strumento emette JSON ma il tuo team usa YAML nel controllo versione (o viceversa), questo convertitore è il modo più veloce per cambiare formato senza avviare Node, Python o yq.

Trappole comuni

Il problema Norvegia (yes, no, on, off come booleani)

In YAML 1.1, le stringhe yes, no, on, off, y, n, true, false (e le loro varianti capitalizzate) sono tutte booleane. Quindi il codice paese ISO non quotato NO diventa il booleano false. js-yaml 4.x è di default YAML 1.2 che tratta solo true e false come booleani, ma i parser YAML più vecchi possono ancora inciampare. Quota esplicitamente le stringhe ambigue se mescoli versioni di tooling.

I tab non sono indentazione YAML valida

YAML usa spazi, non tab, per l'indentazione. Se il tuo editor inserisce tab per default, lo YAML convertito fallirà il parsing in Kubernetes, Helm o qualsiasi loader YAML rigoroso. Configura il tuo editor per usare 2 o 4 spazi per file .yaml e .yml, o esegui un linter (yamllint) prima del commit.

Ancore e alias non sopravvivono alla conversione JSON

YAML supporta ancore (&name) e alias (*name) per riutilizzare valori. Quando converti YAML a JSON, le ancore vengono espanse inline perché JSON non ha una funzionalità equivalente. La conversione inversa JSON a YAML non reintrodurrà ancore automaticamente. Se hai bisogno di ancore, scrivile a mano dopo la conversione.

Le stringhe multi-riga necessitano di indicatori espliciti

Una stringa JSON con newline incorporati (Hello\nWorld) converte a YAML usando lo scalar di blocco letterale (|) o lo scalar di blocco folded (>). js-yaml sceglie la forma giusta, ma se modifichi a mano il risultato, ricorda che | preserva i newline e > li ripiega in spazi.

I numeri grandi perdono precisione

I numeri JavaScript sono float IEEE 754 a 64 bit, quindi gli interi oltre 2 alla 53 (circa 9 quadrilioni) perdono precisione quando parsati da JSON.parse. La conversione a YAML preserva il valore con perdita, non l'originale. Se i tuoi dati hanno identificatori in stile BigInt, codificali come stringhe in JSON prima di convertire.

I commenti vanno persi in YAML a JSON

YAML supporta i commenti #, JSON no. Quando converti YAML con commenti di nuovo a JSON, i commenti vengono rimossi perché JSON non ha sintassi per loro. Se fai round-trip di YAML attraverso JSON per l'elaborazione, aspettati di perdere ogni riga #. Strumenti come yq o ruamel.yaml possono preservare i commenti, ma il js-yaml conforme alla spec li elimina.

Privacy e gestione dei dati

Tutta la conversione gira nel tuo browser tramite la libreria js-yaml impacchettata nella pagina. Non inviamo il tuo JSON o YAML a un server, non registriamo gli input e non eseguiamo analytics sul contenuto delle tue conversioni. Il pulsante Copia usa l'API Clipboard che richiede un gesto utente, e il pulsante Download .yaml usa un URL blob in memoria, quindi il file non fa mai un round-trip attraverso alcuna rete.

Una volta caricata la pagina (incluso il file CDN js-yaml), lo strumento funziona offline. Puoi disconnetterti dalla rete e convertire configurazioni sensibili (chiavi API, URL database, nomi di servizi interni) senza che nulla lasci il tuo dispositivo. Il file js-yaml è servito da jsDelivr con un hash Subresource Integrity, quindi il bundle non può essere scambiato silenziosamente.

Quando non usare questo convertitore

Streaming di megabyte di dati

Il convertitore carica l'intero input in memoria, lo parsa ed emette il risultato in un colpo solo. Per file JSON o YAML di più megabyte, usa yq o jq in una pipeline shell, o un parser streaming nel tuo linguaggio preferito. Il browser non è lo strumento giusto sopra i 5-10 megabyte.

Dati binari in JSON

Se il tuo JSON ha blob binari codificati Base64 che devono essere ispezionati o modificati, convertire a YAML non li scompatterà. YAML supporta binary taggato (!!binary) che js-yaml gestisce, ma i byte rimangono Base64. Usa un editor binario dedicato per il vero lavoro a livello di byte.

Validazione di schema

Questo convertitore controlla che l'input sia JSON o YAML valido, ma non valida contro uno schema (JSON Schema, OpenAPI, Kubernetes CRD, Helm values). Se hai bisogno di sapere se un manifest Kubernetes è strutturalmente corretto per un cluster 1.28, esegui kubectl --dry-run=server o uno strumento come kubeval, kubeconform.

Refactoring consapevole dello schema

Se hai bisogno di rinominare un campo in centinaia di file YAML o aggiornare una versione API (apps/v1beta1 a apps/v1), usa sed, ast-grep o yq con query di percorso esplicite. Il convertitore trasforma solo tra formati, non modifica contenuto semantico.

Altre domande

JSON è più sicuro di YAML?

Per la sicurezza, sì. yaml.load di PyYAML (prima della 5.1) e parser permissivi simili potevano eseguire codice arbitrario da input YAML non attendibili tramite oggetti Python taggati. JSON non ha tale funzionalità, ogni parser JSON è sicuro per design. I parser YAML moderni (PyYAML 5.1+, js-yaml dal 4.0) sono di default safe-load, quindi il divario si è ridotto, ma JSON è ancora il default più sicuro per input non attendibile.

Perché YAML ha scelto l'indentazione invece delle parentesi?

Gli autori di YAML volevano che le config si leggessero come outline, quindi hanno usato la stessa convenzione del whitespace significativo di Python. Parentesi graffe e quadre sono YAML valido (stile flow), ma lo stile block con indentazione è il default perché scansiona più naturalmente per gli umani che editano in testo semplice. Il compromesso è che il whitespace diventa significativo, il che cattura gli editor che auto-tagliano gli spazi finali.

YAML è sempre un superinsieme stretto di JSON?

Dal YAML 1.2 (2009), sì. Qualsiasi documento JSON valido è anche un documento YAML 1.2 valido. YAML 1.1 aveva alcuni casi limite (numeri sessagesimali, il problema Norvegia) dove la relazione era più sciolta. js-yaml moderno usa 1.2 per default, quindi la proprietà di superinsieme vale per questo strumento.

Perché il YAML di Kubernetes è così verboso?

I manifest Kubernetes hanno una forma top-level fissa (apiVersion, kind, metadata, spec) e la spec contiene oggetti annidati che rispecchiano le struct Go interne dell'API. La verbosità è un effetto collaterale del mappare un'API orientata agli oggetti a un formato testo piatto. Strumenti come Kustomize, Helm e Pulumi riducono la verbosità, ma il YAML sottostante è ciò che kubectl invia effettivamente al cluster.

Posso fare round-trip di JSON attraverso YAML senza perdita di dati?

Per la maggior parte del JSON, sì. Stringhe, numeri, booleani, null, array, oggetti sopravvivono tutti. I casi limite includono interi molto grandi (perdita di precisione), coppie surrogate Unicode (dipende dal parser) e ordine delle chiavi (YAML può riordinare). Se le tue chiavi JSON devono mantenere il loro ordine originale, usa uno strumento che rispetti l'ordine di inserimento (OrderedDict di Python, json-stable-stringify in JavaScript).

E TOML e HCL?

TOML (Tom's Obvious Minimal Language, 2013 di Tom Preston-Werner) è usato da Cargo (Rust), pyproject.toml (Python) e altri. HCL (HashiCorp Configuration Language, 2014) è usato da Terraform. Entrambi mirano al caso d'uso di configurazione ma usano sintassi diversa. Questo convertitore gestisce solo JSON e YAML. Per TOML o HCL, usa convertitori dedicati o yq con il plugin giusto.