On ouvre deux fichiers, pas un caractère ne diffère, et pourtant diff affirme que toutes les lignes ont changé, ou que seule la première ou la dernière ligne diffère. La cause est généralement un caractère invisible à l'écran. Cet article passe en revue ces « différences invisibles » et la façon de les résoudre.
Les caractères de saut de ligne : CRLF, LF, CR
La convention pour marquer un saut de ligne varie selon le système d'exploitation.
| Notation | Octets | Utilisation principale |
|---|---|---|
| LF | 0A (\n) | Linux, macOS, la plupart des outils de développement |
| CRLF | 0D 0A (\r\n) | De nombreux programmes Windows comme le Bloc-notes, protocoles Internet comme l'e-mail et HTTP |
| CR | 0D (\r) | Très anciens Mac OS (avant la version 9) |
Si un fichier est enregistré en CRLF et l'autre en LF, la comparaison par ligne relève en fin de chaque ligne un \r invisible : tout le fichier semble modifié. GNU diff permet d'ignorer cette différence avec --strip-trailing-cr, git diff avec --ignore-cr-at-eol.
Le saut de ligne en fin de fichier
Selon la convention POSIX, chaque ligne d'un fichier texte se termine par un caractère de saut de ligne. Beaucoup d'outils en ajoutent donc un après la dernière ligne, mais certains éditeurs ne le font pas. Dans un diff unifié, cette différence s'affiche ainsi :
@@ -1,2 +1,2 @@ host=example.com-port=8080\ No newline at end of file+port=8080\ No newline at end of file signifie que la ligne juste au-dessus ne se termine pas par un saut de ligne. Dans cet exemple, le contenu est le même : seul le fichier après modification a reçu un saut de ligne final. De nombreux guides de style de code exigent un saut de ligne en fin de fichier, et le réglage « insérer un saut de ligne final » de l'éditeur permet d'uniformiser.
Le BOM : quand seule la première ligne diffère
Il arrive que les trois octets EF BB BF figurent au tout début d'un fichier UTF-8. C'est l'indicateur d'ordre des octets (BOM). L'UTF-8 n'a pas besoin d'indiquer l'ordre des octets, mais certains programmes l'ajoutent pour signaler « ce fichier est en UTF-8 ». Le BOM est invisible : si diff indique que seule la première ligne diffère, pensez-y. Ce site retire le BOM en tête lors du chargement d'un fichier et, lorsqu'une option d'espaces est activée, traite aussi le BOM (U+FEFF) présent dans un texte collé comme un espace.
Tabulations, espaces et espaces spéciaux
- Tabulation et espaces : une tabulation et quatre espaces se ressemblent à l'écran, mais ce sont des caractères différents.
- Espace insécable (NBSP, U+00A0) : se glisse souvent dans un texte copié depuis une page web ou un traitement de texte. En français, il précède régulièrement « : », « ; », « ? », « ! » ou suit le guillemet ouvrant.
- Espace idéographique (U+3000) : peut être saisi par les méthodes d'entrée coréennes, japonaises ou chinoises.
- Espace sans chasse (U+200B) : de largeur nulle, il est totalement invisible, mais compte comme un caractère.
La plupart de ces caractères sont filtrés quand une option d'espaces est activée (les caractères qui ne sont pas classés comme espaces, comme U+200B, peuvent toutefois subsister). En passant le détail dans la ligne au caractère, le surlignage montre l'emplacement exact d'un caractère invisible.
Normalisation Unicode : même lettre, octets différents
La lettre « é » peut s'écrire avec un seul caractère précomposé (U+00E9) ou avec « e » (U+0065) suivi de l'accent aigu combinant (U+0301). De même, la syllabe coréenne « 가 » peut être un caractère précomposé (U+AC00) ou la suite de la consonne initiale ㄱ (U+1100) et de la voyelle ㅏ (U+1161). Unicode appelle la forme précomposée NFC et la forme décomposée NFD (UAX #15). Les deux textes s'affichent à l'identique, mais la comparaison les voit comme des caractères différents. Exemple typique : des noms de fichiers créés sous macOS dont les caractères accentués ou les syllabes coréennes apparaissent décomposés sur un autre système. La solution consiste à convertir l'un des deux textes en NFC avant la comparaison.
Uniformiser les sauts de ligne dans git
Pour un dépôt partagé entre plusieurs systèmes d'exploitation, la configuration de git permet d'uniformiser les sauts de ligne.
core.autocrlf: avectrue, les LF sont convertis en CRLF à l'extraction (checkout) et les CRLF en LF au commit (surtout sous Windows). Avecinput, les CRLF ne sont convertis en LF qu'au commit..gitattributes: les règles sont définies au niveau du dépôt, si bien que le résultat est le même quels que soient les réglages de chacun.
* text=auto
*.sh text eol=lf
*.bat text eol=crlftext=auto normalise en LF, dans le dépôt, les sauts de ligne des fichiers que git reconnaît comme texte ; eol=lf et eol=crlf précisent les sauts de ligne utilisés lors de l'extraction dans le répertoire de travail.
Essayer avec cet outil
L'option Normaliser les fins de ligne du comparateur de texte est activée par défaut : CRLF, CR et LF sont tous traités comme le même saut de ligne, et la présence ou l'absence de saut de ligne en fin de fichier est ignorée. Désactivez-la : le CR en fin de ligne s'affiche comme ␍ et une ligne sans saut de ligne final comme ∅, ce qui rend visibles les différences cachées. Les options liées aux espaces sont décrites dans Options pour ignorer les espaces, et la signification des symboles du résultat dans Lire un diff unifié.