Convertitore da YAML a JSON gratuito

Cos’è YAML?

YAML (YAML Ain’t Markup Language) è un formato di serializzazione dei dati facile da leggere per gli umani, progettato per essere semplice da leggere e scrivere. È ampiamente utilizzato per file di configurazione, pipeline CI/CD e scambio di dati tra linguaggi di programmazione.

Perché convertire YAML in JSON?

• Compatibilità universale · JSON è supportato praticamente da tutti i linguaggi di programmazione e strumenti.
• Gestione della configurazione · Molti strumenti si aspettano JSON per la configurazione o lo scambio di dati.
• Integrazione API · Le API web richiedono tipicamente il formato JSON.
• Elaborazione dei dati · Converti i file di configurazione YAML per l’uso in flussi di lavoro automatizzati.

Domande frequenti

Quali funzionalità YAML sono supportate?

Il convertitore supporta tutte le funzionalità standard di YAML 1.2, incluse mappe, liste, tipi scalari (stringhe, numeri, booleani, null), ancore e alias, documenti multipli e strutture annidate.

La mia struttura YAML complessa verrà convertita correttamente?

Sì. Il convertitore gestisce strutture profondamente annidate, array di oggetti, riferimenti di ancore e tipi di dati misti. Se il tuo YAML è valido, produrrà un JSON equivalente che preserva tutte le relazioni tra i dati.

I commenti YAML vengono preservati?

No. JSON non supporta i commenti, quindi vengono rimossi durante la conversione. Solo i dati strutturati del tuo YAML vengono convertiti in formato JSON.

Una breve storia di YAML, una costola di una mailing list del 2001

La preistoria di YAML comincia sulla mailing list sml-dev, una propaggine degli anni 2000 di xml-dev che raccolse le persone convinte che XML fosse eccessivo per i dati modificati a mano. Convergevano due filoni paralleli: il modulo Perl Data::Denter di Ingy döt Net, scritto come formato di serializzazione per il modulo Inline di Perl, e il lavoro congiunto di Oren Ben-Kiki e Clark Evans volto a semplificare XML. L'11 maggio 2001, Clark Evans pubblicò «YAML Draft 0.1» su sml-dev, e il formato fu reso pubblico per la prima volta in un articolo di xmlhack il giorno successivo.

Lo scioglimento iniziale dell'acronimo era ironico: Yet Another Markup Language, una frecciata alla proliferazione di formati di markup nel 2001. Tra dicembre 2001 e aprile 2002 gli autori adattarono il backronimo ricorsivo YAML Ain't Markup Language: in parte per sottolineare che YAML è un formato di serializzazione di dati anziché un formato di markup di documenti come XML o HTML, e in parte perché la battuta era invecchiata. Lo scioglimento ricorsivo è ancora oggi lo slogan ufficiale su yaml.org.

Cronologia della specifica

• Draft 0.1: 11 maggio 2001, annuncio sulla mailing list sml-dev.
• YAML 1.0: 29 gennaio 2004, la prima specifica stabile, di Ben-Kiki, Evans e Ingy döt Net.
• YAML 1.1: 18 gennaio 2005, la versione che la maggior parte dei parser «legacy» emula ancora per impostazione predefinita. All'origine del Problema Norvegia e della maggior parte delle imperfezioni della tipizzazione implicita.
• YAML 1.2.0: 21 luglio 2009, la prima revisione con un esplicito obiettivo di «superinsieme di JSON». Tipizzazione implicita riscritta per allinearsi ai token di JSON.
• YAML 1.2.1: 1 ottobre 2009, un aggiornamento di sola errata della 1.2.0.
• YAML 1.2.2: 1 ottobre 2021, la revisione di corrigenda a opera del nuovo YAML Language Development Team formato nel 2020.

La specifica 1.2.2 è esplicita sul fatto che «non ci sono modifiche normative rispetto alla specifica YAML v1.2»; il lavoro è consistito nel convertire il sorgente da DocBook a Markdown, nel rigenerare i diagrammi da LaTeX in testo semplice e nell'aprire il processo di sviluppo affinché i contributori esterni potessero inviare pull request alla specifica stessa. Nessuna versione del linguaggio è uscita dal 2009: da allora ogni bug di conformità dei parser è un residuo della 1.1 oppure una deviazione da una specifica che ormai regge da oltre quindici anni. Il tipo MIME ufficiale application/yaml è stato finalizzato nel 2024; le estensioni di file .yaml e .yml sono entrambe riconosciute da circa il 2006, con .yaml come quella raccomandata.

Il rapporto con JSON, «quasi un superinsieme»

La specifica YAML 1.2.2 lo formula con cautela: «Per pura coincidenza, JSON era quasi un sottoinsieme completo di YAML.» JSON comparve tra YAML 1.0 (2004) e YAML 1.1 (2005); gli autori di YAML scoprirono la sovrapposizione solo a posteriori. L'obiettivo esplicito della revisione 1.2, nelle sue stesse parole, era «rendere YAML un superinsieme stretto di JSON», e questo è quasi vero per i documenti YAML 1.2 in formato JSON ma non è vero per YAML 1.1.

In termini pratici: ogni documento JSON è YAML 1.2 valido, la mappatura in stile flow {"a": 1, "b": [true, null]} viene analizzata in modo identico in entrambi. La maggior parte dei documenti JSON non è YAML 1.1 valido a causa delle insidie dei booleani e di Norvegia: un documento JSON che contiene la stringa letterale "NO" verrebbe riemesso come false se passasse per un parser 1.1 con le impostazioni predefinite. Il contrario non è mai vero: YAML può esprimere cose che JSON non può, i commenti (persi nella conversione), gli ancoraggi e gli alias (risolti durante la conversione), i tag (di solito scartati), i flussi multi-documento (sopravvive solo il primo o tutti come array) e le chiavi non stringa nelle mappature.

Il Problema Norvegia

L'insidia più citata di YAML. Prende il nome dalla Norvegia perché il codice paese ISO 3166-1 di due lettere per la Norvegia è NO, e la regex booleana di YAML 1.1 interpreta NO come il valore booleano falso. Scrivi country: NO in YAML 1.1 (o in un qualsiasi parser 1.2 che usa ancora per impostazione predefinita il comportamento 1.1, ossia la maggior parte di essi), analizzalo, esportalo come JSON e ottieni {"country": false}. Il bug è silenzioso: non c'è alcun avviso, nessun errore di tipo, solo corruzione dei dati.

La regex booleana completa di YAML 1.1 dallo schema ufficiale yaml.org/type/bool.html è:

y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF

Sono sei lessemi (y/n, yes/no, on/off, true/false) con tre varianti di maiuscole/minuscole ciascuno, ventidue stringhe che diventano tutte booleani senza preavviso. Un elenco di risposte valide [y, n, maybe] diventa [true, false, "maybe"]; un feature flag dark_mode: on viene analizzato come dark_mode: true; un'impostazione di modalità porta scritta OFF diventa false. YAML 1.2 ha corretto questo a livello di specifica: lo schema di base allineato a JSON riconosce solo true, True, TRUE, false, False, FALSE e non riconosce affatto y/n/yes/no/on/off. Ma questa correzione non si è propagata sul campo: PyYAML e LibYAML usano ancora per impostazione predefinita la 1.1 in tutte le versioni attualmente distribuite. Questo convertitore usa js-yaml v4, che usa per impostazione predefinita lo schema YAML 1.2 / compatibile con JSON; è uno dei motivi per cui un convertitore lato browser è in realtà più sicuro che eseguire yaml.load() in PyYAML e convertire da lì.

Altre mine della tipizzazione implicita

Numeri ottali. YAML 1.1 seguiva la convenzione del C: uno zero iniziale significava ottale. Così 010 veniva analizzato come l'intero 8, e permissions: 0777 (un modo perfettamente naturale di scrivere un permesso di file Unix) veniva analizzato come 511. La correzione di YAML 1.2 fu richiedere un esplicito prefisso 0o analogo al Python moderno: 0o777 è 511, e 0777 è semplicemente 777. I parser fermi alle impostazioni predefinite della 1.1 continuano a sbagliare questo.

Numeri sessagesimali. YAML 1.1 ereditò dai precedenti formati di serializzazione la convenzione per cui qualsiasi sequenza di gruppi di cifre decimali separati da due punti dovesse essere analizzata come un intero o un decimale in base 60 (sessagesimale). Il caso d'uso pubblicizzato erano le durate temporali: 1:11:00 veniva analizzato come l'intero 4260 (un'ora, undici minuti espressi in secondi). Questa regola morde ancora le persone nella pratica quando scrivono timestamp come 21:00 o numeri di versione come 2:3:4 e li trovano convertiti in silenzio in interi. Il sessagesimale fu rimosso in silenzio in YAML 1.2, ma PyYAML e altri parser con la 1.1 come predefinita lo applicano ancora.

Conversione automatica di data e ora. YAML 1.1 rileva automaticamente anche i timestamp ISO 8601 e li analizza come il tipo data/ora nativo del linguaggio ospite, il che è un problema se volevi una stringa. Scrivi version: 2024-01-15 e ottieni un oggetto date di Python, non la stringa "2024-01-15". La lezione generale, ribadita dal saggio «YAML document from hell» di Ruud van Asseldonk: metti sempre tra virgolette le stringhe che potrebbero plausibilmente essere analizzate come qualcos'altro. I codici paese, i numeri di versione, i permessi di file, i timestamp e qualsiasi valore tratto da un vocabolario fisso dovrebbero essere racchiusi tra virgolette singole o doppie.

Ancoraggi, alias e la chiave di merge

Il sistema di ancoraggi/alias di YAML consente di etichettare un nodo con &name e riutilizzarlo in seguito con *name. L'esempio classico:

defaults: &defaults
  timeout: 30
  retries: 3
production:
  <<: *defaults
  host: prod.example.com

Qui &defaults ancora la mappatura, e <<: *defaults (la chiave di merge (una funzionalità dello schema 1.1 mantenuta dalla maggior parte dei parser) la innesta nel blocco di produzione. Quando questo viene convertito in JSON, l'alias è completamente risolto) l'output JSON contiene il contenuto ripetuto letterale, non un riferimento. Gli ancoraggi e gli alias spariscono, e ogni chiave di merge viene appiattita.

La famosa modalità di errore di questo sistema è il billion laughs attack: poiché gli ancoraggi possono essere riferiti tramite alias più volte e i bersagli degli alias possono a loro volta contenere alias, un piccolo file YAML può espandersi in una struttura in memoria enorme (10 livelli × annidamento decuplo = 10¹⁰ elementi stringa). PyYAML, LibYAML e altri hanno dovuto aggiungere limiti di espansione per mitigarlo. I convertitori lato browser hanno limiti di memoria naturali (la scheda andrà in OOM molto prima che ne soffra l'host), ma il rischio strutturale è reale.

Flussi multi-documento e front matter

Un flusso YAML può contenere più di un documento. I documenti sono separati da una riga contenente esattamente --- (usato anche come marcatore di fine direttive all'inizio del primo documento, motivo per cui il front matter in Jekyll, Hugo ed Eleventy è racchiuso tra righe ---). Una riga contenente ... segna la fine di un documento senza iniziarne uno nuovo, utile nei protocolli di streaming.

Kubernetes usa --- per raggruppare più manifest di risorse in un solo file. JSON non ha un equivalente. Un convertitore ha tre scelte quando incontra YAML multi-documento: emettere solo il primo documento, emettere un array JSON di documenti, oppure emettere un documento JSON per ogni --- separato da a capo (JSON Lines). La maggior parte dei convertitori usa per impostazione predefinita la prima o la seconda opzione; loadAll di js-yaml restituisce un array.

Stringhe multi-riga, folded vs literal

YAML ha due stili di scalare a blocco. Lo stile literal (|) preserva esattamente gli a capo. Lo stile folded (>) sostituisce le singole interruzioni di riga con spazi e preserva le righe vuote come separatori di paragrafo. Entrambi accettano indicatori di chomping: |- e >- rimuovono tutti gli a capo finali, |+ e >+ li mantengono tutti, e il | o > non modificato («clip») preserva un singolo a capo finale. Quando vengono convertiti in JSON, entrambi gli stili producono normali valori stringa: il blocco folded diventa una lunga stringa con \n incorporati solo in corrispondenza delle righe vuote preservate; il blocco literal ha \n a ogni interruzione di riga.

Cosa si perde nella conversione

• Le rappresentazioni di null collassano. YAML accetta null, Null, NULL, ~ e un valore vuoto (key: senza nulla dopo) come null. Tutti e cinque diventano null in JSON, in modo indistinguibile.
• I commenti spariscono in silenzio. I commenti YAML iniziano con # e la specifica 1.2 è esplicita sul fatto che sono solo di presentazione, non fanno parte del modello dei dati. JSON non ha una sintassi per i commenti. Se hai bisogno di preservarli, memorizzali come dati (ad es. un campo _comment) prima della conversione.
• Le chiavi non stringa vengono convertite. Le mappature YAML consentono qualsiasi nodo come chiave, compresi gli interi (1: foo), i booleani (true: yes) e persino le sequenze annidate. JSON richiede chiavi stringa. La maggior parte dei convertitori le converte in stringhe ("1": "foo"); alcuni generano un errore.
• I tag di solito vengono eliminati. I tag personalizzati come !!set, !!omap o quelli specifici dell'applicazione !myapp/Type non hanno un equivalente JSON.
• Le date/ore fanno il round-trip come stringhe. Una data o un timestamp YAML di solito diventa una stringa ISO 8601 in JSON, poiché JSON non ha un tipo data nativo.
• I numeri interi grandi perdono precisione in JavaScript. I numeri JSON sono double IEEE 754 in JS, quindi un intero YAML come 9007199254740993 diventa in silenzio 9007199254740992 dopo la conversione.
• Gli ancoraggi vengono espansi. Un grafo YAML che condivide un sotto-albero in più posizioni diventa un albero JSON con quel sotto-albero duplicato. I riferimenti ciclici (che YAML consente) non sono affatto rappresentabili in JSON.

Dove viene effettivamente usato YAML

YAML è ovunque nell'infrastruttura moderna: manifest Kubernetes (l'intero modello a oggetti è YAML per convenzione; i file multi-documento separati da --- sono lo standard), Docker Compose (docker-compose.yml per servizi, reti, volumi), GitHub Actions (.github/workflows/*.yml: schema YAML 1.2 stretto perlopiù rispettato, ma il parser riconosce ancora on: come chiave, un quasi-incidente del Problema Norvegia che GitHub aggira esplicitamente), GitLab CI/CD, playbook Ansible, CircleCI / Travis CI / Drone / Bitbucket Pipelines, front matter di Jekyll / Hugo / Eleventy / Gatsby / Astro, specifiche OpenAPI / Swagger (ufficialmente «un oggetto JSON che può essere rappresentato in JSON o in YAML»), configurazione dello stack di monitoraggio Prometheus / Grafana / Loki / Tempo, cloud-init (provisioning al primo avvio di VM EC2/GCE/Azure) e AWS CloudFormation / Azure Resource Manager / Google Cloud Deployment Manager. Per la maggior parte di questi, la conversione da YAML a JSON è essenziale ogni volta che incorpori la configurazione in protocolli che accettano solo JSON, confronti file con jq o passi l'output a uno strumento che si aspetta JSON.

Perché la conversione lato browser è più sicura di quella lato server

yaml.load() di PyYAML con le impostazioni predefinite poteva eseguire codice Python arbitrario su qualsiasi input non attendibile tramite il tag !!python/object, che deserializza in veri e propri oggetti Python con effetti collaterali: CVE-2017-18342, punteggio CVSS v3.1 di 9,8 (Critico), corretto in PyYAML 5.1 (marzo 2019) deprecando l'impostazione predefinita non sicura e rendendo safe_load() il punto di accesso raccomandato. SnakeYAML di Java aveva il proprio equivalente (CVE-2022-1471, anch'esso CVSS 9,8) attorno alla classe Constructor che consentiva l'istanziazione arbitraria. Il crate serde_yaml de facto di Rust è stato deprecato a marzo 2024; l'ecosistema sta ancora scegliendo un successore (serde_yml, serde_yaml_ng, serde_norway).

Eseguire l'analisi nel browser tramite js-yaml v4 elude tutto questo: non c'è alcun server da compromettere, js-yaml non ha alcun concetto di esecuzione di codice arbitrario tramite i tag (i tag sconosciuti diventano semplici scalari anziché oggetti costruiti) e la v4 usa per impostazione predefinita il più sicuro schema 1.2. Lo strumento di Absolutool ne beneficia per impostazione predefinita.

Altre domande

Come gestisce il convertitore i file YAML multi-documento?

Li carica con loadAll di js-yaml, che restituisce un array di documenti analizzati: l'output JSON è quindi un array JSON con un elemento per ogni documento separato da ---. Se hai un solo documento, otterrai un array JSON con un elemento; racchiudi il tuo input tra i marcatori ---/... se vuoi una semantica esplicita a documento singolo.

Il mio manifest Kubernetes verrà convertito correttamente?

Quasi sempre sì. Kubernetes usa perlopiù contenuti compatibili con YAML 1.2, e js-yaml v4 gestisce tutte le primitive standard (stringhe, interi, booleani, null, sequenze, mappature) più gli ancoraggi e gli alias. Le due cose che non sopravvivono sono i commenti (rimossi) e gli eventuali ancoraggi che vengono espansi in contenuto ripetuto anziché in riferimenti.

Perché il mio codice paese NO viene letto come un booleano?

Non dovrebbe esserlo in questo convertitore: js-yaml v4 usa per impostazione predefinita lo schema YAML 1.2 / compatibile con JSON, che non riconosce y/n/yes/no/on/off come booleani. Se incontri questo problema in un altro strumento (PyYAML, per esempio), la soluzione è racchiudere il valore tra virgolette: country: "NO".

Qual è il limite di dimensione del file?

5 MB sul widget di caricamento, ma il contenuto incollato può essere più grande se il tuo browser ha la memoria. Il collo di bottiglia è la rappresentazione in memoria, non la rete: non c'è alcun server nel circuito. Per i file più grandi di ~50 MB, valuta invece una toolchain YAML desktop (yq da riga di comando, per esempio).

Strumenti correlati