Strumenti per sviluppatori · JSON formattatore e validatore
Cronologia degli standard di JSON: da RFC 4627 a RFC 8259 e ECMA-404
· Sfondo
json standard convalida
JSON è stato specificato almeno quattro volte da due organismi di normalizzazione. Questo post traccia il percorso da json.org di Douglas Crockford a RFC 8259 e ECMA-404 e spiega cosa è effettivamente cambiato per gli sviluppatori lungo il percorso.
Quali specifiche sta seguendo il mio parser?
Quale specifica sta seguendo un parser? La risposta è solitamente visibile ai bordi piuttosto che negli oggetti e negli array ordinari. Testare una stringa di livello superiore come `"ready"`, un segno di ordine dei byte iniziale, nomi di membri duplicati e numeri insolitamente grandi. Diversi documenti discutono la sintassi e l'interoperabilità a diversi livelli, mentre le implementazioni aggiungono i propri tipi di dati e comportamento degli errori. Dare un nome a uno standard è utile solo quando il contratto del parser osservato viene mantenuto separato dai presupposti su ogni implementazione JSON.
Le prove raccolte nell'archivio per ToolAcre sono concrete e più ristrette di una cronologia degli standard generali. Il formattatore utilizza `JSON.parse` per produrre valori e `JSON.stringify` per emetterli; dopo un errore di analisi, uno scanner locale fornisce una posizione diagnostica stabile e una ragione.
json.org e la prima descrizione di JSON
json.org ha presentato JSON come una notazione compatta derivata dalla sintassi letterale oggetto di JavaScript e ha documentato le sue strutture principali con una piccola grammatica. Quella prima descrizione ha aiutato a fornire agli sviluppatori un nome e un riferimento condiviso per oggetti, array, stringhe, numeri, valori booleani e null. È più sicuro descrivere la pagina come una delle prime spiegazioni pubbliche che affermare, senza citare prove storiche qui, che una pagina o una persona da sola abbia scoperto un formato o stabilito la sua adozione.
Le fonti attuali del repository non includono una cronologia di archivio di json.org, utilizzo del browser o discussioni del comitato. Mostrano come questa applicazione analizza e diagnostica JSON oggi. Di conseguenza, le dichiarazioni storiche contenute in questo articolo si attengono a documenti standard datati ed evitano di attribuire motivazioni o effetti di mercato che tali documenti locali non possono dimostrare.
RFC 4627 in 2006 — la prima descrizione IETF, il tipo di supporto application/json e la regola secondo cui un testo doveva essere un oggetto o un array
RFC 4627, pubblicato in 2006, descriveva JSON per lo scambio Internet e registrava il tipo di supporto `application/json`. La sua definizione di un testo JSON richiedeva un oggetto o un array al livello più alto, anche se stringhe, numeri e valori letterali esistevano come valori all'interno di quei contenitori. Questa restrizione è un'utile differenza storica perché un documento contenente solo `"ready"` potrebbe essere un valore valido in una formulazione successiva pur non rientrando nella definizione di testo RFC 4627 di JSON.
Il documento discuteva anche i problemi di codifica e sicurezza nel contesto delle implementazioni disponibili all'epoca. Non deve essere letto come un registro delle modifiche per questo repository: ToolAcre non contiene una modalità di compatibilità RFC 4627 e il relativo percorso del parser delega la costruzione del valore al motore host JavaScript.
ECMA-404 in 2013 — Lo standard minimo di sola sintassi di Ecma e perché due organizzazioni hanno finito per descrivere un formato
ECMA-404, pubblicato per la prima volta in 2013, specifica la sintassi JSON in una forma volutamente compatta. Il suo focus è la grammatica del testo JSON valido piuttosto che un profilo di interscambio completo per ogni utilizzo della rete. Questo ambito aiuta a spiegare perché i documenti ECMA-404 e IETF possono descrivere la stessa notazione di base pur differendo nelle indicazioni di interoperabilità circostanti che enfatizzano. L'esistenza di due organismi di normalizzazione non implica due formati incompatibili nell'uso comune.
Le affermazioni sul motivo per cui le organizzazioni hanno scelto particolari percorsi di pubblicazione richiedono fonti documentarie oltre questa base di codice, quindi questo articolo non deduce le motivazioni del comitato dalle date degli standard. Il punto pratico rilevante è che RFC 8259 e ECMA-404 sono destinati ad allinearsi sulla sintassi, mentre RFC 8259 fornisce raccomandazioni importanti per lo scambio interoperabile.
RFC 7159 e RFC 8259
RFC 7159 ha sostituito RFC 4627 in 2014 e ha ampliato la definizione di un testo JSON a qualsiasi valore serializzato, rimuovendo la regola di livello superiore solo oggetto o array. RFC 8259 ha sostituito RFC 7159 in 2017 e rimane il riferimento IETF normalmente citato per JSON. Richiede UTF-8 per JSON scambiato tra sistemi al di fuori di un ecosistema chiuso e registra avvertenze di interoperabilità su numeri, nomi duplicati, Unicode e segni di ordine dei byte piuttosto che fingere che la grammatica da sola garantisca risultati identici ovunque.
Un `true` di livello superiore è un modo compatto per osservare la moderna regola del valore root in ToolAcre perché `JSON.parse` la accetta. Questo risultato dimostra il comportamento di questa implementazione; non ricostruisce quando ogni browser, server o API ha adottato la definizione più ampia.
Cosa è cambiato per gli sviluppatori che lavorano
Per gli sviluppatori attivi, le modifiche più chiare alle specifiche sono l'accettazione moderna di qualsiasi valore JSON alla radice e una guida più forte per la codifica interoperabile. La lezione meno visibile è che la sintassi valida lascia ancora scelte di implementazione. I nomi degli oggetti duplicati potrebbero essere compressi, l'ordinamento dei membri non è un contratto semantico, numeri molto grandi potrebbero perdere precisione e sequenze Unicode insolite possono viaggiare in modo diverso attraverso le librerie. Un documento conforme agli standard può quindi meritare vincoli aggiuntivi da uno schema applicativo.
In questo formattatore, i nomi duplicati e i token numerici passano prima attraverso `JSON.parse`, quindi la formattazione successiva riflette il valore JavaScript risultante anziché il documento lessicale originale. Lo scanner fornisce la diagnostica dopo il guasto; non conserva membri duplicati o numeri di precisione arbitraria. Queste sono osservazioni supportate dal repository.
Ciò che questo non copre
Ciò che questo non copre sono le specifiche sovrapposte a JSON. JSON Lo schema descrive i vincoli sulla forma e sui valori del documento; JSON Il puntatore indirizza le posizioni all'interno di un documento; JSON La patch rappresenta le modifiche. Risolvono problemi diversi dalla grammatica di base e non devono essere trattati come versioni successive di JSON stesso. JSONC, JSON5 e formati di creazione simili estendono o alterano anche la sintassi accettata e richiedono i propri parser anziché essere ripiegati in una rigorosa convalida silenziosamente.
Questo articolo evita inoltre una cronologia sociale completa dell'adozione di JSON, del supporto dei browser o della concorrenza con XML perché le fonti del repository elencate non possono suffragare tale narrazione. Non sono state inventate citazioni esterne per colmare la lacuna.
Da asporto: RFC 8259 è il riferimento da citare
RFC 8259 è il riferimento pratico IETF da citare per le attuali linee guida sulla sintassi e sull'interoperabilità di JSON, con ECMA-404 che fornisce lo standard di sintassi Ecma allineato. RFC 4627 e RFC 7159 rimangono utili per comprendere come è cambiata la definizione pubblicata, soprattutto al livello più alto. Citare il documento che supporta l'affermazione esatta invece di utilizzare "la specifica JSON" come un vago appello all'autorità e distinguere le regole normative dal comportamento di implementazione osservato in un particolare parser.
Per ToolAcre, l'affermazione difendibile è che il repository utilizza il parser e il serializzatore JSON di JavaScript e aggiunge uno scanner locale rigoroso per la diagnostica dopo gli errori. Test di valori di livello superiore, punteggiatura non corretta e gestione dei numeri descrivono quel percorso; non sono fonti storiche.