Comment comparer deux documents JSON

Collez le document d’origine à gauche, la version modifiée à droite, cliquez sur Comparer : la page signale chaque valeur ajoutée, supprimée ou modifiée avec son chemin — 7 143 changements entre deux objets de 50 000 clés, dans l’ordre du parcours.

Le résultat est un JSON Patch (RFC 6902) qui transforme le premier document en second : un tableau d’opérations add, remove et replace portant des chemins JSON Pointer. Les deux zones sont analysées et comparées dans la page : rien n’est envoyé, et la comparaison continue de fonctionner une fois le réseau coupé.

Collez le document avant dans la zone de gauche et le document après dans celle de droite. Charger l’exemple remplit les deux avec une petite paire pour voir d’abord la forme du résultat.
Cliquez sur Comparer. Les compteurs apparaissent au-dessus de la liste — ajoutés, supprimés, modifiés — et chaque ligne porte le pointeur vers la valeur ainsi qu’un aperçu limité à 120 caractères.
Lisez le patch en dessous : le document RFC 6902 complet, indenté, prêt à être collé dans une suite de tests, un script de migration ou une requête HTTP PATCH.
Copier le patch le place dans le presse-papiers et Effacer vide les deux zones. Si une zone ne peut pas être analysée, la ligne d’état indique quel document échoue — Before JSON ou After JSON — avec la position de l’erreur, et le résultat précédent est abandonné.

Ce que dit le patch, et ce qu’il ne dit pas

Ce qui compte comme différence

L’ordre des clés n’est pas une différence : {"a":1,"b":2} face à {"b":2,"a":1} donne 0 changement. Les nombres sont comparés comme des doubles JavaScript : 1 et 1.0 sont donc la même valeur, alors que 1e2 arrive sous forme de 100 et ressort comme un changement.

Les types ne sont jamais convertis : 1 face à "1" est un changement, true face à 1 aussi, et une clé valant null n’équivaut pas à une clé absente — null dans le premier document et absent du second donne remove /a plutôt qu’une correspondance. Les clés en double conservent la dernière valeur, la zone étant lue par JSON.parse : {"a":1,"a":2} face à {"a":2} annonce 0 changement.

Les tableaux sont comparés par index

Le résultat ne contient aucune opération move. Un tableau est parcouru position par position : une réorganisation apparaît donc comme une suite de replace — [1,2] face à [2,1] donne replace /0 par 2 puis replace /1 par 1.

Les changements de longueur partent de la fin : [1,2,3,4] face à [1,2] supprime d’abord /3 puis /2, et [1,2] face à [1,2,3,4] ajoute /2 puis /3. Cet ordre garde chaque opération valide lorsque le patch est appliqué de haut en bas.

Pointeurs, échappements et clés vides

Chaque chemin est un JSON Pointer conforme à la RFC 6901. Une clé contenant une barre oblique ou un tilde est échappée : a/b devient /a~1b et c~d devient /c~0d.

Une clé vide reçoit elle aussi un pointeur — le chemin vaut / — et le document racine a le chemin vide : le remplacer entièrement tient donc en une seule opération avec path "".

Où s’exécute la comparaison

L’analyse et la comparaison se font dans la page. Au chargement de l’outil puis lors de la comparaison de deux objets de 50 000 clés, aucune requête n’est partie en dehors des ressources de la page : les documents ne quittent pas le navigateur, et l’outil fonctionne hors ligne une fois chargé.

Les limites de l’analyseur JSON s’appliquent : au-delà de 2^53, les entiers perdent en précision, si bien que 9007199254740993 et 9007199254740992 sont jugés identiques, et une imbrication de 20 000 niveaux a été comparée puis patchée sans erreur. Le temps dépend du nombre de changements : 50 000 clés ont demandé une demi-seconde pour un patch de 511 Ko, 500 000 clés environ cinq secondes pour 5,25 Mo. Relisez le patch avant de l’appliquer à des données de production.