Entwicklertools · Textvergleich
Jede Zeile geändert? Zeilenenden, nachgestellte Leerzeichen und Stücklisten in einem Diff
· Wie es funktioniert
Text-Diff Zeilenenden Debugging
Diagnostiziert die drei unsichtbaren Ursachen eines Vergleichs, der jede Zeile als unterschiedlich meldet, und zeigt, wie Sie feststellen können, welche Sie haben, bevor Sie dem Autor die Schuld geben.
Dieselbe Datei, zweimal gespeichert, offenbar neu geschrieben – stellt den gemeinsamen Fall einer Datei dar, die auf zwei Betriebssystemen bearbeitet wurde
Zwei Speicherungen können wie ein Neuschreiben aussehen, wenn ein Editor unsichtbare Zeichen ändert, aber das Verhalten von ToolAcre hängt davon ab, welche Zeichen geändert wurden. Es normalisiert Zeilenenden vor dem Abgleich, während Leerzeichen am Rand einer Zeile und ein U+FEFF am Anfang normaler Zeileninhalt bleiben, sofern nicht eine andere Option den Schlüssel ändert.
Erstellen Sie eine Diagnosevorrichtung, anstatt anhand der Farbe zu raten. Vergleichen Sie ein Paar, das sich nur in den Endungen unterscheidet, ein anderes, das sich in den nachgestellten Leerzeichen unterscheidet, und ein drittes mit einer führenden Stückliste. Kontrollierte Paare offenbaren die Grenzen des Werkzeugs zuverlässiger als eine echte Datei, die mehrere unsichtbare Änderungen gleichzeitig enthält.
CRLF im Vergleich zu LF: das Zeichen am Ende jeder Zeile – erklärt, warum Windows Zeilen mit zwei Zeichen beendet, Unix mit einem und wie ein Diff den zusätzlichen Wagenrücklauf erkennt
`splitLines` ersetzt CRLF und einzelnes CR durch LF und teilt sich dann auf. Tests zeigen, dass alle drei Konventionen die gleichen Arrays erzeugen. Daher ist ein reiner CRLF-Unterschied selbst dann nicht sichtbar, wenn „Leerzeichen ignorieren“ deaktiviert ist. Die Behauptung der Gliederung, dass jede Zeile anders sein würde, widerspricht dieser Implementierung.
Ein abschließender Zeilenumbruch erstellt auch keine zusätzliche Zeile. Nach der Aufteilung wird ein leerer Terminaleintrag entfernt. Echte Leerzeilen in der Mitte bleiben Vergleichseinheiten, sodass das Verhalten eine Dateiendekonvention von einer absichtlichen vertikalen Trennung innerhalb des Dokuments unterscheidet.
ToolAcre normalisiert CRLF, CR und LF vor dem Vergleich, sodass Änderungen nur am Ende verschwinden
Nachgestellte Leerzeichen bleiben in den Originalzeilen erhalten. Beim normalen Vergleich haben `name=value` und `name=value ` unterschiedliche Schlüssel. „Leerzeichen ignorieren“ schneidet beide Enden ab und reduziert interne Verläufe, sodass diese Option dafür sorgen kann, dass das Paar übereinstimmt, während der linke Originaltext in der angezeigten gleichen Zeile erhalten bleibt.
Die Bibliothek implementiert auch eine engere Option `ignoreTrailingWhitespace`, die aktuelle Benutzeroberfläche stellt sie jedoch nicht zur Verfügung. Artikel dürfen kein Kontrollkästchen beschreiben, das Benutzer nicht auswählen können. Das mitgelieferte Bedienfeld bietet die Optionen „Groß-/Kleinschreibung ignorieren“, „Alle Leerzeichenunterschiede ignorieren“ und „Lange unveränderte Läufe reduzieren“.
Die Bytereihenfolgemarkierung oben in der Datei – beschreibt das U+FEFF-Zeichen, das einige Editoren UTF-8-Dateien voranstellen, und warum es nur die erste Zeile unterscheidet
Eine UTF-8 Bytereihenfolgemarkierung, die in JavaScript-Text dekodiert wird, ist U+FEFF am Anfang der ersten Zeile. `splitLines` hat keine explizite Stücklistenentfernung. Beim gewöhnlichen Abgleich kann dieses Zeichen dazu führen, dass sich nur die erste Zeile unterscheidet, während spätere Zeilen gleich bleiben.
JavaScript-Leerzeichenoperationen behandeln U+FEFF möglicherweise als Leerzeichen, wenn „Leerzeichen ignorieren“-Aufrufe `trim` aufrufen, dieser Artikel verallgemeinert dies jedoch nicht auf das Dateidecodierungsverhalten. Der Editor erhält Strings; Es liest keine Dateibytes und meldet keine Kodierungen. Überprüfen Sie das tatsächliche Zeichen, wenn die Herkunft auf Byte-Ebene wichtig ist.
Arbeitsbeispiel: Unterscheidung der drei Ursachen – ergibt einen Entscheidungspfad: Ein Unterschied nur in der ersten Zeile zeigt auf eine Stückliste, jede Zeile zeigt auf Enden, verstreute Zeilen zeigen auf nachfolgende Leerzeichen
Beginnen Sie mit „Alpha“. beta` and `alpha beta`: the result is identical. Next compare `alpha beta` with `alpha beta`: Der normale Modus meldet Ersatzzeilen, während der Leerraummodus diese abgleicht. Stellen Sie schließlich dem Alpha einer Seite U+FEFF voran und beobachten Sie den First-Line-Effekt.
Diese Sequenz trennt Ursachen mithilfe von Repository-erprobten Vorgängen. Wenn jede Zeile nach Abschluss der Normalisierung immer noch unterschiedlich ist, untersuchen Sie den Inhalt, die Einrückung oder die nachgestellten Zeichen, anstatt nur CRLF dafür verantwortlich zu machen. Wenn sich nur Zeile eins unterscheidet, überprüfen Sie die führenden Codepunkte, bevor Sie die gesamte Datei neu schreiben.
Verwendung der Leerzeichenoption als Diagnose – zeigt, wie die Aktivierung von „Ignorieren von Leerzeichen“ im Textvergleich von ToolAcre nachgestellte Leerzeichen und Zeilenenderauschen absorbieren kann, sodass echte Änderungen hervorstechen
„Leerzeichen ignorieren“ ist bei nachgestelltem Leerzeichen nützlich, da dadurch Leitungstasten gekürzt und komprimiert werden. Es ist nicht dafür verantwortlich, CRLF gegenüber LF zu verbergen; das ist schon beim Splitten passiert. Die Trennung dieser Phasen verhindert eine irreführende Schlussfolgerung darüber, welche Option den Vergleich repariert hat.
Führen Sie beide Ansichten aus, da durch das Trimmen sinnvolle Einrückungen verborgen werden können und durch das Komprimieren Werte mit fester Breite oder Zeichenfolgenliterale geändert werden können. Ein ruhiges normalisiertes Ergebnis besagt, dass die Schlüssel unter dieser Transformation übereinstimmen. Es wird nicht bescheinigt, dass die Originaldateien byteidentisch oder semantisch austauschbar sind.
Der Leerraummodus diagnostiziert nachfolgende Leerzeichen, während Zeilenenden bereits normalisiert sind
Textdiff konvertiert keine Dateien, konfiguriert Git nicht, ändert keine Editoreinstellungen und stellt keine hexadezimalen Bytes zur Verfügung. Es akzeptiert eingefügte Zeichenfolgen und meldet Zeilenoperationen. Ratschläge zu `.gitattributes`, `core.autocrlf` oder Codierungsreparatur gehören zu Tools, deren Verhalten separat überprüft werden kann.
Das Tool kann auch nicht erkennen, wie ein unsichtbares Zeichen in den Text gelangt ist. Ein Formatierer, eine Zwischenablage, ein Decoder oder eine manuelle Bearbeitung kann dieselbe Zeichenfolge erzeugen. Verwenden Sie den Vergleich, um die Zeile zu lokalisieren, und überprüfen Sie dann die Quellpipeline, bevor Sie eine Ursache zuweisen.
Fazit: Überprüfen Sie Unsichtbares, bevor Sie dem Autor die Schuld geben – fasst den Diagnosepfad zusammen und vermerkt, dass der Vergleich in Ihrem Browser ausgeführt wird, sodass vertrauliche Dateien auf Ihrem Computer bleiben
Überprüfen Sie die unsichtbaren Zeichen in einer festen Reihenfolge: Endungen, abschließende oder interne Leerzeichen, dann führende Sonderzeichen. Die Tests von ToolAcre liefern ein eindeutiges Ergebnis für die erste Kategorie und seine Optionen helfen, die zweite zu isolieren. Der dritte benötigt möglicherweise einen Charakterinspektor außerhalb dieser Route.
Durch die browserseitige Zeilenaufteilung verschwinden plattformübergreifende Endungsunterschiede von vornherein. Das ist praktisch, bedeutet aber auch, dass dieses Tool nicht nachweisen kann, dass zwei Quelldateien dieselben physischen Newline-Bytes verwenden. Wählen Sie ein Byte-fähiges Dienstprogramm, wenn die Beibehaltung einer exakten Wire- oder Repository-Darstellung erforderlich ist.