Outils de développement · Comparaison de texte
Chaque ligne a été modifiée ? Fins de ligne, espaces de fin et nomenclatures dans un Diff
· Comment ça marche
texte-diff fins de ligne débogage
Diagnostique les trois causes invisibles d'une comparaison qui rapporte chaque ligne comme différente et montre comment savoir laquelle vous avez avant de blâmer l'auteur.
Le même fichier, enregistré deux fois, apparemment réécrit — constitue le cas courant d'un fichier édité sur deux systèmes d'exploitation
Deux sauvegardes peuvent ressembler à une réécriture lorsqu'un éditeur modifie des caractères invisibles, mais le comportement de ToolAcre dépend des caractères modifiés. Il normalise les fins de ligne avant la correspondance, tandis que les espaces au bord d'une ligne et un U+FEFF au début restent le contenu de la ligne ordinaire à moins qu'une autre option ne modifie la clé.
Construisez un appareil de diagnostic au lieu de deviner à partir de la couleur. Comparez une paire ne différant que par les terminaisons, une autre différant par les espaces de fin et une troisième avec une nomenclature de début. Les paires contrôlées révèlent les limites de l'outil de manière plus fiable qu'un fichier réel contenant plusieurs modifications invisibles à la fois.
CRLF versus LF : le caractère à la fin de chaque ligne – explique pourquoi Windows termine les lignes avec deux caractères, Unix avec un, et comment un diff voit le retour chariot supplémentaire
`splitLines` remplace CRLF et le CR solitaire par LF, puis se divise. Les tests établissent que les trois conventions produisent les mêmes tableaux. Par conséquent, une différence CRLF uniquement est invisible même lorsque Ignorer les espaces est désactivé ; l’affirmation du plan selon laquelle chaque ligne serait différente contredit cette implémentation.
Une nouvelle ligne finale ne crée pas non plus de ligne supplémentaire. Après le fractionnement, une entrée de terminal vide est supprimée. Les véritables lignes vides au milieu restent des unités de comparaison, de sorte que le comportement distingue une convention de fin de fichier d'une séparation verticale intentionnelle à l'intérieur du document.
ToolAcre normalise CRLF, CR et LF avant la comparaison, de sorte que les modifications de fin uniquement disparaissent
Les espaces de fin restent dans les lignes d'origine. Avec une comparaison ordinaire, `name=value` et `name=value ` ont des clés différentes. Ignorer les espaces supprime les deux extrémités et réduit les séquences internes, de sorte que cette option puisse faire correspondre la paire tout en préservant le texte original de gauche dans la ligne égale affichée.
La bibliothèque implémente également une option `ignoreTrailingWhitespace` plus étroite, mais l'interface utilisateur actuelle ne l'expose pas. Les articles ne doivent pas décrire une case à cocher que les utilisateurs ne peuvent pas sélectionner. Le panneau fourni propose Ignorer la casse, Ignorer toutes les différences d'espaces et Réduire les longues exécutions inchangées.
La marque d'ordre des octets en haut du fichier — décrit le caractère U+FEFF que certains éditeurs ajoutent aux fichiers UTF-8 et pourquoi seule la première ligne diffère.
Une marque d'ordre d'octet UTF-8 décodée en texte JavaScript est U+FEFF au début de la première ligne. `splitLines` n'a pas de suppression explicite de nomenclature. Avec une correspondance ordinaire, ce caractère ne peut différer que la première ligne tandis que les lignes suivantes restent égales.
Les opérations d'espacement JavaScript peuvent traiter U+FEFF comme des espaces lorsque Ignorer les espaces appelle `trim`, mais cet article ne généralise pas cela dans le comportement de décodage de fichiers. L'éditeur reçoit des chaînes ; il ne lit pas les octets des fichiers ni ne rapporte les encodages. Inspectez le caractère réel lorsque la provenance au niveau de l’octet est importante.
Exemple concret : distinguer les trois causes – donne un chemin de décision : une différence de première ligne uniquement pointe vers une nomenclature, chaque ligne pointe vers des fins, les lignes dispersées pointent vers des espaces de fin.
Commencez par `alpha beta` et `alpha beta` : le résultat est identique. Comparez ensuite `alpha beta` avec `alpha beta` : le mode ordinaire signale les lignes de remplacement, tandis que le mode espaces les correspond. Enfin, préfixez l’alpha d’un côté avec U+FEFF et observez l’effet first-line.
Cette séquence sépare les causes à l'aide d'opérations éprouvées par le référentiel. Si chaque ligne diffère encore après la fin de la normalisation, étudiez le contenu, l'indentation ou les caractères de fin plutôt que de blâmer CRLF seul. Si seule la première ligne diffère, examinez ses principaux points de code avant de réécrire l'intégralité du fichier.
Utilisation de l'option d'espacement comme diagnostic : montre comment l'activation de l'ignorance des espaces dans la comparaison de texte de ToolAcre peut absorber le bruit des espaces de fin et de fin de ligne afin que les modifications réelles se démarquent.
Ignorer les espaces est utile pour le bruit des espaces de fin, car il coupe et condense les clés de ligne. Il n'est pas responsable de cacher le CRLF contre le LF ; cela s'est déjà produit lors de la scission. Garder ces étapes séparées évite de tirer des conclusions trompeuses sur l’option qui a réparé la comparaison.
Exécutez les deux vues, car le découpage peut masquer une indentation significative et la condensation peut modifier les valeurs de largeur fixe ou les littéraux de chaîne. Un résultat normalisé et discret indique que les clés correspondent sous cette transformation. Il ne certifie pas que les fichiers originaux sont identiques au niveau des octets ou sémantiquement interchangeables.
Le mode Espaces diagnostique les espaces de fin, tandis que les fins de ligne sont déjà normalisées
Text diff ne convertit pas les fichiers, ne configure pas Git, ne modifie pas les paramètres de l'éditeur et n'expose pas les octets hexadécimaux. Il accepte les chaînes collées et signale les opérations de ligne. Les conseils sur `.gitattributes`, `core.autocrlf` ou la réparation de l'encodage appartiennent à des outils dont le comportement peut être vérifié séparément.
L'outil ne peut pas non plus distinguer la manière dont un caractère invisible a saisi le texte. Un formateur, un presse-papiers, un décodeur ou une édition manuelle peuvent produire la même chaîne. Utilisez la comparaison pour localiser la ligne, puis inspectez le pipeline source avant d'attribuer une cause.
À retenir : vérifiez les invisibles avant de blâmer l'auteur – résume le chemin de diagnostic et note la comparaison exécutée dans votre navigateur, afin que les fichiers sensibles restent sur votre ordinateur
Vérifiez les invisibles dans un ordre fixe : fins, espaces de fin ou internes, puis caractères spéciaux de début. Les tests de ToolAcre donnent un résultat ferme pour la première catégorie et ses options permettent d'isoler la seconde. Le troisième peut avoir besoin d'un inspecteur de caractère en dehors de cet itinéraire.
La division des lignes côté navigateur fait disparaître les différences de fin entre plates-formes de par sa conception. C'est pratique, mais cela signifie également que cet outil ne peut pas prouver que deux fichiers sources utilisent les mêmes octets de nouvelle ligne physiques. Choisissez un utilitaire prenant en charge les octets lorsque la préservation d'une représentation exacte de fil ou de référentiel est requise.