Comparateur JSON (Diff)

Un diff de texte (comme le Vérificateur de différences de texte de ce site) compare deux blocs de texte ligne par ligne - il ne sait pas ce qu'est du JSON, donc reformater un document, réordonner ses clés ou changer l'indentation fait apparaître un mur de lignes modifiées même quand les données sous-jacentes sont identiques. Cet outil analyse d'abord les deux côtés comme du vrai JSON, puis compare les structures obtenues - ainsi {"a":1,"b":2} et une version formatée avec « b » listé avant « a » sont correctement signalées comme n'ayant aucune différence. Seuls les vrais ajouts, suppressions et changements de valeur sont affichés.

« Modifiée » signifie que la valeur à ce chemin est toujours du même type JSON mais a une valeur différente - un nombre passé de 5 à 6, ou une chaîne passée de « brouillon » à « publié ». « Type modifié » signifie que le type lui-même est différent - un champ qui était un booléen est maintenant une chaîne, ou un nombre est devenu null. Cette distinction compte beaucoup en pratique : un changement de type a bien plus de chances de casser du code qui lit ce champ (une fonction attendant un booléen se comportera mal si elle reçoit soudain une chaîne), donc cet outil le signale séparément plutôt que de le confondre avec une simple mise à jour de valeur.

Élément par élément, dans l'ordre : l'index 0 contre l'index 0, l'index 1 contre l'index 1, et ainsi de suite, tout élément supplémentaire à la fin du tableau le plus long étant signalé comme ajouté ou supprimé. C'est simple et prévisible, mais cela signifie qu'insérer un nouvel élément au milieu d'un tableau fera apparaître tous les éléments suivants comme modifiés, même s'ils sont en réalité identiques - car ils ont tous été décalés d'une position. C'est une vraie limite de la comparaison de tableaux basée sur la position en général (pas seulement de cet outil), donc pour les tableaux dont l'ordre peut changer, il est souvent utile de vérifier si les éléments signalés « modifiés » sont vraiment différents ou juste déplacés.

L'erreur d'analyse exacte produite par l'analyseur JSON de votre propre navigateur s'affiche sous cette zone de texte, plutôt que d'échouer silencieusement ou d'afficher un résultat périmé. Les causes courantes sont une virgule superflue après le dernier élément d'un objet ou d'un tableau (valide dans les littéraux d'objet JavaScript, invalide en JSON), des guillemets manquants autour d'un nom de clé, ou un commentaire égaré - le JSON n'a aucune syntaxe de commentaire, contrairement à JavaScript ou JSON5.

Oui, et c'est l'un des usages les plus utiles : collez une réponse capturée avant un changement et une capturée après, et chaque champ ajouté, supprimé ou - point crucial - ayant changé de type est signalé. Un champ passant silencieusement d'un nombre à une chaîne, ou d'un booléen à null, est exactement le genre de changement cassant facile à manquer à l'œil nu dans deux gros payloads mais qui apparaît immédiatement ici comme une entrée « type modifié » distincte.

Non, jamais - deux objets JSON avec les mêmes clés et valeurs sont traités comme identiques quel que soit l'ordre dans lequel ces clés sont écrites, puisque JSON lui-même ne définit aucune signification pour l'ordre des clés. Cela signifie aussi qu'un document JSON minifié sur une seule ligne et une version joliment indentée des mêmes données exactes afficheront correctement zéro différence ici.

Non. Les deux documents sont analysés et comparés entièrement dans votre navigateur en JavaScript pur - rien n'est envoyé à un serveur, donc vous pouvez coller sans risque de vraies réponses d'API, des fichiers de configuration ou d'autres données que vous ne voudriez pas voir quitter votre machine.

L'outil gère confortablement les réponses d'API et fichiers de configuration classiques - de quelques lignes à plusieurs milliers - puisque toute la comparaison s'exécute de façon synchrone dans votre onglet de navigateur. Pour des documents vraiment énormes (des dizaines de mégaoctets), le parcours récursif de chaque clé et index de tableau peut devenir perceptiblement lent ; si cela arrive, il est souvent utile de réduire les deux documents à la seule section qui vous intéresse avant de les comparer.

Ils répondent à des questions différentes et fonctionnent bien ensemble plutôt que comme des substituts. Un diff de contrôle de version est textuel - il montre les lignes exactes qui ont changé dans le fichier, y compris un reformatage, une réindentation, ou un linter réordonnant les clés, rien de tout cela n'étant considéré comme une vraie différence ici. Cet outil répond à une question plus précise, souvent plus utile après qu'un formateur ou un fichier généré automatiquement a touché quelque chose : la configuration a-t-elle vraiment changé, ou seulement sa mise en forme ? Exécuter les deux ensemble sur un commit suspect est un moyen rapide de distinguer « rien à craindre, juste reformaté » de « ceci change vraiment le comportement ».

Ça fonctionne quand même - si le niveau le plus haut diffère en forme (un objet d'un côté, un tableau de l'autre, ou une valeur primitive face à l'un ou l'autre), cela est signalé comme une seule différence au niveau racine plutôt que l'outil ne force une comparaison qui n'a pas de sens. La même logique qui signale le changement de type d'un champ imbriqué s'applique à la racine : c'est traité comme le type de différence le plus fondamental que deux documents JSON puissent avoir.

Seulement comme effet secondaire - chaque côté est analysé pour être comparé, donc un document invalide affiche une erreur d'analyse plutôt que de comparer silencieusement rien. Mais le rôle de cet outil est de comparer deux documents déjà valides en JSON, pas de reformater ou corriger automatiquement l'un d'eux. Si vous devez valider, reformater ou minifier un seul document JSON, le Formateur et validateur JSON de ce site est conçu spécifiquement pour cela et constitue une première étape naturelle avant de coller un document ici.