Entwicklertools · Textvergleich
Warum Windows und Unix sich über Zeilenenden nicht einig sind: Die CR-, LF- und CRLF-Geschichte
· Hintergrund
Text-Diff Zeilenenden Software-Historie
Verfolgt Zeilenenden von Schreibmaschinen und Fernschreibern bis hin zu modernen Betriebssystemen und erklärt, warum in jedem plattformübergreifenden Projekt immer noch zwei Konventionen nebeneinander bestehen.
Ein unsichtbarer Charakter, jahrzehntelange Spannungen – beginnt mit dem anhaltenden plattformübergreifenden Ärger
Zeilenenden sind in normalen Editoren unsichtbar, können jedoch für Dateien und Protokolle von Bedeutung sein. In ToolAcre werden CR, LF und CRLF jedoch vor dem Zeilenvergleich normalisiert. Ein Paar, das sich nur in diesen Trennzeichen unterscheidet, erzeugt dasselbe Linienarray und ein identisches Ergebnis.
Dieses Verhalten löst die praktische Frage für diese Route und schränkt gleichzeitig die Diagnosemöglichkeiten ein. Der Vergleich kann nicht nachweisen, welche Newline-Bytes die Originaldateien enthielten, nachdem der Text seine Editoren erreicht hat. Für die Aufbewahrung oder Protokollprüfung ist ein Byte-fähiges Tool erforderlich.
Wagenrücklauf und Zeilenvorschub auf einer Schreibmaschine – erklärt die beiden physischen Aktionen, die die Zeichen ursprünglich beschrieben haben
Die Begriffe Wagenrücklauf und Zeilenvorschub haben physikalische und historische Bedeutungen, aber das Repository enthält keine Schreibmaschinenquelle. Das Wiederholen einer mechanischen Ursprungsgeschichte aus dem Gedächtnis würde gegen den Beweisvertrag verstoßen, selbst wenn der Bericht bekannt vorkäme.
Dieser Artikel behandelt CR daher als die Codeeinheit ` ` und LF als „ ` nur dort, wo die Implementierung sie verwendet. Historische Erläuterungen sollten später anhand von Primärnormen oder Archiven hinzugefügt werden und nicht einer Übersicht entnommen werden, die ausdrücklich keine Quelle darstellt.
Schreibmaschinenbedeutungen sind historische Behauptungen, die externe Quellen erfordern
Ebenso dokumentieren die Quelldateien keine Fernschreibkonventionen oder frühe Betriebssystementscheidungen. Sie offenbaren lediglich eine Kompatibilitätsauswahl im aktuellen JavaScript: Ersetzen Sie jedes CRLF oder einzelne CR durch LF, bevor Sie es aufteilen.
Diese Transformation akzeptiert eingefügten Text, der nach mehreren Konventionen erstellt wurde, ohne die Ausgabe nur mit Endungsänderungen zu füllen. Es handelt sich um eine Implementierungsentscheidung, die in einem regulären Ausdruck sichtbar ist und durch Tests für alle drei Formen fixiert wird.
Der Fernschreiber und die Abstammung des Betriebssystems liegen außerhalb der Repository-Beweise
Es ist üblich, Unix mit LF, Windows mit CRLF und ältere Systeme mit einsamem CR zu assoziieren, aber das aktuelle Repository kann nicht als historischer Beweis für diese Übernahmen dienen. Der sichere Anspruch ist betriebsbereit: Alle drei Eingaben werden innerhalb von `splitLines` zu LF.
Ein Terminal-LF erstellt keine letzte leere Zeile, während Leerzeilen in der Mitte verbleiben. Diese Unterscheidung bedeutet, dass der logische Inhalt erhalten bleibt, auch wenn Unterschiede in den physischen Trennzeichen gelöscht werden. Der Vergleich ist zeilenorientiert und nicht byteerhaltend.
Der Code beweist, dass sich drei Konventionen normalisieren; Es beweist nicht, warum Systeme sie übernommen haben
Einige Netzwerk- und Nachrichtenprotokolle geben genaue Leitungsabschlusszeichen vor, ihre Anforderungen müssen sich jedoch aus ihren Spezifikationen ergeben. Die Normalisierung von ToolAcre macht es für den Nachweis der Konformität mit einem solchen Drahtformat ungeeignet, da der ursprüngliche Trennzeichenbeweis absichtlich entfernt wird.
Verwenden Sie vor dem Parsen einen Hex-Viewer oder Protokollvalidator, wenn genaue CRLF-Sequenzen wichtig sind. Ein sauberes Textdiff-Ergebnis kann übereinstimmende logische Zeilen bestätigen und gleichzeitig einen Fehler auf Transportebene verbergen. Beide Beobachtungen können wahr sein, da die Tools unterschiedliche Fragen beantworten.
Protokollanforderungen erfordern eigene Spezifikationen und werden hier weggelassen
Vergleiche `Alpha beta`, `alpha beta` and `alpha beta` paarweise. Jede erzeugt zwei Zeilen, Alpha und Beta, und keine Hinzufügungen oder Entfernungen. Leerzeichen ignorieren führt nicht zu dieser Gleichheit; Die Normalisierung hat bereits während der Aufteilung stattgefunden.
Fügen Sie nachgestellte Leerzeichen zu einer Beta-Zeile hinzu, und im normalen Modus wird jetzt ein Unterschied gemeldet. Aktivieren Sie „Leerzeichen ignorieren“, damit es möglicherweise verschwindet. Die Sequenz trennt die Behandlung von Zeilenumbrüchen von der Behandlung von Zeilenschlüssel-Leerzeichen und verhindert, dass die falsche Option gutgeschrieben wird.
Arbeitsbeispiel: Alle drei Endformen werden vor den Leerraumoptionen als gleich verglichen
Diese Route konfiguriert keine Editoren, schreibt keine Dateien neu, legt keine Git-Attribute fest und führt keine Massenkonvertierung durch. Außerdem wird das ursprüngliche Trennzeichen in Ergebniszeilen nicht angezeigt. Eingefügte Zeichenfolgen gelangen in eine Vergleichspipeline und nicht in ein Newline-Migrationsdienstprogramm.
Historische Kausalität und Protokollstandards werden bis zur Quellenangabe weggelassen. Diese Einschränkung hinterlässt einen kleineren, aber genauen Artikel: Was drei Konventionen in dieser Implementierung bewirken, welche Leerzeilen bleiben und warum Gleichheit hier keine Byte-Identität herstellt.
Imbiss: Wissen Sie, welche Konvention Ihr Text trägt – fasst den Verlauf zusammen und wie der Textvergleich von ToolAcre dabei hilft, zu bestätigen, ob ein Unterschied nur in den Zeilenenden besteht
Erfahren Sie, welche Beweise das Tool überlebt haben. Nach der Normalisierung kann ToolAcre den Inhalt logischer Zeilen über gängige Trennzeichen hinweg vergleichen. Es kann Ihnen nicht sagen, welche Konvention eine der Quellen verwendet hat oder ob ein nachgeschalteter Verbraucher eine genaue Bytesequenz benötigt.
Verwenden Sie den Browser-Diff für die menschliche Überprüfung und eine Überprüfung auf Byte-Ebene für die Repository- oder Protokolldurchsetzung. Ein Werkzeug ist zuverlässig, wenn seine Transformationen explizit sind; Die Gutachter bleiben dafür verantwortlich, eine auszuwählen, die die Eigenschaft bewahrt, die sie überprüfen müssen.