Comparer deux textes _

Comment fonctionnent les algorithmes de diff

Chaque vue de diff sur cette page est produite par l’algorithme de Myers — une technique de 1986 d’Eugene W. Myers qui trouve le script d’édition le plus court entre deux séquences de jetons en temps O((N+M)D), où D est la distance d’édition. L’algorithme est fondé sur le problème de la Plus Longue Sous-séquence Commune, et le moteur s’exécute entièrement dans votre navigateur grâce à la bibliothèque open-source jsdiff.

1. Tokeniser les entrées — Avant la comparaison, l’algorithme divise chaque entrée en une séquence de jetons. La granularité par ligne divise sur les sauts de ligne ; la granularité par mot divise sur les espaces et les limites de ponctuation ; la granularité par caractère traite chaque point de code Unicode comme son propre jeton.
2. Construire le graphe d’édition — L’algorithme de Myers modélise la comparaison comme un chemin à travers une grille 2D où se déplacer vers la droite signifie « supprimer de l’original », se déplacer vers le bas signifie « insérer depuis la version modifiée », et se déplacer en diagonale signifie « le jeton correspond dans les deux ». L’algorithme trouve le chemin diagonal le plus court.
3. Extraire la LCS — Les mouvements diagonaux dans le chemin le plus court tracent la Plus Longue Sous-séquence Commune — les jetons qui apparaissent dans les deux entrées dans le même ordre relatif. Chaque jeton dans la LCS est « inchangé » ; tout le reste est soit un ajout, soit une suppression.
4. Appliquer les options de prétraitement — Si vous activez « Ignorer la casse », les deux entrées sont mises en minuscules avant la passe LCS pour que « BONJOUR » et « bonjour » soient considérés comme identiques. « Ignorer les espaces » compresse plusieurs espaces en un seul. « Rogner chaque ligne » supprime les espaces de début et de fin par ligne avant la comparaison.
5. Afficher la vue sélectionnée — Le résultat est le même résultat LCS affiché de trois façons : Côte à côte montre l’original à gauche et la version modifiée à droite dans une grille à deux colonnes avec des surlignages de lignes rouges et verts. Unifié montre une seule colonne avec des lignes préfixées − et +, comme la sortie de git diff. En ligne montre les suppressions en rouge barré et les ajouts en vert souligné dans le même flux de texte.
6. Calculer le résumé — Après le rendu, l’outil compte combien de jetons ont été ajoutés, supprimés et conservés, puis calcule la similarité comme le rapport des jetons inchangés sur le plus grand des deux longueurs d’entrée. Une similarité de 100% signifie que les entrées sont identiques après prétraitement.

Pourquoi utiliser un diff checker

• Revue de code sans client Git — Collez deux versions d’un fichier de configuration, d’une migration SQL ou d’un script shell et voyez ce qui a changé sans cloner un dépôt, changer de branche ni attendre un pipeline CI. L’outil est pratique pour les revues rapides pendant la programmation en binôme, pour les transferts de prestataires où l’autre partie n’a pas partagé son historique Git, et pour les codebases legacy qui sont antérieures à tout contrôle de version. La vue unifiée produit une sortie que vous pouvez copier directement dans un fil de discussion ou un ticket.
• Suivi des révisions de contrats et documents — Le diff au niveau des mots montre quels termes ont changé entre les versions d’un contrat plus rapidement que le panneau Suivi des modifications de Word. Collez la clause A du premier brouillon et la clause B de la copie exécutée et la substitution s’allume rouge sur vert à la phrase exacte qui a bougé. Les juristes et les équipes d’achat utilisent cela pour vérifier que les révisions de dernière minute ne se sont pas glissées à travers la revue avant la signature d’un contrat.
• Révisions d’essais et de brouillons — Les rédacteurs comparant un premier brouillon à une version éditée peuvent passer à la granularité par mots pour voir chaque substitution, insertion et coupure sans relire les deux copies. Le même workflow fonctionne pour les traducteurs vérifiant les modifications par rapport au texte source, pour les éditeurs s’assurant qu’une correction de style a préservé la voix de l’auteur, et pour les équipes de presse réconciliant un article publié avec le brouillon soumis.
• Comparaison de journaux et de configs — Les administrateurs système comparant deux instantanés de configuration de serveur, deux plannings cron ou deux sorties de ps aux peuvent utiliser la granularité par lignes pour localiser le paramètre unique modifié dans un fichier de 200 lignes en quelques secondes. Associez-le à l’option Ignorer-les-espaces et un diff bruyant se réduit aux changements de paramètres qui comptent vraiment.

Applications courantes

Le diff de texte apparaît à la fin de chaque cycle d’édition dans les travaux d’écriture, de développement et d’opérations.

• Revue de pull request : collez deux implémentations de fonction côte à côte pour comprendre le changement de logique avant d’approuver, sans l’overhead de récupérer la branche.
• Assurance qualité de l’internationalisation : comparez une chaîne source anglaise à son équivalent traduit au niveau des mots pour détecter les insertions, omissions ou changements de terminologie que le traducteur a pu introduire.
• Analyse d’incident : comparez deux instantanés de manifest Kubernetes ou deux sorties « docker inspect » au niveau des lignes pour isoler le changement de configuration qui a précédé une panne.

Un exemple concret

Prenons une configuration serveur de cinq lignes. Original : host=localhost, port=5432, dbname=app_db, user=app, password=secret. Modifié : host=db.prod.example.com, port=5432, dbname=app_db, user=app_prod, password=secret. Avec la granularité par lignes et la vue Côte à côte, la ligne 1 montre rouge à gauche (host=localhost) et vert à droite (host=db.prod.example.com), la ligne 4 montre rouge (user=app) et vert (user=app_prod), et les lignes 2, 3 et 5 restent inchangées des deux côtés. Le résumé indique 2 ajouts, 2 suppressions, 3 inchangés et une similarité de 60% — trois des cinq lignes conservées. Passez à la granularité par mots et le diff se resserre davantage : seules les valeurs à droite du = sur les lignes 1 et 4 s’allument, les clés restent inchangées, et la similarité monte à environ 85% car la LCS compte maintenant host, user et la ponctuation environnante comme conservés.

Est-ce que cela s’exécute dans mon navigateur ?

Oui. L’ensemble du calcul de diff s’exécute côté client grâce à la bibliothèque open-source jsdiff chargée avec la page. Rien de ce que vous tapez, collez ou comparez n’est envoyé à un serveur. Vous pouvez le vérifier vous-même : ouvrez les DevTools du navigateur, passez à l’onglet Réseau, effacez le journal, cliquez sur Comparer, et confirmez qu’aucune requête réseau ne se déclenche pour l’étape de comparaison.

Que signifie le pourcentage de similarité ?

La similarité est calculée comme jetons inchangés / max(total jetons dans l’original, total jetons dans la version modifiée). Un score de 100% signifie que les deux entrées sont identiques après l’application de vos options de prétraitement (normalisation de la casse, compression des espaces, rognage des lignes). Un score de 0% signifie qu’aucun jeton n’est partagé entre les entrées. La métrique est une approximation grossière de la distance d’édition — utile comme indicateur rapide — pas un score de plagiat ou d’originalité.

Puis-je comparer JSON / YAML / XML sémantiquement ?

Pas avec cet outil. Il s’agit d’un diff au niveau du texte, donc un reformatage JSON ou XML avec uniquement des espaces montre quand même de nombreux changements même si les données sont logiquement identiques. Réordonner les clés d’objets dans JSON apparaît également comme des changements même si la plupart des parseurs considèrent l’ordre des clés comme non significatif. Pour un vrai diff sémantique qui compare des arborescences d’objets analysés et ignore l’ordre des clés et le formatage, nous planifions un outil dédié JSON Diff. Pour l’instant, normalisez les deux entrées à la même indentation et au même ordre de clés avant de les coller ici.

En quoi les vues unifiée et côte à côte diffèrent-elles ?

Côte à côte affiche deux colonnes : l’original à gauche et la version modifiée à droite, avec les lignes supprimées surlignées en rouge à gauche et les lignes ajoutées surlignées en vert à droite. Les lignes inchangées apparaissent dans les deux colonnes alignées sur la même ligne. Unifié affiche une seule colonne avec un préfixe − et fond rouge pour les lignes supprimées et un préfixe + et fond vert pour les lignes ajoutées — la même mise en page qu’affiche git diff dans votre terminal. Utilisez unifié quand vous souhaitez copier le résultat comme fichier patch ou le coller dans un fil de revue de code. Utilisez côte à côte quand l’alignement visuel de ce qui a remplacé quoi importe plus que le texte brut du patch.

Collez l’original à gauche, la version modifiée à droite, choisissez une vue et une granularité, et la comparaison apparaît en quelques millisecondes. Activez le mode en direct et le diff se relance à chaque frappe pendant que vous éditez l’un ou l’autre côté. Téléchargez le résultat comme fichier .patch unifié standard que git apply consomme directement. Sans envoi, sans compte, sans clé API de fournisseur, sans quota.