Converti YAML in JSON Online
Converti YAML in JSON nel tuo browser. Perfetto per validare configurazioni Docker, Kubernetes o GitHub Actions.
{
"name": "John Doe",
"age": 30,
"active": true,
"tags": [
"developer",
"javascript"
],
"address": {
"city": "Madrid",
"zip": "28001"
}
}A cosa serve
YAML in JSON: valida le configurazioni DevOps all'istante
Docker e Kubernetes
Converti docker-compose.yml o i manifest Kubernetes in JSON per validare le strutture o usarli con strumenti che accettano solo JSON.
Debug CI/CD
Valida i workflow GitHub Actions, le pipeline GitLab CI o i playbook Ansible convertendoli in JSON per vedere la struttura analizzata.
100% privato
La tua configurazione YAML viene elaborata nel browser. Non lascia mai il tuo dispositivo. Ideale per config che contengono segreti.
Rilevamento degli errori
Gli errori di sintassi YAML (indentazione, tabulazioni, tipi non validi) vengono mostrati chiaramente prima della conversione.
Come funziona
Tre passaggi, senza complicazioni
Incolla il tuo YAML
Incolla il tuo file YAML: docker-compose.yml, deployment Kubernetes, workflow GitHub Actions o qualsiasi configurazione YAML.
Conversione e validazione
Il convertitore analizza il YAML secondo la specifica YAML 1.2 e genera JSON valido istantaneamente, mostrando eventuali errori di sintassi.
Copia il JSON risultante
Copia il JSON formattato per usarlo nella tua API, nel tuo strumento di configurazione o per validare la struttura del tuo YAML.
FAQ
Hai delle domande?
YAML (YAML Ain't Markup Language, un acronimo ricorsivo) e un linguaggio di serializzazione dei dati leggibile dall'uomo. La specifica YAML 1.2 e stata pubblicata nel luglio 2009 su yaml.org ed e un superset di JSON: qualsiasi JSON valido e anche YAML valido. YAML e ampiamente usato nelle configurazioni degli strumenti DevOps (Docker Compose, Kubernetes, Ansible, Terraform, GitHub Actions, GitLab CI) perche la sua sintassi basata sull'indentazione e piu leggibile di JSON per configurazioni lunghe e gerarchiche. A differenza di JSON, YAML supporta i commenti (righe che iniziano con #), le stringhe su piu righe, le ancore e gli alias per riutilizzare i dati, e tipi aggiuntivi come le date ISO 8601.
YAML offre due stili per le stringhe su piu righe. Lo stile letterale (contrassegnato con |) preserva esattamente le interruzioni di riga come scritte - utile per script shell, contenuti di file o testo formattato. Lo stile ripiegato (contrassegnato con >) converte le interruzioni di riga in spazi e preserva solo le interruzioni di paragrafo (righe vuote) - utile per le descrizioni lunghe. In JSON, entrambi diventano stringhe con \n per le interruzioni di riga letterali o senza interruzioni per lo stile ripiegato. Il modificatore di troncatura (|- per eliminare, |+ per mantenere) controlla se l'ultima newline viene preservata.
Si. Le ancore YAML (&nome) e gli alias (*nome) sono un modo per riutilizzare nodi nel documento. In docker-compose.yml, e comune definire variabili d'ambiente condivise come ancora e referenziarle in piu servizi con la chiave di unione. Il nostro convertitore espande tutte le ancore e gli alias prima di generare il JSON, producendo la struttura completa senza riferimenti - il comportamento corretto, poiche JSON non ha un equivalente alle ancore YAML.
No. JSON (RFC 7159/RFC 8259) non supporta i commenti. I commenti YAML (testo dopo # fino alla fine della riga) vengono scartati durante l'analisi. Questa e una limitazione fondamentale del formato JSON, non del convertitore. Se hai bisogno di preservare la documentazione associata ai campi di configurazione, considera di usare JSON Schema (che consente campi description) o di mantenere il YAML originale come fonte di verita e generare il JSON su richiesta.
YAML usa spazi (mai tabulazioni) per l'indentazione al fine di indicare la gerarchia. La specifica YAML 1.2 non fissa un numero specifico di spazi, ma la convenzione piu comune e 2 spazi. La coerenza all'interno dello stesso livello gerarchico e fondamentale. Mescolare tabulazioni e spazi e un errore di sintassi in YAML. L'errore piu comune e mescolare accidentalmente tabulazioni con spazi, soprattutto quando si modifica YAML in editor che espandono le tabulazioni in modo diverso.
Si. I manifest Kubernetes (Deployment, Service, ConfigMap, Ingress) e i file docker-compose.yml sono YAML standard e si convertono correttamente in JSON. Questo e utile per validare la struttura del manifest, passarla a strumenti che accettano solo JSON (come alcuni client dell'API Kubernetes), o fare debug di comportamenti inattesi causati da sottili errori YAML. L'API Kubernetes accetta sia YAML che JSON; internamente, kubectl converte il YAML in JSON prima di inviare la richiesta al server API.
Convertire YAML in JSON: validazione di configurazioni DevOps e Kubernetes nel browser
YAML (YAML Ain't Markup Language) e diventato il formato di configurazione dominante nell'ecosistema DevOps moderno. Docker Compose (introdotto nel 2014, ora parte di Docker Engine dalla versione 20.10), Kubernetes (la cui API accetta manifest in YAML o JSON fin dal suo lancio da parte di Google nel 2014), GitHub Actions (lanciato a novembre 2019), GitLab CI/CD, Ansible (Red Hat, 2012), Terraform (HashiCorp, 2014) e i chart Helm usano tutti YAML come formato di configurazione principale. La specifica YAML 1.2, pubblicata su yaml.org nel luglio 2009, stabilisce che YAML e un superset rigoroso di JSON, il che significa che qualsiasi documento JSON e anche un documento YAML valido. Questa relazione rende la conversione tra i due formati semanticamente perfetta: non c'e perdita di informazioni strutturali, solo differenze di rappresentazione.
La conversione da YAML a JSON e particolarmente utile in diversi flussi di lavoro DevOps: fare debug delle pipeline CI/CD dove un errore di indentazione produce comportamenti inattesi (la rappresentazione JSON rende la struttura esplicita e inequivocabile); usare strumenti che accettano solo JSON come input (alcuni client REST dell'API Kubernetes, strumenti di validazione JSON Schema, o processori come jq che lavorano nativamente con JSON); migrare configurazioni tra strumenti che usano formati diversi; e verificare che il YAML venga analizzato come atteso, specialmente quando si usano funzionalita avanzate come ancore, alias, chiavi di unione, tipi espliciti o stringhe su piu righe con blocchi letterali e ripiegati.
L'analisi YAML presenta alcune sfide note che hanno portato al cosiddetto Norway Problem: in YAML 1.1 (usato da PyYAML prima della versione 6.0), il valore NO veniva interpretato come booleano false, causando un'analisi errata del codice del paese della Norvegia. YAML 1.2 (specifica luglio 2009) ha risolto questo: solo true e false (senza distinzione maiuscole/minuscole) sono booleani, e valori come yes, no, on, off che YAML 1.1 trattava come booleani ora sono stringhe. Il nostro convertitore usa una libreria che implementa YAML 1.2, garantendo un comportamento corretto e moderno. Per i progetti che usano PyYAML, l'aggiornamento alla versione 6.0 o superiore (rilasciata nel marzo 2022) e importante, poiche ha aggiunto il supporto al loader sicuro conforme a YAML 1.2 tramite yaml.safe_load().