Rassemble les questions les plus fréquentes sur les outils de ce site et sur la spécification JSON, regroupées par scénario, avec une réponse directement actionnable plutôt qu'une conclusion vague.
25 articlesLes données sont-elles téléversées, quelle taille de fichier fonctionne, quelque chose est-il stocké localement, pourquoi le chinois devient-il des échappements : dix questions qui explicitent les vraies frontières d'un outil JSON en ligne.
Les commentaires sont-ils autorisés, pourquoi une virgule finale erre, les clés ont-elles besoin de guillemets, pourquoi 9007199254740993 change — douze conclusions, chacune vérifiée contre la RFC 8259.
Les requêtes de chemin doivent-elles utiliser JSONPath ou Pointer, comment choisir entre Patch et Merge Patch, ce que Schema peut bloquer, et comment choisir une version de draft — tout expliqué en une passe.
Pourquoi un fichier JSON de dizaines de Mo ne s'ouvre pas, combien coûte un clonage profond, comment empêcher la pollution par __proto__, et où le XSS entre — dix conclusions de premiers secours classées par symptôme.
Style de nommage, formats de temps, sémantique de null, formes d'énumération, formats de configuration, organisation des fixtures et conflits de fusion — douze compromis sur lesquels les équipes se disputent réellement.
La RFC 8259 n'a aucune syntaxe de commentaire, donc // et les commentaires de bloc font lever JSON.parse. Utilisez plutôt JSON5 ou JSONC, un champ _comment, une description de Schema, ou YAML.
Les virgules finales sont légales dans les littéraux d'objet JavaScript et fatales en JSON. Voici l'erreur exacte, la grammaire RFC 8259 qui la cause, et trois corrections qui tiennent vraiment.
Un BOM UTF-8 est trois octets invisibles, donc JSON.parse échoue au premier caractère et rapporte ligne 1 colonne 1, ce qui fait paraître le fichier vide ou tronqué.
JSON n'a que des littéraux numériques décimaux. JSON.stringify transforme NaN et Infinity en null sans prévenir, ce qui explique pourquoi « le champ numérique est parfois null » revient sans cesse en production.
Les entiers au-delà de 2^53-1 perdent de la précision dans JSON.parse. Les identifiants snowflake, numéros de commande et bigints de base de données y sont tous exposés, donc gardez-les en chaînes de bout en bout.
Un échappement \u4e2d\u6587 est de l'Unicode légal, pas un échec d'encodage. Le vrai mojibake est différent, et les distinguer décide de ce qu'il faut réellement corriger.
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.
JSON délimite avec des accolades et YAML avec l'indentation : JSON pour les machines, YAML pour les humains qui éditent de la configuration. Commentaires, ancres et structure multi-documents ne survivent pas.
JSON Pointer est une adresse unique que vous pouvez stocker comme clé ; JSONPath est un langage de requête. Utiliser le mauvais casse les mises à jour de configuration ou réinvente un JSONPath bancal.
Schema régit la structure et les types, pas le sens métier. Il bloque les champs manquants, les types faux et les énumérations hors plage, tandis que des règles comme un montant supérieur à zéro restent dans le code.
2020-12 est la version courante et ajoute $defs, prefixItems et unevaluatedProperties, mais beaucoup d'outils ne parlent encore que draft-07. Choisissez selon ce que toute votre chaîne d'outils prend en charge.
json-schema-to-typescript et quicktype émettent un .d.ts en une commande, mais c'est un brouillon : caractère facultatif, unions, additionalProperties et dates demandent une passe humaine.
Optimiser dans le mauvais ordre rend tout échange de bibliothèque inutile. Mesurez séparément réseau, parsing et rendu, puis réduisez les parsings, diminuez les charges utiles et passez au flux.
JSON.parse traite __proto__ comme une clé ordinaire ; les dégâts surviennent dans une fusion récursive qui écrit dans Object.prototype, donc chaque objet hérite des propriétés de l'attaquant.
JSON ne s'exécute jamais de lui-même. Le XSS survient au moment où vous le traitez comme du HTML — concaténation de chaînes côté serveur, innerHTML frontend, ou intégration directe de JSON dans une balise script.
Vous n'avez pas besoin de lire une politique de confidentialité pour le savoir. Ouvrez le panneau réseau, essayez la page hors ligne, et rafraîchissez pour voir si quelque chose a persisté. Deux minutes, trois vérifications, aucune confiance requise.
Il n'y a pas de limite fixe ; la contrainte est le budget mémoire de votre onglet. Un fichier de 20 Mo devient typiquement 60 à 100 Mo une fois parsé, et le DOM surligné peut encore doubler cela.
Les objets nus sont propres jusqu'à ce qu'il faille des métadonnées ; les enveloppes complètes sont sûres mais verbeuses. Pour la plupart des projets, utilisez le statut HTTP pour les résultats et une enveloppe stable pour les données.
Les nombres epoch et les chaînes ISO ont chacun leurs compromis, mais c'est les mélanger qui casse réellement les choses. Utilisez ISO 8601 avec un offset, stockez en UTC, affichez dans le fuseau de l'utilisateur.
`null` dit que le champ existe sans valeur ; omettre dit que le champ n'existe pas. Corps PATCH, fusion de configuration et préremplissage de formulaire sont là où la différence mord.
