JSON5 vs JSON
La rigidité de JSON est sa fonctionnalité : la RFC 8259 fait que tous les parseurs du monde se comprennent. JSON5 échange une partie de cette universalité contre le confort humain — commentaires, clés sans guillemets, guillemets simples, virgules finales, nombres hexadécimaux. Gardez JSON pour tout ce qu’un programme lit ; n’autorisez JSON5 que dans des fichiers de configuration que chaque consommateur analyse avec la même bibliothèque.
JSON5 vs JSON en clair
Tout fichier JSON qui a exaspéré quelqu’un échoue de la même manière : impossible d’expliquer pourquoi un champ existe, impossible de désactiver temporairement un bloc, et supprimer la dernière virgule est une corvée que le parseur pourrait bien pardonner. JSON5 est la réponse de la communauté — un sur-ensemble strict de JSON, modelé sur la syntaxe d’ECMAScript 5, qui ajoute des commentaires, assouplit les guillemets et tolère les virgules finales plus quelques commodités numériques. Un JSON valide est toujours un JSON5 valide ; l’inverse ne l’est jamais.
La spécification vit sur json5.org plutôt que dans un document de l’IETF, et cet emplacement résume honnêtement l’échange. La grammaire de la RFC 8259 garantit qu’une charge utile écrite à Tokyo s’analyse à l’identique à Toronto — une page de règles, aucun dialecte. JSON5 réintroduit la question que le JSON strict ne pose jamais : quel parseur, et quelle version de ce parseur ? Les navigateurs livrent JSON.parse et rien d’autre, donc JSON5 signifie toujours une dépendance.
Voilà pourquoi la répartition en pratique est nette : JSON pour le fil et tout ce qui est stocké, JSON5 pour la configuration maintenue par des humains, où une dépendance à un parseur est un coût ponctuel et où les commentaires se justifient. Cette page passe en revue ce que JSON5 ajoute, ce qu’il coûte et où passe la frontière — avec les outils JSON locaux du site prêts à vérifier l’un ou l’autre camp.
Curieux de savoir où votre fichier se situe par rapport à la frontière de rigidité ? Le Validateur JSON analyse d’après la RFC 8259 en local et signale la première construction qu’un parseur strict rejette.
Pour les fichiers déjà dans le sous-ensemble strict, le Formateur JSON normalise guillemets, clés et indentation dans votre navigateur, sans aucun envoi.
Ce que JSON5 ajoute réellement
Les extensions de JSON5 viennent toutes de la syntaxe des littéraux d’objets d’ES5 — l’endroit d’où JSON vient à l’origine. Les commentaires reviennent, sous forme de // jusqu’à la fin de la ligne et de /* block */. Les clés peuvent être sans guillemets quand ce sont des identifiants valides. Les chaînes peuvent utiliser des guillemets simples et davantage de séquences d’échappement. Les nombres gagnent l’hexadécimal, un point décimal en tête ou en fin, un signe plus initial, et les valeurs spéciales Infinity, -Infinity et NaN. Les virgules finales sont admises dans les deux conteneurs.
| Fonctionnalité | JSON (RFC 8259) | JSON5 |
|---|---|---|
| Commentaires | Aucun — retirés délibérément | // et /* */ autorisés |
| Clés d’objet | Chaînes à guillemets doubles uniquement | Identifiants valides sans guillemets |
| Guillemets des chaînes | Guillemets doubles uniquement | Simples ou doubles |
| Virgules finales | Erreur de syntaxe | Autorisées |
| Nombres | Décimaux seulement, sans + initial | Hex, +.5, 5., Infinity, NaN |
| Norme | RFC 8259 / ECMA-404 | Spécification sur json5.org, définie par la bibliothèque |
Le coût : qui peut lire le fichier
JSON.parse rejette le premier commentaire, le premier guillemet simple ou la première clé nue qu’il rencontre — aucun navigateur n’embarque JSON5 nativement et aucune plateforme serveur n’en livre. Chaque consommateur a donc besoin de la même bibliothèque, figée sur un comportement compatible. Dès qu’un document cesse d’être du JSON strict, « n’importe quel parseur convient » cesse d’être vrai — et cette garantie est le principal bénéfice que la RFC 8259 procurait.
Un coût plus discret est le zoo de dialectes qui pousse dans l’intervalle : JSONC — commentaires et virgules finales seulement — est ce que tsconfig et VS Code acceptent réellement, et ce n’est pas du JSON5, puisque JSONC garde des guillemets et des nombres stricts. Les fichiers dérivent d’un dialecte à l’autre, les éditeurs divergent sur la coloration syntaxique, et une mise à jour de la chaîne d’outils peut transformer une construction tolérée en erreur. Le JSON strict n’a aucune de ces ambiguïtés à gérer.
Où chacun a sa place
La répartition suit le lecteur. Une configuration écrite et relue par des humains profite de commentaires qui expliquent un champ, d’interrupteurs mis en commentaire pendant le débogage et de clés sans guillemets qui réduisent le bruit — c’est le territoire de JSON5, partout où la chaîne d’outils le prend déjà en charge. Tout ce qu’un programme émet ou consomme — charges utiles d’API, état stocké, logs structurés, messages de file d’attente — reste en JSON strict, où l’universalité est tout l’enjeu.
- Format filaire : JSON, toujours — tout consommateur doit pouvoir l’analyser sans aucune configuration partagée.
- Configuration maintenue par des humains : JSON5 ou JSONC, si vos outils le parlent déjà nativement.
- Schéma et documentation : le JSON strict pousse l’explication vers les schémas, car les commentaires n’ont nulle part où vivre.
- Données au repos : JSON — ses futurs lecteurs incluent des outils qui ne sont pas encore choisis.
Convertir de l’un à l’autre
De JSON vers JSON5, c’est gratuit : le JSON strict s’analyse déjà comme du JSON5, donc « convertir » est une affaire de style, pas de structure. De JSON5 vers JSON, la conversion perd des données exactement comme on s’y attend : les commentaires n’ont aucune destination et disparaissent, et Infinity, -Infinity et NaN n’ont pas de valeur JSON, si bien qu’ils deviennent null ou des chaînes. Tout le reste survit : les clés gagnent des guillemets, les guillemets se normalisent, les nombres hexadécimaux arrivent avec la même valeur en décimal.
Vous pouvez constater la frontière vous-même : collez un fichier JSON5 dans un validateur strict et la première erreur pointe la construction qui l’a franchie — un commentaire, un guillemet, une virgule finale. Le diagnostic marche aussi dans l’autre sens : si un fichier de configuration doit un jour être lu par un outillage strict, gardez-le dans le sous-ensemble strict dès le premier jour, car la rétrogradation est le trajet qui perd des données.
Quand choisir l’un ou l’autre
Choisissez JSON par défaut et ne vous tournez vers JSON5 qu’avec une raison. La raison, c’est un fichier entretenu par des humains et simplement consommé par des machines — configuration de build, feature flags, définitions d’environnement — associé à une chaîne d’outils qui analyse déjà JSON5 nativement. Si vos consommateurs sont inconnus, externes ou appelés à durer, la rigidité n’est pas de la bureaucratie ; c’est le contrat d’interface.
La recommandation s’inverse proprement : un fichier de configuration qui n’a jamais eu besoin d’un seul commentaire n’a pas besoin de JSON5 non plus, et un fichier JSON5 qu’un service s’est mis à analyser à l’exécution est devenu discrètement un format filaire — ce qui signifie qu’il veut redevenir du JSON.
Questions fréquentes
Puis-je formater ou valider du JSON ici sans envoyer le fichier ?
Oui. Le formateur et le validateur s’exécutent entièrement dans votre onglet de navigateur — l’analyse utilise le moteur JSON du navigateur lui-même, d’après la RFC 8259, aucune requête ne quitte la page, la Content-Security-Policy du site bloque les appels sortants et le panneau Network de DevTools reste silencieux. Les fichiers de configuration ne quittent jamais votre machine. Le JSON strict se valide ; les extensions JSON5 apparaissent comme des erreurs de syntaxe qui nomment la construction exacte.
JSON5 est-il une norme officielle ?
Pas au sens d’une RFC. Il est spécifié sur json5.org et adossé à son implémentation de référence et à sa communauté, là où JSON a la RFC 8259 et ECMA-404. En pratique, cela veut dire aucun langage de conformité, aucun registre, et une interopérabilité garantie uniquement par le partage du même parseur — l’inverse de la promesse de JSON, « n’importe quel parseur fera l’affaire ».
Pourquoi JSON ne prend-il pas en charge les commentaires ?
Douglas Crockford les a retirés délibérément en normalisant le format : des éditeurs avaient commencé à incruster des directives d’analyse dans les commentaires, ce qui cassait l’interopérabilité entre implémentations. Un format d’échange de données doit signifier la même chose pour chaque lecteur, donc la grammaire est restée minimale. Les conventions survivantes sont des clés voisines comme "_comment", ou JSONC quand la chaîne d’outils le permet.
JSON.parse sait-il traiter du JSON5 ?
Non — il lève une exception au premier commentaire, au premier guillemet simple, à la première clé sans guillemets ou à la première virgule finale, ce qui disqualifie immédiatement la plupart des fichiers JSON5 réels. Il vous faut la bibliothèque JSON5, ou d’abord une réécriture en JSON strict. Méfiez-vous aussi du piège JSONC : un parseur qui accepte commentaires et virgules finales n’est toujours pas un parseur JSON5, et il rejettera les guillemets simples et les nombres hexadécimaux.
La conversion de JSON5 vers JSON perd-elle des données ?
Les commentaires, oui — ils n’ont aucune représentation JSON légale, donc tout convertisseur les écarte de par sa conception. Infinity, -Infinity et NaN perdent leurs valeurs et deviennent null ou des chaînes selon le convertisseur. Tout le reste survit : les clés sans guillemets en gagnent, les guillemets simples deviennent doubles, les nombres hexadécimaux arrivent avec la même valeur en décimal. Si les commentaires comptent, le fichier doit rester là où ils sont légaux.
Ma configuration doit-elle être en JSON5 ou en YAML ?
Si votre chaîne d’outils parle déjà JSON5, restez-y — migrer coûte plus cher que ne valent les commentaires. Pour un départ à neuf, YAML est le format de configuration humaine le plus éprouvé, avec ses scalaires en bloc, ses ancres pour la réutilisation et une décennie d’outillage, au prix d’une sensibilité à l’indentation et d’une inférence de types. L’avantage de JSON5 : il reste à un petit pas du JSON strict, donc promouvoir une configuration en données machine est trivial.
Où puis-je lire les normes citées ici ?
Quels outils liés devriez-vous utiliser ensuite ?
- Formater du JSONIndente, trie les clés et supprime les commentairesOuvrir
- Valider du JSONVérifie la syntaxe avec ligne et colonne exactes, puis répareOuvrir
- Qu’est-ce que le JSONGuide en langage clairOuvrir
- JSON vs YAMLComparatif point par pointOuvrir
- Comment fonctionne Base64Guide en langage clairOuvrir
- Outils JSONComparez, formatez, validez et explorez des documents JSON.Ouvrir