Comparaison des bibliothèques de parsing et de traitement JSON

L'essentiel : classez d'abord le besoin, puis comparez les implémentations — utilisez JSON.parse natif pour des valeurs en lecture seule, jsonc-parser quand il faut des offsets ou préserver le formatage original, et ajoutez des bibliothèques de requête ou de patch seulement là où c'est nécessaire ; chargez paresseusement les grosses bibliothèques par page et abandonnez celles qui ne sont plus maintenues.

Chaque bibliothèque affirme être « rapide, petite et complète ». Ce qui les sépare réellement, c'est la quantité d'informations qu'elles peuvent vous donner quand quelque chose va mal.

1. Quatre catégories par objectif

Identifiez d'abord la catégorie dans laquelle vous êtes, puis comparez les implémentations concrètes — sinon il est facile d'utiliser une bibliothèque de requête pour faire le travail d'un parseur.

2. Comparaison côte à côte

Les messages d'erreur de JSON.parse varient beaucoup entre moteurs. V8 produit quelque chose comme Unexpected token } in JSON at position 42, mais l'exactitude de la position dépend de la version du moteur ; jsonc-parser renvoie plutôt un { error, offset, length } structuré et stable, adapté aux marqueurs d'éditeur.

3. Quatre points de décision clés

3.1 Avez-vous besoin d'offsets

Si vous construisez un éditeur et voulez « cliquer sur l'erreur pour sauter à la ligne correspondante », il vous faut un offset. Le test est simple : si votre message d'erreur ne peut imprimer que « JSON invalide », les utilisateurs devront le chercher eux-mêmes.

复制import { parse, printParseErrorCode } from 'jsonc-parser';

const errors: Array<{ error: number; offset: number; length: number }> = [];
parse(text, errors, { allowTrailingComma: true, disallowComments: false });

if (errors.length > 0) {
  const firstError = errors[0];
  console.error(`${printParseErrorCode(firstError.error)} at offset ${firstError.offset}`);
}

3.2 Avez-vous besoin de préserver le texte original

Lire seulement des valeurs → n'importe quel parseur convient. « Changer un champ et laisser tout le reste exactement tel quel » → il faut une API de style édition, pas « parser → changer l'objet → sérialiser ».

Cette dernière perd : les commentaires, l'ordre des clés (dans certaines implémentations), le style d'indentation, la notation littérale des nombres (1e3 devient 1000), et les formes d'échappement (\u4e2d devient le caractère réel).

3.3 Les comportements limites sont-ils explicites

Avant de choisir une bibliothèque, vérifiez trois choses dans la documentation :

1. Comment sont gérées les clés dupliquées (garder la dernière / lever une erreur) ;
2. Si les grands entiers perdent de la précision (la plupart des bibliothèques JS le font, car elles passent toutes par Number) ;
3. La portée prise en charge pour le BOM, les commentaires et les virgules finales.

S'il n'y a pas de documentation, écrivez un petit échantillon et testez-le vous-même. C'est plus fiable que de lire le README.

3.4 État de maintenance

Le risque d'une bibliothèque JSON n'est pas des fonctionnalités manquantes, mais un abandon de longue durée : plus personne ne livrera de correctifs de sécurité (pollution de prototype, ReDoS).

4. Comparaison avec d'autres langages

Lors d'échanges de données entre langages, les choses les plus faciles à heurter restent la précision des nombres et les formats de temps ; le choix de bibliothèque ne peut que les atténuer, pas les éliminer.

5. Combinaisons typiques

Option 1 : site d'outils (côté navigateur)

复制Parsing and error location: jsonc-parser
Editor: CodeMirror 6 + @codemirror/lang-json
Query: jsonpath-plus
Patch: fast-json-patch
Share links: lz-string

Le trait distinctif de cette combinaison est que tout tourne localement et aucune donnée n'est téléversée, ce qui correspond aux attentes de confidentialité d'un site utilitaire.

Option 2 : passerelle d'API côté serveur

复制Validation: Ajv (compile the schema once, reuse it)
Parsing: native JSON.parse (together with a body size limit)
Deferred parsing of large fields: keep the raw string, parse only when needed

N'introduisez pas de bibliothèques de requête/patch dans la couche passerelle pour implémenter de la logique métier — c'est le travail de la couche métier.

Option 3 : CLI et scripts

复制Pick fields: jq
Format conversion: yq / dasel
Interactive browsing: jless
Batch validation: ajv-cli

6. L'impact réel de la taille de bundle et des performances

• jsonc-parser est très petit et convient au bundle principal ;
• json5 est un peu plus gros que jsonc-parser car il prend en charge plus de syntaxe ;
• jsonpath-plus inclut l'évaluation d'expressions et est nettement plus gros, donc il devrait être chargé paresseusement par page ;
• fast-json-patch est de taille moyenne et n'est nécessaire que si vous avez une fonction de comparaison.

L'optimisation est simple : importez dynamiquement par page, et ne les mettez pas dans le chunk du premier écran.

复制const { JSONPath } = await import('jsonpath-plus');

7. Liste de vérification

• [ ] Choisissez les bibliothèques par objectif ; n'utilisez pas une bibliothèque de requête pour le parsing ;
• [ ] Utilisez jsonc-parser quand il faut des localisations d'erreur précises ;
• [ ] Utilisez des API de style édition quand commentaires et formatage doivent être préservés ;
• [ ] Testez en pratique les trois comportements limites : clés dupliquées, grands entiers et BOM ;
• [ ] Surveillez l'état de maintenance de la bibliothèque et les avis de sécurité ;
• [ ] Importez dynamiquement les grosses bibliothèques à la demande.

FAQ

Comment choisir une bibliothèque JSON selon la taille de mon projet ?

Les petits outils qui ne lisent que des données d'API peuvent rester sur JSON.parse natif. Les projets qui ont besoin de localisations d'erreur de qualité éditeur ou qui doivent préserver le formatage original devraient utiliser jsonc-parser. Une passerelle côté serveur n'a besoin que de validation et de parsing, laissant les bibliothèques de requête et de patch à la couche métier, tandis que les scripts CLI peuvent utiliser directement jq, yq et ajv-cli.

Pourquoi l'état de maintenance compte-t-il plus que le nombre de fonctionnalités ?

Le vrai risque d'une bibliothèque JSON est l'abandon de longue durée, pas des fonctionnalités manquantes : personne ne livrera de correctifs de sécurité pour la pollution de prototype ou le ReDoS. Aussi complète que soit la liste de fonctionnalités, une bibliothèque à l'arrêt vous laisse la rafistoler vous-même. Traitez la maintenance et les avis de sécurité comme des critères durs plutôt que de comparer des tableaux de fonctionnalités.

Faut-il utiliser JSON.parse pour changer un champ en gardant commentaires et indentation ?

Non. Parser, changer l'objet, puis sérialiser perd les commentaires, l'ordre des clés, le style d'indentation, la notation littérale des nombres (1e3 devient 1000), et les formes d'échappement (\u4e2d devient le caractère réel). Changer un champ en gardant tout le reste intact exige une API de style édition comme modify et applyEdits dans jsonc-parser.