Outils de développement · JSON formateur et validateur
JSON : RFC 4627 à RFC 8259 et ECMA-404
· Contexte
json normes validation
JSON a été spécifié au moins quatre fois par deux organismes de normalisation. Cet article retrace le chemin depuis json.org de Douglas Crockford vers RFC 8259 et ECMA-404, et explique ce qui a réellement changé pour les développeurs en cours de route.
Quelle spécification mon analyseur suit-il ?
Quelle spécification un analyseur suit-il ? La réponse est généralement visible sur les bords plutôt que dans les objets et tableaux ordinaires. Testez une chaîne de niveau supérieur telle que `"ready"`, une marque d'ordre des octets en tête, des noms de membres en double et des nombres inhabituellement grands. Différents documents traitent de la syntaxe et de l'interopérabilité à différents niveaux, tandis que les implémentations ajoutent leurs propres types de données et comportements d'erreur. Nommer une norme n'est utile que lorsque le contrat de l'analyseur observé est séparé des hypothèses sur chaque implémentation de JSON.
Les preuves du référentiel pour ToolAcre sont concrètes et plus étroites qu'un historique général des normes. Le formateur utilise `JSON.parse` pour produire des valeurs et `JSON.stringify` pour les émettre ; après un échec d'analyse, un scanner local fournit une position et une raison de diagnostic stables.
json.org et la première description de JSON
json.org a présenté JSON comme une notation compacte dérivée de la syntaxe littérale objet de JavaScript et a documenté ses structures de base avec une petite grammaire. Cette première description a permis de donner aux développeurs un nom et une référence partagés pour les objets, les tableaux, les chaînes, les nombres, les booléens et les valeurs nulles. Il est plus sûr de décrire la page comme une première explication publique plutôt que d’affirmer, sans citer de preuves historiques ici, qu’une page ou une personne à elle seule a découvert un format ou établi son adoption.
Les sources actuelles du référentiel n'incluent pas d'historique d'archives de json.org, d'utilisation du navigateur ou de discussions de comité. Ils montrent comment cette application analyse et diagnostique JSON aujourd'hui. En conséquence, les déclarations historiques contenues dans cet article restent proches des documents normatifs datés et évitent d’attribuer des motivations ou des effets de marché que ces fichiers locaux ne peuvent pas prouver.
RFC 4627 dans 2006 — la première description de l'IETF, le type de média de l'application/json et la règle selon laquelle un texte doit être un objet ou un tableau
RFC 4627, publié dans 2006, décrit JSON pour l'échange Internet et a enregistré le type de média `application/json`. Sa définition d'un texte JSON nécessitait un objet ou un tableau au niveau supérieur, même si des chaînes, des nombres et des littéraux existaient en tant que valeurs à l'intérieur de ces conteneurs. Cette restriction est une différence historique utile car un document contenant uniquement `"ready"` pourrait être une valeur valide dans une formulation ultérieure tout en tombant en dehors de la définition de texte JSON de la RFC 4627.
Le document aborde également les problèmes de codage et de sécurité dans le contexte des implémentations disponibles à l'époque. Il ne doit pas être lu comme un journal des modifications pour ce référentiel : ToolAcre ne contient pas de mode de compatibilité RFC 4627 et son chemin d'analyse délègue la construction de valeurs au moteur JavaScript hôte.
ECMA-404 dans 2013 — La norme minimale de syntaxe d'Ema, et pourquoi deux organisations ont fini par décrire un seul format
ECMA-404, publié pour la première fois dans 2013, spécifie la syntaxe JSON sous une forme délibérément compacte. Il se concentre sur la grammaire du texte JSON valide plutôt que sur un profil d'échange complet pour chaque utilisation en réseau. Cette portée aide à expliquer pourquoi l'ECMA-404 et les documents de l'IETF peuvent décrire la même notation de base tout en différant dans les orientations d'interopérabilité environnantes sur lesquelles ils mettent l'accent. L'existence de deux organismes de normalisation n'implique pas deux formats incompatibles dans l'usage courant.
Les affirmations sur les raisons pour lesquelles les organisations ont choisi des voies de publication particulières nécessitent des sources documentaires au-delà de cette base de code, donc cet article ne déduit pas les motivations du comité à partir des dates des normes. Le point pratique pertinent est que les RFC 8259 et ECMA-404 sont destinées à s'aligner sur la syntaxe, tandis que la RFC 8259 fournit des recommandations importantes pour l'échange interopérable.
RFC 7159 et RFC 8259
RFC 7159 a remplacé RFC 4627 dans 2014 et a élargi la définition d'un texte JSON à toute valeur sérialisée, en supprimant la règle de niveau supérieur d'objet ou de tableau uniquement. La RFC 8259 a remplacé la RFC 7159 dans 2017 et reste la référence IETF normalement citée pour JSON. Il nécessite UTF-8 pour JSON échangé entre des systèmes en dehors d'un écosystème fermé et enregistre les mises en garde en matière d'interopérabilité concernant les nombres, les noms en double, l'Unicode et les marques d'ordre des octets plutôt que de prétendre que la grammaire seule garantit des résultats identiques partout.
Un `true` de niveau supérieur est un moyen compact d'observer la règle de valeur racine moderne dans ToolAcre car `JSON.parse` l'accepte. Ce résultat démontre le comportement de cette implémentation ; il ne reconstruit pas le moment où chaque navigateur, serveur ou API a adopté la définition plus large.
Ce qui a changé pour les développeurs en activité
Pour les développeurs en activité, les changements de spécification les plus clairs sont l'acceptation moderne de toute valeur JSON à la racine et des conseils plus solides pour un codage interopérable. La leçon la moins visible est qu’une syntaxe valide laisse encore des choix d’implémentation. Les noms d'objets en double peuvent être réduits, l'ordre des membres n'est pas un contrat sémantique, de très grands nombres peuvent perdre en précision et des séquences Unicode inhabituelles peuvent voyager différemment dans les bibliothèques. Un document conforme aux normes peut donc mériter des contraintes supplémentaires de la part d'un schéma d'application.
Dans ce formateur, les noms et les jetons numériques en double passent d'abord par `JSON.parse`, de sorte que le formatage ultérieur reflète la valeur JavaScript résultante plutôt que le document lexical d'origine. Le scanner contribue au diagnostic après une panne ; il ne conserve pas les membres en double ni les numéros de précision arbitraire. Ce sont des observations sauvegardées dans un référentiel.
Ce que cela ne couvre pas
Ce que cela ne couvre pas, ce sont les spécifications superposées à JSON. JSON Le schéma décrit les contraintes sur la forme et les valeurs du document ; JSON Le pointeur pointe vers des emplacements dans un document ; JSON Le correctif représente les modifications. Ils résolvent des problèmes différents de la grammaire de base et ne doivent pas être traités comme des versions ultérieures de JSON lui-même. JSONC, JSON5 et les formats de création similaires étendent ou modifient également la syntaxe acceptée et nécessitent leurs propres analyseurs plutôt que d'être intégrés silencieusement dans une validation stricte.
Cet article évite également un historique social complet de l'adoption de JSON, de la prise en charge du navigateur ou de la concurrence avec XML, car les sources du référentiel répertoriées ne peuvent pas étayer ce récit. Aucune citation externe n’a été inventée pour combler cette lacune.
À retenir : RFC 8259 est la référence à citer
RFC 8259 est la référence pratique de l'IETF à citer pour la syntaxe JSON actuelle et les conseils d'interopérabilité, avec ECMA-404 fournissant la norme de syntaxe Ecma alignée. Les RFC 4627 et RFC 7159 restent utiles pour comprendre comment la définition publiée a changé, en particulier au niveau supérieur. Citez le document qui soutient l'affirmation exacte au lieu d'utiliser « la spécification JSON » comme un vague appel à l'autorité, et distinguez les règles normatives du comportement de mise en œuvre observé dans un analyseur particulier.
Pour ToolAcre, l'affirmation défendable est que le référentiel utilise l'analyseur et le sérialiseur JSON de JavaScript et ajoute un scanner local strict pour les diagnostics après des pannes. Des tests de valeurs de niveau supérieur, de ponctuation mal formée et de gestion des nombres décrivent cet itinéraire ; ce ne sont pas des sources historiques.