Name: Tremplin Numérique
Price range: $$$

JSON est devenu un format de données quasi omniprésent, utilisé dans les réponses API, la sauvegarde des fichiers de jeu et la configuration. Mais beaucoup de gens pensent qu’il pourrait être amélioré, et diverses tentatives ont été faites pour l’étendre ou l’améliorer. JSONC est l'une de ces tentatives.

Sommaire

Qu'est-ce que JSONC et pourquoi a-t-il été créé ?

JavaScript Object Notation (JSON) est un format de texte lisible par l'homme pour le stockage de données structurées, utilisant des paires nom-valeur, des tableaux et des valeurs scalaires. Il a été fortement influencé par la syntaxe JavaScript (d'où son nom), mais est désormais utilisé par presque tous les langages de programmation, dans de nombreux types d'environnements différents, comme format neutre pour l'échange de données.

Malgré sa popularité, JSON a ses critiques. Les plaintes les plus courantes concernent sa syntaxe, et elles sont généralement l'une des suivantes :

Il n'autorise pas les commentaires.
Il n'autorise pas les virgules de fin (une virgule après le dernier élément d'un tableau ou la dernière propriété d'un objet).
Cela nécessite que les clés (noms de propriété) soient entre guillemets.
Il ne prend pas en charge les chaînes multilignes.

En d’autres termes, il s’agit d’un JSON invalide :

        {
theme: "light",description: "This is a description
wrapped over multiple lines for ease
of reading",

tab-width: 8,
}

Au lieu de cela, ces données doivent être écrites comme ceci :

        {
"theme": "light","description": "This is a description wrapped over multiple lines for ease of reading",
"tab-width": 8
}

JSONC est une tentative, parmi tant d’autres, d’améliorer JSON. D'autres formats qui tentent de faire quelque chose de similaire incluent YAML et JSON5. Chacun d'eux est un sur-ensemble de JSON, donc un JSON valide est également un JSONC, YAML et JSON5 valides. Les formats diffèrent dans la mesure dans laquelle ils tentent d'étendre la syntaxe de JSON.

YAML apporte des changements importants et a trouvé une niche dans la configuration et, occasionnellement, dans la documentation. Le format est un peu hybride entre Markdown et JSON, avec une indentation pour l'imbrication, des types de données personnalisés et des chaînes multilignes. YAML est utilisé par des projets tels que Docker Compose, les workflows dans GitHub Actions et le framework Ruby on Rails.

JSON5, quant à lui, est un JavaScript valide, comme JSON, il adhère donc plus strictement à cette syntaxe. JSON5 vise à résoudre toutes les plaintes ci-dessus concernant JSON, et plus encore, mais il reste très similaire à JSON. JSON5 est utilisé dans la programmation Chromium, Next.js et macOS.

JSONC, en revanche, est « JSON avec commentaires », il se concentre donc entièrement sur l'autorisation des commentaires dans les données JSON. Cela signifie qu'il prend en charge un hybride des deux exemples précédents :

            {
	// One of "dark", "light", or "auto"
	"theme": "light",

	/*
   I like LOADS
   of spaces!
   */
	"tab-width": 8
}

JSONC prend en charge deux formes courantes de commentaires :

Les commentaires en ligne commencent par // et ne durent que jusqu'à la fin de leur ligne.
Les commentaires de bloc commencent par /* et se terminent par */ et peuvent contenir n'importe quel nombre de lignes.

La troisième forme courante de commentaire (identique au commentaire en ligne, mais commençant par un seul caractère « # ») n'est pas prise en charge.

Quels sont les avantages et les inconvénients de JSONC ?

JSONC est beaucoup moins populaire que JSON, ce qui est en soi un inconvénient. Alors, qu’apporte JSONC, et est-ce suffisant pour que le format alternatif connaisse le succès ?

Premièrement, je pense personnellement que les commentaires sont une plus grande victoire que la résolution des autres plaintes JSON courantes. Les modifications apportées à la syntaxe pour gérer les guillemets et les virgules peuvent rendre les choses plus pratiques, mais elles n'apportent pas d'avantages aussi fondamentaux. Les commentaires dans les fichiers JSON ont deux utilisations importantes :

Fichiers de configuration : les commentaires peuvent servir d'exemples ou de texte d'aide dans les modèles de configuration, et ils peuvent également être utilisés pour expliquer pourquoi une configuration particulière a été choisie.
Annotation des données : les développeurs peuvent inclure des commentaires à côté des données pour expliquer leur objectif ou comment elles interagissent avec d'autres données.

Les commentaires peuvent également être utilisés pour désactiver temporairement des sections de code, par exemple dans les fichiers de code source, à des fins de débogage ou de test. Mais cette utilisation est moins courante dans les fichiers de données, comme JSON, car ils pourraient facilement créer de la confusion lors de la transmission de données entre différentes sources.

Les commentaires fournissent un moyen de documentation autonome ; sans eux, les fichiers JSON doivent être expliqués ailleurs, dans un endroit qui pourrait ne pas être évident ou facilement accessible. Une autre solution possible consiste à ajouter des données « factices », par exemple :

            {
   "theme-comment": "The theme value should be one of 'dark', 'light', or 'auto'",
   "theme": "dark"
}

Bien que cela puisse fonctionner, cela est fragile car cela dépend du fait que tout système lisant ces données ignore les clés qu'il ne reconnaît pas.

Gardez toutefois à l’esprit que les commentaires ne sont pas universellement bénéfiques. Douglas Crockford, le spécificateur original de JSON, est probablement la meilleure personne pour faire valoir cet argument :

J'ai supprimé les commentaires de JSON parce que j'ai vu que des gens les utilisaient pour contenir des directives d'analyse, une pratique qui aurait détruit l'interopérabilité.

En d’autres termes, les commentaires sont propices aux abus, ce que leur interdiction prévient.

Il ne gère pas les virgules finales ni les clés sans guillemets

Comme je l'ai expliqué plus haut, je considère cela comme moins important, mais cela reste un inconvénient mineur. Si nous essayons de réparer JSON avec une mise à niveau rétrocompatible, autant réparer tout ce que nous pouvons.

Les virgules de fin sont plus faciles à maintenir, ce qui entraîne moins de bogues et des correctifs plus propres. JSON ne les autorise pas pour des raisons historiques liées à la syntaxe désordonnée de JavaScript. Mais nous pouvons résoudre ce problème dès maintenant, et nous devrions probablement le faire, même si les avantages sont minimes.

JSONC n'est pas compatible avec JSON

Bien que JSONC soit un sur-ensemble de JSON, donc tout JSON valide est également un JSONC valide, cela ne fonctionne pas dans l'autre sens. La plupart des outils nécessitant JSON échoueront si vous essayez de les utiliser avec un fichier JSONC :

Cela ne pose peut-être pas de problème pour votre propre usage, mais cela rend l'adoption généralisée de JSONC encore plus difficile.

C'est difficile de prétraiter

L'interopérabilité pose moins de problèmes si JSONC peut être facilement converti en JSON. Vous pouvez utiliser l'outil JSMin de Douglas Crockford pour faire exactement cela. Mais la syntaxe de commentaire choisie par JSONC signifie qu'il doit s'agir d'un analyseur JSON à part entière pour garantir que les commentaires sont correctement reconnus dans leur contexte.

Si, à la place, les commentaires étaient indiqués par un seul caractère « # » dans la colonne 0, un convertisseur serait trivial :

        '^#' >output.json

Cela signifierait que n'importe quel analyseur JSON pourrait facilement être mis à jour pour prendre en charge JSONC, plutôt que d'avoir à apporter des modifications de code plus importantes ou à s'appuyer sur un programme tiers comme JSMin.

Comment puis-je utiliser JSONC aujourd’hui ?

Le plus souvent, vous rencontrerez JSONC lorsque vous devrez modifier une configuration. Par exemple, le programme fastfetch lit un fichier de configuration au format JSONC, vous pouvez donc l'annoter avec des notes, des suggestions ou tout ce que vous souhaitez ajouter.

Si vous travaillez avec votre propre code et souhaitez écrire quelque chose qui gère aussi bien JSONC que JSON, vous disposez de deux options principales. Tout d’abord, vous pouvez utiliser un outil comme JSMin et gérer JSONC exactement de la même manière que vous traitez déjà JSON.

Vous pouvez également utiliser une bibliothèque qui gère JSONC, supprimant ainsi la dépendance à un programme distinct. Le code fastfetch utilise yyjson, une bibliothèque C qui gère les commentaires JSONC ainsi que les virgules de fin et bien plus encore. Le node-jsonc-parser de Microsoft fait une chose similaire pour JavaScript et prend également en charge les virgules de fin.