JSON vs JSON5 vs JSONC
L’essentiel : Des surensembles stricts, dans l'ordre : JSONC ajoute les commentaires ; JSON5 ajoute guillemets simples, clés sans guillemets, virgules finales et nombres hexadécimaux. Mal choisir casse une API, pas votre éditeur.
L'essentiel : utilisez du JSON standard chaque fois que des données franchissent une frontière système, et JSONC seulement pour la configuration locale que des humains éditent ; recourez à JSON5 quand il faut des guillemets simples, des virgules finales ou des clés sans guillemets, mais confirmez d'abord que le chargeur le prend en charge.
En une ligne : JSONC est JSON plus les commentaires ; JSON5 est JSON plus les habitudes JavaScript.
Matrice des fonctionnalités
| Fonctionnalité | JSON | JSONC | JSON5 |
|---|---|---|---|
| Chaînes entre guillemets doubles | ✅ | ✅ | ✅ |
| Chaînes entre guillemets simples | ❌ | ❌ | ✅ |
| Clés sans guillemets | ❌ | ❌ | ✅ |
Commentaires de ligne // |
❌ | ✅ | ✅ |
Commentaires de bloc /* */ |
❌ | ✅ | ✅ |
| Virgules finales | ❌ | ❌ | ✅ |
Nombres hexadécimaux 0xFF |
❌ | ❌ | ✅ |
Infinity / NaN |
❌ | ❌ | ✅ |
| Chaînes multi-lignes | ❌ | ❌ | ✅ |
| Lisible par les parseurs standard | ✅ | ❌ | ❌ |
Notez que JSONC ne résout que les commentaires. Beaucoup supposent que « du JSON qui autorise les commentaires » autorise aussi les virgules finales ; tsconfig.json échoue encore sur l'une.
À quoi sert chacun
JSON — l'échange. API, files, colonnes JSON de bases de données, journaux. Tout ce qui est machine-à-machine.
JSONC — la configuration d'éditeur. VS Code parse lui-même ces fichiers, donc JSON.parse ne les voit jamais. Il n'y a pas de RFC ; c'est une convention de facto menée par Microsoft.
JSON5 — un surensemble indulgent pour les humains. L'objectif était « une configuration qui ressemble à un littéral d'objet JavaScript ». Adapté aux fichiers .json5 chargés par des outils de build ; la syntaxe la plus large et le support d'outillage le plus étroit.
Choisir
| Situation | Choix |
|---|---|
| Corps de requête ou de réponse | JSON, pas d'alternative |
| Colonnes JSON dans MySQL / PostgreSQL | JSON, leurs fonctions n'acceptent rien d'autre |
| Configuration de projet qui a besoin d'explications | JSONC si pris en charge, sinon YAML |
| Vous voulez la laxisme de style JS | JSON5, après avoir confirmé le support du chargeur |
| Des non-ingénieurs vont l'éditer | YAML, l'indentation bat les accolades |
Un piège facile
Parser un fichier JSONC comme du JSON strict produit une erreur qui pointe le commentaire :
SyntaxError: Unexpected token / in JSON at position 42
Avant de supprimer le commentaire, vérifiez si le fichier est censé être du JSONC. Supprimez-le et vous pourriez encore heurter une virgule finale deux lignes plus loin.
FAQ
Comment choisir entre JSONC et JSON5 ?
Utilisez JSONC quand les commentaires sont la seule chose nécessaire : il ajoute // et /* */ par-dessus JSON, et settings.json et tsconfig.json de VS Code l'utilisent. Utilisez JSON5 quand vous voulez aussi guillemets simples, clés sans guillemets, virgules finales, nombres hexadécimaux ou chaînes multi-lignes. Les deux dépendent du chargeur, donc confirmez que l'outil qui lit le fichier le prend en charge.
Pourquoi un fichier JSONC ne peut-il pas être lu comme du JSON standard ?
JSONC est une convention de facto, pas une RFC séparée, donc les parseurs standard rejettent les commentaires. JSON.parse sur un tel fichier lève Unexpected token /, pointant le commentaire plutôt que les données. Seule la configuration lue par un éditeur ou un parseur dédié devrait être écrite en JSONC.
Faut-il envoyer un fichier JSON5 à une API ?
Non. Les API, colonnes JSON de bases de données et files parsent du JSON strict, donc les guillemets simples, clés sans guillemets et virgules finales de JSON5 sont rejetés. JSON5 est pour la configuration locale que des humains éditent ; convertissez-le en JSON standard avant qu'il franchisse une frontière système.