Strumenti per sviluppatori · Convertitori di sintassi
JSON è valido YAML? Cosa promette YAML 1.2 e dove non funziona
· Sfondo
json yaml formati di dati
YAML 1.2 è stato progettato in modo che ogni documento JSON sia anche un documento YAML, motivo per cui la conversione da JSON a YAML sembra banale. Questo post spiega cosa garantisce effettivamente la specifica e i casi limite in cui la promessa viene meno.
Incollare JSON in un file YAML e farla franca: perché funziona e l'unica volta in cui non ha funzionato
Un normale oggetto JSON può essere incollato nel lato sorgente YAML e letto nello schema YAML 1.2 JSON di ToolAcre. Parentesi graffe, parentesi quadre, chiavi tra virgolette, stringhe, numeri, booleani e null diventano lo stesso semplice valore JavaScript. Ciò spiega perché il confine spesso sembra banale.
La garanzia dovrebbe rimanere specifica del parser. ToolAcre limita i tag, limita gli alias e la nidificazione e applica un limite di input. Un testo può essere valido sotto un processore YAML più ampio ma essere rifiutato qui per ragioni di sicurezza o di forma non correlate al suo nucleo dall'aspetto JSON.
Il normale JSON viene caricato tramite questo YAML 1.2 lettore; le estensioni non supportate falliscono per motivi separati
Gli schemi selezionati producono valori a forma di JSON: stringhe, numeri, booleani, null, matrici e mappature. Questo allineamento consente l'analisi e la serializzazione anziché la sostituzione della punteggiatura. Il codice sorgente non stabilisce ogni formulazione o errore della specifica YAML, quindi l'articolo riporta il comportamento testato invece di dichiarare una conformità esaustiva.
In modalità rigorosa, la tilde, il valore vuoto e `0o755` rimangono stringhe. Quelli sono YAML token che JSON stesso non conterrebbe. Core li risolve in modo diverso pur restituendo comunque un output a forma di JSON.
Gli schemi forniti si allineano con i dati in formato JSON senza dimostrare ogni vantaggio delle specifiche
Le chiavi di mappatura YAML duplicate mantengono l'ultimo valore con un avviso; un'interpretazione rigorosa altrove potrebbe respingerli. I lettori legacy YAML 1.1 possono digitare parole come `NO` in modo diverso, mentre questo lettore le conserva come stringhe. Tali differenze complicano le dichiarazioni generali sulla portabilità.
Le tabulazioni utilizzate come rientro producono un errore, mentre le tabulazioni all'interno delle stringhe JSON tra virgolette vengono sottoposte a escape. Valori molto profondi o sovradimensionati possono raggiungere i limiti di sicurezza locali. Una relazione linguistica teorica non supera i limiti di implementazione.
Le chiavi duplicate e le differenze del parser legacy rimangono i limiti dell'interoperabilità
Il contrario è chiaramente falso per questa pipeline di valore. I commenti YAML non hanno alcuna rappresentazione JSON, gli alias si risolvono in dati ripetuti, i flussi di più documenti diventano array e i tag non supportati vengono rifiutati. Gli scalari a blocchi diventano stringhe ma la loro presentazione viene persa.
Anche un documento YAML supportato può quindi essere convertito in un documento JSON valido e non tornare mai allo stesso testo YAML. L'uguaglianza dei dati può sopravvivere per valori ordinari mentre i commenti, gli ancoraggi, l'ortografia e l'identità del flusso no.
Cosa significa questo per la conversione: da JSON a YAML è un cambiamento di stile, da YAML a JSON è una traduzione che può perdere informazioni
JSON-to-YAML è in genere una modifica di stile e serializzazione per l'input a forma di JSON. YAML-to-JSON interpreta prima la sintassi specifica di YAML e quindi proietta il risultato nel modello di valori più piccolo di JSON. Le direzioni non sono simmetriche.
ToolAcre testa i normali documenti JSON-to-YAML-to-JSON contenenti valori nidificati, Unicode, valori null, array e stringhe dall'aspetto ambiguo. Questi dispositivi dimostrano la classe di dati coperta, non tutte le possibili coppie di processori JSON o YAML.
Esempio elaborato: un documento JSON caricato come YAML: la stessa struttura, quindi una funzione solo YAML aggiunta per mostrare dove si interrompe l'utensileria JSON
Incolla `{"country":"NO","items":[1,null],"nested":{"ok":true}}` come input YAML. Il lettore rigoroso restituisce lo stesso albero. Aggiungi un commento YAML e il valore rimane lo stesso mentre il commento scompare. Sostituisci un oggetto ripetuto con un'ancora e un alias; JSON ora contiene copie anziché sintassi di riferimento.
Aggiungi `---` e un secondo documento; il risultato diventa una serie di documenti con un avviso. Aggiungi `!!binary`; il lettore ristretto lo rifiuta. Ogni passaggio segna un confine distinto: presentazione ignorata, struttura risolta, convenzione del flusso e tipo non supportato.
Cosa non copre: compatibilità a livello di schema, dove i tipi YAML come i timestamp non hanno controparte JSON
La compatibilità dello schema non riguarda solo la sintassi della superficie. Core può creare Infinity o NaN, che JSON scrive come null con avvisi. Timestamp e tag binari vengono rifiutati negli schemi limitati anziché convertiti. ToolAcre restringe deliberatamente YAML ai dati sicuri a forma di JSON.
Un'altra implementazione YAML potrebbe supportare tipi aggiuntivi. Ciò lo rende meno compatibile con i semplici valori JSON in quei punti, non automaticamente migliori o peggiori. Scegli in base al contratto di destinazione e ai requisiti di sicurezza.
La compatibilità a livello di schema include valori non finiti e tag temporali che questo lettore limitato limita o rifiuta
I normali dati in formato JSON passano in modo pulito attraverso questo lettore e scrittore YAML 1.2. Affermazioni più ampie su tutti i documenti o parser richiedono soluzioni che coprano chiavi duplicate, versioni di schema, tag e limiti di risorse.
Utilizza i convertitori di sintassi per testare il testo effettivo e leggere i suoi avvisi. Considera "JSON is YAML" come una scorciatoia utile solo dopo aver nominato il parser, lo schema e le funzionalità non supportate che rendono preciso il confine reale.
Per un test di portabilità, mantieni un dispositivo interamente all'interno del modello di valore di JSON e un altro che aggiunge una sola funzionalità YAML alla volta. Esegui entrambi attraverso ciascun consumatore previsto. Il primo misura l'affermazione pratica del sottoinsieme; il secondo identifica esattamente dove divergono commenti, alias, stream, tag o regole scalari. Questo metodo a fasi è più informativo che chiedere se due lingue sono sottoinsiemi in astratto, perché produce errori legati ai parser effettivamente utilizzati dal sistema.