Comparer deux textes en ligne : algorithme LCS/Myers et 6 cas d’usage
Un outil de diff texte en ligne répond rapidement à une seule question : qu’est-ce qui a vraiment changé entre la version A et la version B ? Vous collez deux blocs de texte, l’outil exécute un algorithme de plus longue sous-séquence commune (LCS), et vous obtenez une vue côte à côte ou unifiée de chaque insertion, suppression et modification, généralement en moins d’une milliseconde.
Ce guide s’adresse aux développeurs qui font de la revue de code, aux SRE qui comparent des extraits de logs, aux juristes qui annotent des contrats et aux rédacteurs qui relisent des corrections. Il couvre l’algorithme (LCS, Myers, Patience), les deux vues standard, les options d’ignorance qui résolvent 95 % des plaintes du type « tout semble avoir changé », quand préférer un JSON diff, six cas d’usage prêts à coller, et les pièges que l’algorithme lui-même permet d’expliquer.
Vous voulez sauter directement à la comparaison ? Ouvrez Comparateur de texte. L’outil tourne entièrement dans votre navigateur, sans envoi.
1. Qu’est-ce qu’un diff texte ?
Un diff texte est le plus petit ensemble d’insertions et de suppressions qui transforme un texte en un autre, chaque ligne étant marquée comme ajoutée, supprimée ou inchangée. Les diffs modernes ajoutent une seconde passe au niveau du mot ou du caractère pour qu’une modification d’un seul caractère ne mette en évidence que ce token, plutôt que la ligne entière.
1.1 Pourquoi l’égalité de caractères (===) ne suffit pas
Insérez une ligne en haut d’un fichier de configuration de 200 lignes et une comparaison naïve caractère par caractère signale chaque octet après le point d’insertion comme différent. Le texte n’a pas changé : sa position a changé. Un algorithme de diff doit reconnaître que « les 199 lignes suivantes sont toujours les mêmes lignes, simplement décalées d’une position » et signaler une seule insertion. C’est ce que LCS permet, et c’est pourquoi git, GitHub et tous les outils de revue de code en embarquent un.
1.2 Diff côte à côte ou unifié
La vue côte à côte place les deux versions en colonnes parallèles et colore les cellules : vert pour les ajouts, rouge pour les suppressions, jaune pour les modifications. Le diff unifié est l’ancien format texte issu de GNU diff : une colonne, des marqueurs - et +, trois lignes de contexte autour de chaque hunk. Même comparaison, deux présentations. La section 4 couvre quand utiliser chacune.
1.3 Où le diff texte est utilisé
Revue de code sur GitHub et GitLab. Sortie locale de git diff. Patches collés dans Slack. Annotation de contrats. Relecture de traductions. Tests CI à base de snapshots qui échouent avec une sortie +/-. Investigation chronologique de logs. Comparaison de deux fichiers .env. Bref, dès que deux blocs de texte doivent être alignés ligne par ligne.
Ouvrez Comparateur de texte et collez deux textes pour voir tout cela en action. Chaque comparaison se déroule localement dans votre navigateur.
2. L’algorithme derrière le diff texte (LCS + Myers + Patience)
2.1 Plus longue sous-séquence commune
Étant donné deux séquences de lignes A et B, la plus longue sous-séquence commune (LCS) est la plus longue liste de lignes qui apparaissent dans les deux, dans le même ordre, sans exiger qu’elles soient adjacentes. Une fois la LCS obtenue, le diff devient simple : les lignes de A absentes de la LCS sont supprimées, les lignes de B absentes de la LCS sont ajoutées, les lignes de la LCS restent inchangées.
La LCS classique se calcule via une table de programmation dynamique de taille N × M. La cellule (i, j) contient la longueur de la LCS des i premières lignes de A et des j premières lignes de B. On remplit la table de gauche à droite, de haut en bas, puis on remonte depuis la cellule en bas à droite pour reconstruire le script d’édition. Le temps et l’espace sont tous deux en O(N×M) : convenable pour deux fichiers de mille lignes, lent pour un log de cent mille lignes.
2.2 Myers (1986)
L’article d’Eugene Myers de 1986, « An O(ND) Difference Algorithm and Its Variations », reformule le problème comme un plus court chemin dans un graphe d’édition : les nœuds sont les positions (i, j) dans les deux entrées, les déplacements horizontaux sont des suppressions, les verticaux des insertions, les diagonaux des correspondances. Le plus court chemin correspond au script d’édition minimal.
Myers tourne en O((N+M)D), où D est la taille du script d’édition. Quand les deux textes sont similaires (le cas habituel pour un diff), D reste petit et l’algorithme est quasiment linéaire. C’est l’algorithme par défaut de git diff, de GNU diff et du moteur de rendu des PR sur GitHub. Pour quatre-vingt-dix-neuf pour cent des entrées web, c’est la bonne réponse.
2.3 Diff Patience (Bram Cohen, 2005)
Patience adopte une autre approche : trouver les lignes qui apparaissent exactement une fois dans chaque entrée (les « lignes d’ancrage uniques »), les apparier, puis appliquer récursivement l’algorithme aux écarts entre ancres. Les mathématiques sont moins propres (le pire cas reste mauvais), mais le rendu est nettement meilleur sur du code.
Pourquoi ? Myers minimise la distance d’édition, ce qui est mathématiquement optimal mais visuellement désastreux quand l’alignement optimal traverse des accolades ou des lignes vides sans rapport. Patience refuse de s’aligner sur du boilerplate banal (chaque fichier contient des }, chaque fichier contient des lignes vides), donc les frontières de fonction restent intactes. Bram Cohen l’a inventé pour Bazaar ; Git le propose via git diff --patience. L’algorithme Histogram, proche cousin (git diff --histogram), est légèrement plus rapide avec une qualité de rendu similaire.
Imaginez deux versions d’un même fichier où une fonction a été déplacée. Myers peut aligner l’accolade fermante de la fonction A avec celle de la fonction B et présenter les corps comme totalement différents. Patience s’ancre sur les noms de fonction uniques et signale un déplacement propre. Même entrée, expérience de revue très différente.
2.4 Comparaison des algorithmes
| Propriété | Myers (par défaut) | Patience | Histogram |
|---|---|---|---|
| Complexité temporelle | O((N+M)D) | ~O(N log N) cas courant | similaire à Patience |
| Distance d’édition optimale | Oui, script le plus court | Non, peut être plus long | Non, peut être plus long |
| Lisibilité sur du code | Désaligne parfois accolades et lignes vides | Excellent, s’ancre sur les lignes uniques | Excellent |
| Utilisé par | git par défaut, GNU diff, UI GitHub | git diff --patience, Bazaar | git diff --histogram |
| Idéal pour | Vitesse et exactitude sur la plupart des entrées | Revues de code, diffs de refactor | Comme Patience, légèrement plus rapide |
2.5 Ce que fait cet outil
Comparateur de texte utilise une LCS classique en programmation dynamique avec deux optimisations agressives : suppression du préfixe et du suffixe communs, puis une seconde passe LCS au niveau token pour le diff intraligne au niveau du mot. Un diff de deux configs de deux mille lignes avec une seule ligne modifiée se réduit à une table DP 1×1 après trimming et s’affiche en moins d’une milliseconde. Pour les entrées web typiques, le choix entre Myers et DP est invisible : les deux terminent avant que le navigateur ait fini de peindre le résultat.
3. Diff intraligne au niveau du mot — pourquoi un changement d’un caractère met la ligne entière en surbrillance
Vous changez un identifiant sur une ligne et la ligne entière s’illumine en rouge et vert. Bug ? Non, choix de conception.
Le diff exécute d’abord une LCS au niveau ligne : « la ligne 14 a été remplacée. » Puis, pour chaque paire remplacée, il lance une seconde LCS au niveau token. Les tokens sont produits en découpant sur les frontières de mots Unicode : les suites de lettres et de chiffres restent groupées, les espaces et la ponctuation deviennent chacun leur propre token. La seconde LCS donne le script d’édition minimal au niveau token à l’intérieur de la ligne.
Le moteur de rendu dessine la ligne entière dans la couleur de surbrillance pour que l’œil la repère, puis ne peint que les tokens modifiés avec le fond vif. Les tokens inchangés autour conservent une version atténuée de la même couleur, présents mais visuellement discrets. L’œil se pose précisément sur l’édition.
Exemple 1 : renommage d’identifiant. function getUser(id) devient function getUser(userId). La ligne entière est marquée comme modifiée. À l’intérieur, seuls id (barré rouge) et userId (vert vif) portent la surbrillance inline. Tout le reste reste atténué.
Exemple 2 : changement de latence dans un log. POST /api/orders 201 88ms devient POST /api/orders 201 4200ms. La ligne est modifiée. En inline, seuls 88 et 4200 sont vifs. Le chemin, la méthode et le code de statut restent atténués, exactement ce dont a besoin la personne qui examine la chronologie d’un incident.
Quand trop de tokens changent, la surbrillance au niveau du mot devient du bruit. L’outil bascule alors sur une présentation appariée de suppression et d’ajout : la ligne d’origine affichée comme supprimée, la nouvelle comme ajoutée, sans coloration intraligne. Le seuil est grossièrement « plus de la moitié des tokens diffèrent ».
En résumé : le diff au niveau ligne dit quelle ligne a changé ; le diff au niveau mot dit quels caractères de cette ligne portent le changement. Cliquez sur Exemple dans Comparateur de texte pour voir les deux vues sur une entrée identique.
4. Côte à côte ou unifié — deux vues, un seul diff
4.1 Vue côte à côte
Deux colonnes : l’original à gauche, la version modifiée à droite. Les lignes qui correspondent sont alignées horizontalement. Les lignes ajoutées n’apparaissent que dans la colonne de droite avec un fond vert ; les lignes supprimées n’apparaissent que dans la colonne de gauche avec un fond rouge ; les paires modifiées se retrouvent côte à côte avec une gouttière jaune et des surbrillances intralignes au niveau du mot.
Utilisez la vue côte à côte quand un humain doit lire le diff : revue de PR, enseignement, démos, parcours d’un changement de contrat avec un interlocuteur non technique. C’est la vue pour les yeux.
L’inconvénient : elle ne voyage pas. Vous ne pouvez pas coller un rendu côte à côte dans Slack et permettre à quelqu’un de l’appliquer. Vous ne pouvez pas le piper dans patch. Pour le partage et l’application, il faut l’unifié.
4.2 Format diff unifié
Le diff unifié est un format texte brut vieux de cinquante ans, défini par GNU diff et normalisé par POSIX. Un exemple complet :
--- original
+++ modified
@@ -1,3 +1,4 @@
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
+2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.Les deux premières lignes nomment les fichiers source. La ligne @@ -L,C +L,C @@ est un en-tête de hunk : -L,C signifie « à partir de la ligne L de l’original, C lignes sont concernées » ; +L,C indique la même chose pour la version modifiée. À l’intérieur du hunk, les lignes commençant par une espace sont du contexte (inchangées), - est supprimé, + est ajouté.
Trois lignes de contexte au-dessus et en dessous de chaque modification : c’est la valeur par défaut de GNU. La plupart des outils permettent de la changer avec -U n ; diff -U0 pour aucun contexte, diff -U10 pour dix lignes. L’en-tête de hunk suit la valeur retenue.
Dans Comparateur de texte, cliquez sur l’onglet Unified pour basculer de vue, ou sur Copy unified diff pour placer le patch dans votre presse-papiers.
4.3 Là où le diff unifié est portable
Le diff unifié voyage. C’est le format pivot du changement textuel.
| Destination | Accepte le diff unifié ? | Comment |
|---|---|---|
GNU patch | Oui | patch -p1 < diff.patch |
git apply | Oui | git apply diff.patch |
| Commentaire de revue de PR GitHub | Oui (dans un bloc ```diff) | Rendu en couleur |
| Commentaire MR GitLab | Oui | Même bloc fenced |
| PR Bitbucket / Azure DevOps | Oui | Même bloc fenced |
| Collage dans Slack / Discord | Partiel | Rendu texte dans un bloc de code, sans couleur |
| « Open Patch » dans VS Code | Oui | Appliquer via Source Control |
| Corps de ticket Jira / Linear | Partiel | Fonctionne dans un bloc de code, sans bouton d’application |
Les mêmes neuf lignes de texte ---/+++/@@ s’appliquent via patch, via git apply, se rendent sur trois plateformes de PR et survivent à un collage dans Slack. Aucun autre format de diff n’a une portée comparable.
4.4 Quand choisir laquelle
Côte à côte pour la revue, unifié pour le partage et l’application. Si vous lisez le diff vous-même, les colonnes sont plus rapides. Si un acteur en aval doit le consommer (un relecteur, un outil, une commande patch), copiez le format unifié.
5. Options d’ignorance — espaces, casse, lignes vides, fins de ligne
La plupart des plaintes « tout semble avoir changé » relèvent du bruit. Quatre interrupteurs résolvent 95 % des cas.
- Ignorer la casse mappe
Asura. Équivalent àgit diff -i. Utile pour les comparaisons de variables d’environnement, les audits de style sur les mots-clés SQL, partout où la convention oscille entre majuscules criardes et minuscules discrètes alors que le sens est identique. - Ignorer toutes les espaces écrase chaque espace, tabulation et saut de ligne avant comparaison. Équivalent à
git diff -w. Couvre les reformattages tabulations ↔ espaces, les réécritures d’indentation et les diffs « on est passé à Prettier » qui pulvérisent le nombre de lignes. Un diff avec ignore-whitespace sur ces changements passe typiquement de 87 modifications à 4. - Ignorer les espaces et tabulations de fin ne supprime que les espaces de fin de ligne. Équivalent à
git diff -b. Traite le bruit CRLF après une copie entre Windows et Unix : les\rde fin sont filtrés et le contenu réel s’aligne. - Ignorer les lignes vides supprime les lignes vides avant le diff. Traite le « j’ai ajouté un saut de paragraphe et maintenant le paragraphe 12 paraît totalement différent » dans les diffs de prose.
Une config de 200 lignes qui annonce « 87 modifications » tombe généralement à « 4 modifications » après Ignorer toutes les espaces. Une copie Windows-vers-Unix qui signale chaque ligne tombe à zéro avec Ignorer les espaces de fin. Chaque interrupteur est indépendant et persiste entre les sessions.
CRLF ou LF. Les fins de ligne Windows sont \r\n ; Unix utilise \n ; le Mac classique utilisait \r. Ouvrez un fichier Windows dans un éditeur Unix qui ne normalise pas et vous gardez le \r final. Chaque ligne sera signalée comme « contenu identique mais avec un \r à la fin ». Ignorer les espaces de fin fait taire ce bruit sans masquer les vrais changements.
Un avertissement. Les options d’ignorance sont à double tranchant. Activez Ignorer la casse et un refactor qui change LOG.error en log.Error paraît identique. Activez Ignorer toutes les espaces et un bug d’indentation Python devient invisible. Choisissez les interrupteurs en fonction de la question que vous posez, puis désactivez-les quand vous avez terminé.
6. Diff texte, JSON diff ou git diff — matrice de décision
Le diff texte fait du matching ligne et mot, sans aucune compréhension de la structure. Idéal pour de la prose, à éviter pour du JSON.
6.1 Matrice de décision
| Type d’entrée | Diff texte | JSON diff | Git diff |
|---|---|---|---|
| Prose / Markdown / contrat | Idéal | Mauvais outil | Partiel (ne marche que sur les fichiers suivis) |
| Bout de code (collage d’un seul fichier) | Idéal | Mauvais outil | Partiel (nécessite un repo) |
| Code dans un repo (multi-fichiers) | Partiel | Mauvais outil | Idéal |
| Réponse JSON d’une API | Mauvais outil (faux positifs sur l’ordre des clés) | Idéal | Mauvais outil |
| Config YAML / TOML | Partiel (faux positifs sur l’ordre des clés) | Idéal (après conversion) | Partiel |
| CSV ligne par ligne | Partiel | Mauvais outil | Mauvais outil |
| Log / heredoc | Idéal | Mauvais outil | Mauvais outil |
| Fichier binaire | Mauvais outil | Mauvais outil | git diff --binary |
6.2 Quand le diff texte est le mauvais outil
Trois erreurs classiques.
JSON avec clés réordonnées. {"a":1,"b":2} et {"b":2,"a":1} sont le même document JSON. Un diff texte signale chaque ligne comme modifiée, parce que ce sont effectivement des lignes différentes. Utilisez Comparer JSON en ligne ; l’outil sait que les clés JSON ne sont pas ordonnées.
Configs YAML reformattées. Changez une valeur, passez le fichier dans un formateur, et l’indentation, l’ordre des clés et le quoting changent tous. Le diff texte rapporte une réécriture complète. Convertissez d’abord les deux fichiers en JSON, puis comparez avec JSON Diff.
Refactors multi-fichiers avec renommages. Git suit les renommages ; le diff texte non. Si vous comparez deux arborescences en concaténant les fichiers en un seul blob, chaque déplacement inter-fichier apparaîtra comme suppression + ajout. Utilisez git diff (ou git diff --find-renames=80%) à la place.
6.3 Quand le diff texte est exactement le bon outil
Prose. Bouts de code collés depuis n’importe où. Annotations de contrats. Extraits de logs. Relecture de traductions où vous appariez des phrases en langage naturel. Fichiers .env où l’ordre compte parce que les shells les lisent de haut en bas. Tout ce où les lignes elles-mêmes portent le sens.
Pour aller plus loin sur le filtrage du bruit dans les diffs JSON (timestamps, IDs de requête, UUID auto-générés), lisez Ignorer timestamps et IDs dans un JSON Diff.
7. Six cas d’usage réels (avec entrées prêtes à coller)
7.1 Bout de code en revue — renommage de fonction
Vous relisez une PR. L’auteur a renommé id en userId et ajouté une clause de garde. Collez les deux versions :
// Original
function getUser(id) {
const u = db.users.find(x => x.id === id);
return u;
}// Modified
function getUser(userId) {
if (!userId) return null;
const u = db.users.find(x => x.id === userId);
return u;
}Le diff affiche trois lignes modifiées plus une ligne ajoutée. La surbrillance inline marque chaque token id → userId ; la nouvelle clause de garde apparaît sur fond vert. Options d’ignorance désactivées. Essayez dans Comparateur de texte et copiez la sortie unifiée pour la déposer en commentaire de revue.
7.2 Annotation de contrat ou de policy — une clause insérée
Cinquante paragraphes de contrat, une clause insérée. Collez la version d’hier à gauche et celle d’aujourd’hui à droite :
1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
3. Disputes are resolved in California courts.1. The service is provided as-is.
2. Either party may terminate with 30 days notice.
2a. Termination notice must be in writing.
3. Disputes are resolved in California courts.Le diff affiche quarante-neuf lignes inchangées et une ligne ajoutée (+2a. Termination notice must be in writing.). Exportez le diff unifié comme trace de revue juridique.
7.3 Investigation chronologique de logs
Vous suspectez une régression de latence. Prenez un extrait de logs d’accès avant et pendant l’incident :
GET /api/users 200 14ms
POST /api/orders 201 88ms
GET /api/orders/42 200 21msGET /api/users 200 14ms
POST /api/orders 201 4200ms
GET /api/orders/42 500 21msLa surbrillance inline fait ressortir 88 → 4200 (un saut de latence de 50×) et 200 → 500 (un endpoint de détail de commande qui s’est mis à échouer). Pour un travail plus riche sur les logs (extraire des champs, regrouper par endpoint, calculer des percentiles), associez le diff à Aide-mémoire jq si vos logs sont en JSON.
7.4 Relecture de traduction — préserver les placeholders
Vous avez engagé une nouvelle agence de traduction et vous voulez vérifier que la nouvelle copie correspond à l’ancienne dans sa structure. Collez l’ancienne traduction à gauche, la nouvelle à droite. Activez Ignorer les espaces et tabulations de fin car les traducteurs ajoutent régulièrement une espace parasite à la fin des chaînes.
Le diff confirme que chaque placeholder {username}, {count} et %s reste en place ; seul le texte en langage naturel change. Un placeholder manquant apparaît comme un token supprimé dans le diff inline, détecté avant la mise en production. Si vous devez comparer les formats de placeholders eux-mêmes, l’Aide-mémoire Regex couvre \{\w+\} et ses cousins. Essayez dans Comparateur de texte.
7.5 Audit de config ou de .env — production contre staging
Comparez deux fichiers .env. Activez Ignorer les lignes vides pour que le groupement en paragraphes ne désaligne pas les sections. Le diff vous montre quelles clés diffèrent en valeur, quelles clés existent dans un environnement mais pas dans l’autre, et où les commentaires ont dérivé. Cinq minutes qui évitent la session de débogage du type « ça marche en staging mais pas en prod ».
7.6 Révision de prose ou de brouillon
Votre éditeur vous a renvoyé un brouillon. Collez votre version originale à gauche et la version éditée à droite. Le diff inline au niveau du mot vous montre exactement quelles phrases ont été réécrites, lesquelles sont intactes, et quels paragraphes ont été insérés. Acceptez ou rejetez les changements un par un, sans fonction Suivi des modifications, sans fichier Word, sans format propriétaire.
8. Pièges courants et lecture comme symptômes
Le comportement de l’algorithme explique la plupart des frustrations. Cinq plaintes courantes et ce qu’elles signifient vraiment.
Piège 1 : « Chaque ligne est rouge après une copie Windows-vers-Unix. » Symptôme : chaque ligne du diff est signalée comme modifiée alors que le contenu paraît identique. Cause : les \r finaux issus des fins de ligne CRLF. Remède : activez Ignorer les espaces et tabulations de fin. Le diff retombe aux vrais changements.
Piège 2 : « J’ai collé du JSON et 100 % des lignes sont différentes. » Symptôme : deux objets JSON qui devraient être équivalents apparaissent totalement modifiés. Cause : réordonnancement des clés. Le diff texte traite l’ordre des lignes comme significatif ; JSON ne le fait pas. Remède : utilisez Comparer JSON en ligne pour toute entrée JSON.
Piège 3 : « Le passage tabulations ↔ espaces a fait exploser le diff. » Symptôme : 87 modifications, toutes liées à l’indentation. Cause : votre formateur a changé l’espace de tête de chaque ligne. Remède : Ignorer toutes les espaces écrase le bruit et fait remonter les vrais changements sémantiques.
Piège 4 : « Le diff dit identique mais cmp n’est pas d’accord. » Symptôme : le diff ne signale aucune différence mais une comparaison au niveau octet indique que les fichiers diffèrent. Cause : une option d’ignorance laissée active depuis une session précédente masque les vrais changements. Remède : ouvrez le panneau d’options d’ignorance, désactivez tous les interrupteurs, puis relancez le diff.
Piège 5 : « Une petite édition apparaît comme suppression + ajout. » Symptôme : un petit changement apparaît comme une ligne supprimée séparée et une ligne ajoutée séparée, au lieu d’une surbrillance inline. Cause : la proportion de tokens modifiés a franchi le seuil inline et le moteur de rendu est retombé sur la présentation appariée ligne par ligne. C’est un choix de conception, pas un bug. Basculez sur la vue Unified pour voir la paire classique -/+ attendue par les outils patch.
9. Confidentialité, performances et quand basculer en ligne de commande
Chaque comparaison dans Comparateur de texte tourne en JavaScript dans votre navigateur. Pas d’upload, pas de fichier temporaire, pas de log serveur, pas d’analytics sur le texte que vous collez. Sans risque pour du code propriétaire, des contrats internes, des logs privés : tout ce que vous ne voudriez pas coller dans un serveur tiers.
Limites pratiques : environ 5 000 lignes ou 1 Mo par côté. Le diff live se désactive au-delà de 200 Ko combinés et bascule sur un bouton Diff manuel pour que la frappe ne bloque pas la page. Au-delà de 5 000 lignes, l’entrée est tronquée et un avertissement s’affiche. Ces limites existent parce que le diff tourne sur le thread principal (pas de web worker), et qu’un passage par worker plus la sérialisation coûteraient plus cher que le diff lui-même sur de petites entrées.
Quand vos entrées dépassent le navigateur, passez en ligne de commande :
# Unified diff between two files
diff -u a.txt b.txt
# Same, but using git's diff engine (Patience, Histogram, color)
git diff --no-index a.txt b.txt
git diff --no-index --patience a.txt b.txt
# Streaming diff viewer for huge files (Rust, side-by-side, syntax-aware)
delta a.txt b.txtPassez à la ligne de commande pour les logs de plusieurs mégaoctets, les fichiers binaires, les diffs de repo multi-fichiers, quand vous voulez une coloration syntax-aware comme delta, ou quand vous devez piper la sortie de diff dans un autre outil.
10. Unicode, CJK et RTL — notes sur le diff de texte international
Le tokenizer découpe sur les frontières de mots Unicode selon trois catégories : runs de mots (\p{L} lettres et \p{N} chiffres), ponctuation non-mot, et espaces. Chaque catégorie produit ses propres tokens, donc hello, world! devient hello, ,, , world, !, soit cinq tokens.
Pour le contenu CJK (chinois, japonais, coréen), chaque idéogramme ou kana est son propre token. Changez un caractère dans une phrase chinoise et seul ce caractère porte la surbrillance inline, le reste de la ligne restant atténué. La structure au niveau paragraphe reste basée sur les lignes, donc une réécriture de phrase qui ajoute un saut de ligne apparaît comme une édition au niveau ligne, pas au niveau token.
Pour les langues RTL (arabe, hébreu), le diff utilise des directions CSS logiques (ms-, me- plutôt que ml-, mr-). Sur les locales RTL, la gouttière et les colonnes de lignes s’inversent naturellement ; à l’intérieur de chaque cellule, la direction du texte suit le contenu, donc les chaînes arabes s’affichent de droite à gauche tandis que les marqueurs + et - restent alignés sur la gouttière de début.
La normalisation des fins de ligne reconnaît \r\n (Windows), \n (Unix) et le \r seul (Mac OS classique jusqu’à la version 9). Les trois découpent en lignes séparées, donc un fichier converti d’une plateforme à l’autre ne s’effondre pas en une seule méga-ligne.
11. FAQ
Comment fonctionne un diff texte en ligne ?
Un diff texte découpe les deux entrées en lignes, exécute un algorithme de plus longue sous-séquence commune (typiquement Myers en O((N+M)D)) pour trouver le plus petit ensemble d’insertions et de suppressions, puis met en surbrillance les lignes ajoutées (vert), supprimées (rouge) et inchangées (gris). Une seconde LCS au niveau token marque les mots modifiés à l’intérieur de chaque ligne modifiée. Comparateur de texte effectue toute la comparaison localement dans votre navigateur.
Quelle est la différence entre un diff texte et un JSON diff ?
Le diff texte compare ligne par ligne, ce qui convient à la prose, au code, aux logs et aux contrats. Comparer JSON en ligne comprend le modèle de données JSON : l’ordre des clés n’a aucune importance, les types sont stricts (1 ≠ "1"), les tableaux peuvent être appariés par clé. Collez du JSON dans un diff texte et les réordonnancements de clés ou les espaces feront surface comme des changements que JSON Diff ignore. Utilisez le diff texte pour du contenu non structuré, JSON Diff pour les réponses d’API et les configs.
Pourquoi le diff signale-t-il des lignes entières comme modifiées alors que je n’ai changé qu’un seul mot ?
Ce n’est pas le cas : la ligne est en surbrillance parce que quelque chose dessus a changé, mais à l’intérieur de la surbrillance, seuls les tokens modifiés portent le fond vif (vert pour ajouté, rouge barré pour supprimé). C’est le diff intraligne au niveau du mot : le contexte de la ligne reste lisible tandis que votre œil se pose sur l’édition exacte. Quand trop d’éléments d’une ligne ont changé pour que la surbrillance au niveau du mot soit utile, le diff bascule sur une paire séparée suppression + ajout pour préserver la structure.
Comment ignorer les espaces, la casse ou les lignes vides dans le diff ?
Activez le panneau d’options Ignorer. Ignorer la casse rend A et a équivalents. Ignorer toutes les espaces écrase chaque espace, tabulation et saut de ligne, équivalent à git diff -w. Ignorer les espaces et tabulations de fin reproduit git diff -b et fait taire le bruit CRLF. Ignorer les lignes vides supprime les lignes vides afin que le re-spacing de paragraphes cesse de désaligner le diff. Chaque option est indépendante et persiste entre les sessions.
Qu’est-ce que le format diff unifié ?
Le diff unifié est le format texte ---/+++/@@ -L,C +L,C @@ introduit par GNU diff à la fin des années 1980 et utilisé par git, GitHub, GitLab et la commande Unix patch. Chaque hunk affiche trois lignes de contexte autour du changement, avec - pour supprimé et + pour ajouté. Copiez la sortie unifiée dans un commentaire de PR, collez-la dans git apply, ou lancez patch -p1 < diff.patch : elle s’applique proprement.
Myers ou Patience : quel algorithme de diff est meilleur pour la revue de code ?
Myers est l’algorithme par défaut de git diff et de GNU diff : rapide et mathématiquement minimal, mais il aligne parfois des lignes vides ou des accolades fermantes sans rapport, produisant des diffs qui « se lisent bizarrement ». Patience (Bram Cohen, 2005) s’ancre sur les lignes qui apparaissent exactement une fois dans chaque entrée et applique l’algorithme récursivement entre les ancres, donc les frontières de fonction restent intactes. Utilisez git diff --patience (ou --histogram pour un résultat similaire, légèrement plus rapide) lors de la revue de refactors.
Le texte que je colle est-il envoyé à un serveur ?
Non. Chaque comparaison dans Comparateur de texte tourne localement en JavaScript dans votre navigateur. Votre texte n’est jamais uploadé, journalisé, stocké sur disque ou envoyé à un tiers. Seules vos préférences d’UI (mode d’affichage et interrupteurs d’options d’ignorance) sont sauvegardées dans localStorage pour que la page s’en souvienne à la prochaine visite ; jamais le texte. Vérifiez via DevTools → Network : zéro requête ne part quand vous cliquez sur Diff.
Quelle taille peuvent atteindre les deux entrées ?
La limite pratique est d’environ 5 000 lignes ou 1 Mo par côté. Le diff live se désactive au-delà de 200 Ko combinés et bascule sur un bouton Diff manuel. Au-delà de 5 000 lignes, l’entrée est tronquée avec un avertissement. Pour des fichiers de plusieurs mégaoctets, basculez sur diff -u a.txt b.txt, git diff --no-index a.txt b.txt ou delta : ils streament et gèrent des gigaoctets.