Vérificateur de différences, gratuit

À propos de la comparaison de textes

Cet outil de diff utilise l'algorithme de la plus longue sous-suite commune (LCS) pour comparer deux textes ligne à ligne. Les ajouts sont surlignés en vert et les suppressions en rouge. Choisissez la vue « En ligne » pour voir tous les changements sur une seule colonne, ou « Côte à côte » pour comparer les textes original et modifié en parallèle.

Usages courants

• Comparer des changements de code avant de committer
• Relire des documents ou contrats modifiés
• Vérifier les différences de traduction
• Valider les changements de fichiers de configuration
• Comparer des réponses d'API

Questions fréquentes

Compare-t-il caractère par caractère ?

Cet outil compare ligne à ligne. Si une ligne comporte le moindre changement (même un seul caractère), la ligne entière est marquée comme modifiée. C'est la même approche que celle utilisée par Git et la plupart des outils de diff.

Y a-t-il une limite de taille ?

Il n'y a pas de limite stricte, mais les textes très volumineux (plus de 10 000 lignes) peuvent prendre un instant à traiter, car la comparaison s'exécute entièrement dans votre navigateur.

Ce que « diff » signifie réellement

Un diff décrit comment transformer un texte en un autre à l'aide du plus petit ensemble d'insertions et de suppressions. Il existe une infinité de façons d'y parvenir ; la plus triviale consiste à « supprimer chaque caractère de A puis insérer chaque caractère de B ». Un diff utile est le plus court script d'édition, qui est le dual du problème de la plus longue sous-suite commune : trouver la plus longue séquence de lignes qui apparaît (dans l'ordre) dans les deux textes, tout le reste étant un ajout ou une suppression. La plupart des algorithmes de diff sont des algorithmes de LCS sous un autre nom.

Une subtilité : la plus longue sous-suite commune n'est pas la plus longue sous-chaîne commune. Une sous-suite préserve l'ordre mais pas l'adjacence : ainsi, « ABCDE » et « AXBYCZD » partagent la sous-suite « ABCD » même si aucune suite contiguë de trois caractères n'apparaît dans les deux.

Un bref historique des algorithmes de diff

Le premier programme de comparaison de fichiers largement utilisé fut le diff d'Unix, écrit par Douglas McIlroy aux Bell Labs, l'algorithme sous-jacent ayant été publié par James W. Hunt et McIlroy sous le titre Bell Labs Computing Science Technical Report #41 en juin 1976. McIlroy lui-même a décrit ces quatre mois de développement comme « un effort désespéré ». L'approche Hunt-McIlroy hachait chaque ligne du fichier B, indexait l'emplacement de chaque ligne unique et recherchait la plus longue chaîne de correspondances croissante de façon monotone. Elle a été livrée dans la Version 6 d'Unix et est restée essentiellement le même algorithme dans /usr/bin/diff sur la plupart des systèmes Unix pendant des décennies.

Eugene W. Myers a publié la référence moderne du secteur en 1986, « An O(ND) Difference Algorithm and Its Variations » dans Algorithmica Vol. 1, No. 2. Myers a reformulé la LCS comme un problème de plus court chemin à travers un graphe d'édition : placez A le long de l'axe supérieur et B le long du côté, tracez une diagonale chaque fois que deux lignes correspondent, et cherchez le chemin du coin supérieur gauche au coin inférieur droit comportant le moins d'arêtes non diagonales. Chaque arête non diagonale est une insertion ou une suppression ; chaque diagonale est gratuite. Point crucial, l'algorithme s'exécute en un temps O((N+M)·D) où D est la taille du script d'édition : autrement dit, il devient plus rapide à mesure que les fichiers se ressemblent. Pour les diffs de gestion de versions typiques, D est minuscule comparé à N+M, de sorte que Myers est radicalement plus rapide que le pire cas en O(N·M) en pratique. Son article inclut également un raffinement en espace linéaire utilisant une astuce « middle snake » de type diviser pour régner. L'algorithme de Myers est celui par défaut derrière GNU diff, git diff, Mercurial, Subversion, jsdiff, le difflib de Python et la plupart des visionneuses de diff graphiques.

Bram Cohen (plus tard mieux connu comme l'inventeur de BitTorrent) a conçu le patience diff pour le système de gestion de versions Bazaar vers 2002. Le problème de départ : le diff de Myers aligne n'importe quelle ligne correspondante, y compris les plus banales, de sorte que déplacer une fonction en C peut produire un diff bruité dans lequel l'accolade fermante de la fonction déplacée s'aligne sur l'accolade fermante d'une fonction sans rapport. Le patience diff ancre le diff sur les lignes qui apparaissent exactement une fois dans chaque fichier (typiquement les signatures de fonction, les en-têtes de commentaire, les messages de journal distinctifs), calcule la LCS de ces seules ancres à l'aide du tri patience, puis procède récursivement sur les intervalles. Le résultat s'aligne sur des lignes significatives et se lit mieux pour le code source. Git le prend en charge via git diff --patience. Le histogram diff est un raffinement ajouté à git vers 2010 qui construit un histogramme des occurrences de lignes et privilégie les ancres de basse fréquence plutôt que celles strictement uniques ; à partir de git 2.45, c'est l'option par défaut pour de nombreuses configurations.

Levenshtein contre LCS

Un concept voisin qu'il vaut la peine de distinguer. La distance de Levenshtein (Vladimir Levenshtein, 1965) compte le nombre minimal d'insertions, de suppressions et de substitutions d'un seul caractère pour transformer une chaîne en une autre. Le diff fondé sur la LCS est étroitement lié mais légèrement différent : le diff classique traite un « changement » comme une paire suppression-puis-insertion plutôt que comme une substitution unique, parce que cela correspond mieux aux fichiers orientés ligne. Levenshtein répond à « à quel point ces chaînes diffèrent-elles ? » et vous donne un nombre ; la LCS répond à « qu'est-ce qui a changé précisément ? » et vous donne un véritable script d'édition. Les correcteurs orthographiques et les fonctions « vouliez-vous dire ? » veulent le premier ; les outils de diff veulent le second. La variante Damerau-Levenshtein (1964) étend Levenshtein avec un opérateur de transposition pour la détection de fautes de frappe.

Granularité : ligne, mot et caractère

Le diff peut être calculé à différentes granularités, chacune avec ses compromis :

• Au niveau de la ligne : chaque ligne est un jeton ; deux lignes correspondent exactement ou pas du tout. Rapide, en phase avec la façon dont les programmeurs éditent le code, produit des correctifs concis que patch(1) peut appliquer. Inconvénient : reformater un seul caractère dans une ligne de 200 caractères marque la ligne entière comme modifiée. C'est l'option par défaut pour diff, git, SVN et cet outil.
• Au niveau du mot : chaque jeton délimité par des espaces est une unité, de sorte qu'une ligne dont un mot a changé n'affiche en surbrillance que ce mot. Excellent pour la prose, les contrats, les brouillons de blog. Utilisé par git diff --word-diff, le mode « Suggestions » de Google Docs, le « Suivi des modifications » de Microsoft Word, le mode comparaison de mots de Diffchecker.
• Au niveau du caractère : chaque point de code Unicode est une unité. Détecte les fautes de frappe d'un seul caractère, idéal pour la relecture juridique où un seul mot peut inverser le sens. Lent sur les grandes entrées et parfois illisible pour les longues modifications.

Un schéma courant dans les interfaces de diff modernes consiste à calculer d'abord le diff au niveau de la ligne, puis, pour toute paire de « voisins supprimés/ajoutés », à exécuter un diff secondaire au niveau du mot sur ces deux lignes seulement et à mettre en surbrillance les changements intraligne. C'est exactement ainsi que fonctionnent la vue des PR de GitHub et la bibliothèque diff-match-patch.

Trois modes d'affichage de diff que vous rencontrerez

• Le diff unifié (le format de tout fichier .patch) : les sections sont introduites par @@ -oldStart,oldLen +newStart,newLen @@ avec, par défaut, trois lignes de contexte au-dessus et en dessous. Il est né de l'option -u du GNU diff de Wayne Davison vers 1990. Compact et lisible par la machine via patch(1), ce qui explique pourquoi git, les correctifs par e-mail de style noyau et SVN l'utilisent tous.
• Côte à côte : l'original à gauche, le modifié à droite, alignés ligne par ligne. diff -y produit une version ASCII primitive ; Beyond Compare, Meld, WinMerge et la vue « Côte à côte » ci-dessus utilisent tous ce format. Idéal pour la revue visuelle et la relecture de prose.
• En ligne (empilé) : une seule colonne où les lignes supprimées et ajoutées sont entrelacées. La vue des PR de GitHub utilise ce mode par défaut. Le format le plus économe en espace pour les écrans étroits et les petites modifications.

Variantes utiles de git diff

• git diff : index contre arbre de travail.
• git diff --staged : HEAD contre index.
• git diff main..feature : les pointes de branche. main...feature compare par rapport à la base de fusion, ce que la PR va intégrer.
• git diff --word-diff et --color-words : un diff au niveau du mot adapté au balisage et teinté en couleur.
• git diff --no-index a.txt b.txt : fonctionne sur des fichiers hors de tout dépôt git. Pratique comme diff autonome du pauvre avec les algorithmes patience ou histogramme.
• git diff -w : ignore tous les espaces (correspond à la case « Ignorer les espaces » ci-dessus).
• git diff --histogram : changer d'algorithme commande par commande.

Quand recourir à un diff dans le navigateur

• Revue de code. Collez deux versions d'un fichier, repérez ce qui a changé, décidez si le changement a du sens.
• Relecture de code modifié par l'IA. Comparez votre original à la version remaniée par un LLM pour repérer les dérives ou les hallucinations.
• Révision de contrat juridique. Confirmez que seules les clauses convenues ont changé entre la version 3 et la version 4.
• Assurance qualité de traduction. Comparez deux traductions françaises du même paragraphe, ou comparez les anciens et nouveaux fichiers de localisation lorsque seule une poignée de chaînes auraient dû changer.
• Dérive de configuration. Comparez le nginx.conf de prod à celui de préproduction.
• Comparaison de schémas SQL. Exportez les instructions CREATE TABLE de deux bases de données et comparez-les pour repérer les index manquants ou les dérives de type de colonne.
• Dérive de spécification. Comparez deux versions d'un YAML OpenAPI / Swagger pour vérifier que les changements cassants sont documentés.
• Brouillons de blog en Markdown. Repérez ce qu'un coauteur a modifié.
• Audits de conformité. Comparez une politique de confidentialité d'un mois sur l'autre pour les régulateurs.
• Analyse de fichiers de verrouillage. Comparez package-lock.json ou yarn.lock pour comprendre une mise à niveau de dépendance.

Limites assumées

• Le diff de texte brut n'a aucune conscience sémantique. Renommer foo en bar dans tout un fichier a un coût identique à celui d'une réécriture totalement sans rapport. Des outils comme difftastic analysent l'AST du langage et produisent des diffs structurels (« fonction ajoutée », « argument réordonné »). Cette page ne le fait pas : c'est un simple diff de lignes par LCS.
• Les espaces et les fins de ligne provoquent des diffs parasites. CRLF contre LF, espaces en fin de ligne, tabulations contre espaces. La bascule « Ignorer les espaces » ci-dessus correspond au -w de git.
• Les fichiers binaires ne s'y prêtent pas. Le diff est un concept textuel. Pour le diff binaire, il existe des outils comme bsdiff, xdelta ou VBinDiff.
• Sensibilité à l'ordre. Le diff de lignes suppose que les documents ont été édités ligne par ligne. Pour des CSV non triés ou des réordonnancements de clés d'objets JSON, mieux vaut trier ou canoniser au préalable.
• Détection des déplacements. Le diff LCS classique ne reconnaît pas qu'une fonction a été déplacée au sein d'un fichier : il présente le déplacement comme une suppression suivie d'une insertion. Beyond Compare, Meld et difftastic tentent la détection des déplacements ; cette page ne le fait pas.

Plus de questions

Pourquoi cette page n'affiche-t-elle pas de surbrillance au niveau du caractère à l'intérieur des lignes modifiées ?

Parce que la passe au niveau de la ligne suffit pour la plupart des cas d'usage et s'exécute bien plus vite sur les longues entrées. Pour une surbrillance mot à mot à l'intérieur des lignes, le raffinement en deux étapes est une pratique courante, mais ajoute de la latence. Si toute la différence de la ligne compte pour vous (révision juridique, relecture de prose), un outil dédié au niveau du mot (y compris git diff --word-diff en ligne de commande) convient mieux.

Quelle est la différence entre le diff unifié et le côte à côte ?

Le diff unifié est le format compact et lisible par la machine qu'utilise tout fichier .patch : trois lignes de contexte, des sections marquées par @@. Le côte à côte affiche les deux versions en colonnes parallèles, ce qui est plus reposant pour l'œil lors d'une revue visuelle, mais prend plus d'espace horizontal. Le diff unifié, c'est ce que vous enverriez par e-mail ou committeriez ; le côte à côte, c'est ce que vous liriez sur un grand écran.

Existe-t-il des algorithmes meilleurs que Myers pour le code source ?

Pour le code source comportant des fonctions déplacées ou de grands réagencements, oui : le patience diff (Bram Cohen, 2002) et le histogram diff (git, vers 2010) sont conçus pour s'aligner sur des lignes uniques significatives plutôt que sur des lignes banales, produisant une sortie plus lisible. Les deux sont disponibles via git diff --patience et git diff --histogram. Les outils conscients de l'AST comme difftastic vont plus loin et analysent la structure réelle du langage.

Est-il sûr de coller du texte confidentiel ici ?

Oui, le diff s'exécute entièrement dans votre navigateur à l'aide d'une implémentation LCS en JavaScript. Rien n'est téléversé, aucune analyse des données saisies, aucun journal côté serveur du texte. C'est la seule catégorie d'outil de diff sûre pour les accords de confidentialité, le code source interne ou les clauses de contrat non divulguées ; les services de diff dans le cloud voient tout ce que vous collez.

Outils associés