Comparer du JSON
Le Comparateur JSON est un moteur de comparaison sémantique côté client qui analyse des payloads JSON en arbres de syntaxe abstraite (AST), en ignorant totalement l’ordre des clés et les espaces non significatifs. Il propose un appariement configurable des tableaux par clé primaire, une classification distincte des changements de type, une exécution en Web Worker capable de traiter jusqu’à 100 MB de JSON sans figer l’onglet, un export et une application bidirectionnels de JSON Patch RFC 6902, et une fusion à trois (three-way merge) sur activation qui rapproche deux branches par rapport à un ancêtre commun avec résolution des conflits chemin par chemin.
Comparaison sémantique gauche/droite : ordre des clés et espaces ignorés.
Aucune différence à afficher
Collez deux documents JSON ci-dessus. La comparaison s’exécute dans un Web Worker et la page reste réactive, même avec de gros documents.
Comment fonctionne Comparer du JSON ?
Les outils de diff ligne à ligne classiques (comme le diff Unix historique) échouent sur le JSON parce qu’ils comparent du texte sérialisé et non des données sémantiques. En JSON, l’ordre des clés est explicitement arbitraire selon la RFC 8259 : {"a":1,"b":2} et {"b":2,"a":1} représentent des objets identiques, mais les moteurs de diff textuels les signalent comme des lignes contradictoires.
Le moteur de diff de ToolsByUs résout cela en travaillant sur des arbres de syntaxe abstraite (AST) analysés, à l’intérieur d’un Web Worker isolé . Il normalise les clés d’objets lexicographiquement et implémente trois algorithmes configurables d’appariement des tableaux :
- Appariement par index : aligne les éléments du tableau strictement par position ordinale (par défaut pour les listes de primitives).
- Appariement par clé : corrèle les entités d’une collection par un identifiant immuable (par exemple
idouuuid), de sorte que les éléments réordonnés soient détectés comme des modifications ou des déplacements, et non comme une vague fallacieuse de suppressions et d’ajouts. - Similitude structurelle : utilise un appariement biparti de poids maximal pour aligner les objets présentant la plus grande correspondance de champs.
Les changements de type scalaire (comme passer de la chaîne "42" au nombre 42 ) sont reconnus comme des événements TYPE_CHANGE distincts plutôt que comme des cycles de remplacement destructeurs.
Échantillon gauche vs droite
// Left:
{"id": 1, "tier": "free", "name": "Alpha"}
// Right:
{"name": "Alpha", "id": 1, "tier": "pro"}Exemple de sortie
// Semantic Diff Result: - tier: "free" (Removed) + tier: "pro" (Added) = id: 1 (Unchanged) = name: "Alpha" (Unchanged, key order ignored)
Échantillon gauche vs droite → Exemple de sortie
Échantillon gauche vs droite
{
"id": 42,
"name": "Ada",
"tags": ["math", "code"],
"active": true
}Échantillon gauche vs droite 2
{
"name": "Ada Lovelace",
"id": 42,
"tags": ["math", "code", "analysis"],
"active": false
}Exemple de sortie
[
{
"op": "replace",
"path": "/active",
"value": false
},
{
"op": "replace",
"path": "/name",
"value": "Ada Lovelace"
},
{
"op": "add",
"path": "/tags/2",
"value": "analysis"
}
]Quelles options et quels cas limites Comparer du JSON prend en charge ?
| Paramètre | Type | Valeur par défaut | Comportement et cas limites |
|---|---|---|---|
| Indifférence à l'ordre des clés | Invariant | Toujours activé | Les clés d’objet sont comparées comme des ensembles mathématiques. Des séquences de clés différentes ne produisent aucun diff. |
| Correspondance de tableau : index | Mode | Défaut | Correspond aux éléments strictement par index de base zéro. Idéal pour les tableaux de scalaires simples [1, 2, 3]. |
| Correspondance de tableau : clé | Mode | 'id' | Correspond aux éléments d’objets entre tableaux par clé primaire définie par l’utilisateur. Empêche les fausses ajouts lors des réorganisations. |
| Correspondance de tableau : similarité | Mode | Score > 0.4 | Correspondance heuristique basée sur des clés partagées et l’égalité de scalaires primitifs. |
| Classe de changement de type | Catégorie | Actif | Marque les transitions de type ('1' -> 1) comme des opérations TYPE_CHANGE distinctes au lieu de delete+add. |
| Plafond de mémoire | Limite | 100 MB | Plafond explicite de charge utile dans le worker pour éviter les plantages par manque de mémoire dans l’onglet du navigateur. |
| Fusion à trois voies | Mode | Opt-in | Base + Nôtre + Leur fusionnés en page (plafond de 8 MB) ; les conflits reviennent par défaut à la valeur ancestrale et sont résolus en direct par chemin. |
Questions fréquentes
Pourquoi l’ordre des clés n’a-t-il pas d’importance dans un diff JSON ?
Selon la spécification JSON officielle (section 4 de la RFC 8259), les objets JSON sont des collections non ordonnées de zéro ou plusieurs paires nom/valeur. Comme les encodeurs JSON (dictionnaires Python ou itération de maps en Go, par exemple) sérialisent les clés dans un ordre non déterministe, un diff sémantique doit normaliser l’ordre des clés pour éliminer les fausses différences.
Comment fonctionne l’appariement des tableaux par clé ?
Avec des tableaux de modèles de base de données ou d’enregistrements d’API, les éléments changent souvent d’ordre ou sont supprimés. En spécifiant une clé primaire comme 'id' ou 'uuid', le moteur de diff rapproche les objets de gauche et de droite ayant la même valeur de clé, quelle que soit leur position dans le tableau, et met en évidence avec précision les mutations de champs au lieu de signaler un remplacement complet du tableau.
Puis-je générer un JSON Patch RFC 6902 à partir de ce diff ?
Oui. ToolsByUs génère des tableaux JSON Patch conformes à la RFC 6902 (avec les opérations 'add', 'remove', 'replace' et 'move') que l’on peut copier en un clic ou appliquer directement à des documents. Le patch garantit l’aller-retour : appliquer le patch généré à votre document d’origine produit exactement le document cible.
Comment la fusion à trois gère-t-elle les modifications en conflit ?
Passez en 'Three-way merge' et fournissez l’ancêtre commun dans Base ainsi que les documents des deux branches. Les modifications faites d’un seul côté fusionnent automatiquement. Quand les deux côtés ont touché le même chemin, le moteur enregistre un conflit et la sortie fusionnée utilise la valeur de base jusqu’à ce que vous choisissiez Ours, Theirs ou Base pour ce chemin — chaque choix recalcule immédiatement le résultat, entièrement dans votre navigateur.
Mon payload JSON est-il envoyé à un serveur backend ?
Non. ToolsByUs est un site statique sans backend. L’analyse, le parcours d’AST et la génération de diff s’exécutent à 100% dans le thread Web Worker dédié de votre navigateur. Les requêtes réseau sont totalement désactivées pendant le chargement des documents, ce que des tests E2E automatisés stricts vérifient.
Jusqu’à quelle taille puis-je comparer un document JSON sans figer l’onglet ?
Comme toute l’analyse et le parcours lourds s’exécutent dans un Web Worker et que les lignes sont rendues avec un défilement virtualisé (seuls les éléments visibles dans votre viewport existent dans le DOM), l’interface reste réactive sur des documents allant jusqu’au plafond de 100 MB du worker. Une paire de 50 MB demande toujours des dizaines de secondes de vrai travail — la différence, c’est que vous pouvez faire défiler, taper et annuler pendant l’exécution, au lieu de regarder un onglet figé.