Probleme beim "Vergleich nach Inhalt"

[fruggle]

Wir müssen hier in der Firma öfter Dateien vergleichen, deren Inhalt
aus Daten-Records besteht, die allerdings nur ASCII-Zeichen
beinhalten. Sie werden also als "Text" verglichen, nicht binär.

Diese Dateien werden durchaus mehrere 1000 Bytes lang und
vom Vergleicher als eine Zeile dargestellt.

Beim Vergleichen passiert nun folgendes:
- ist die erste (in meinem Beispiel die längere) Datei länger als 9362
Bytes, dann werden die Zeichen auf dem Bildschirm überlagert (das
9363. Zeichen liegt dann anscheinend über dem ersten usw.)
- ist die zweite (in meinem Beispiel die kürzere) Datei länger als
4096 Bytes, dann werden nicht mehr nur die Unterschiede rot
dargestellt, sondern die ganze Zeile.

Ich habe mir zum Reproduzieren zwei Dateien erstellt: die erste enthält
die Zahlen "1", "2", "3" bis "0" immer wiederholt bis 9363 Bytes. In der
zweiten habe ich die erste kopiert und alle "123" durch "321" ersetzt, um
einen Unterschied zu bekommen. Ausserdem habe ich die Datei auf 4097
Bytes gekürzt.

Kann jemand dieses nachvollziehen? Wie kann man das beheben?
Umschalten auf binär möchte ich nicht, da es ASCII-Daten sind, die
sich als Text leichter lesen lassen.

[icfu]

Klingt wie ein internes Limit. Schick mir die Testdateien mal zu oder hinterleg sie auf irgendeinem Server zum Download, damit man das 1:1 nachvollziehen kann, ohne Fehler zu machen.

Icfu

[van Dusen]

Ist keine direkte Lösung oder Erklärung für das geschilderte Problem und ich kenne die Anforderungen / Gegebenheiten natürlich nicht, aber wäre es als Umgehungslösung eventuell sinnvoll, die zu vergleichenden Dateien vorzuverarbeiten? Also in die zu vergleichenden Dateien zwischen die Datensatz-Grenzen <CR><LF> einzufügen?

Wir machen's bei uns so mit Dateien vom IBM Großrechner, die zunächst binär auf den PC geholt werden und dann mit einem selbstgebastelten Tool vor-aufbereitet werden. Aufgabe des Tools ist u.a. das Einfügen von Datensatz-Trennzeichen. Die Datensätze können eine feste Länge haben oder sie werden per "Lesevorschrift" (XREFs und Copybooks) gelesen, wodurch unterschiedliche Satzarten auch unterschiedliche Längen haben dürfen (das Tool ist so eine Art "File-AID für die ganz Armen" )...

Grüße, van Dusen

[F@ntomas]

Aufgabe des Tools ist u.a. das Einfügen von Datensatz-Trennzeichen. Die Datensätze können eine feste Länge haben oder sie werden per "Lesevorschrift" (XREFs und Copybooks) gelesen, wodurch unterschiedliche Satzarten auch unterschiedliche Längen haben dürfen (das Tool ist so eine Art "File-AID für die ganz Armen" )...

Grüße, van Dusen

... aber einer gute Idee

[fruggle]

Klingt wie ein internes Limit. Schick mir die Testdateien mal zu oder hinterleg sie auf irgendeinem Server zum Download, damit man das 1:1 nachvollziehen kann, ohne Fehler zu machen.

Icfu

Liegen hier.

[icfu]

Hm, das erste was mir auffiel ist, daß diverse Textverarbeitungsprogramme, die ich hier habe, Probleme mit diesen enormen Zeilenlängen machen. Ultra Edit beispielsweise bricht nach 4096 Zeichen automatisch um, Metapad bereits nach 2730 Zeichen.

Bei den Plugins sieht es folgendermaßen aus:
hpg_ed zeigt nur 4096 Zeichen und frißt den Rest, gar nicht gut...
SynPlus meistert diese Herausforderung problemlos und zeigt klaglos alles auf einer Linie an, Respekt!

Der TC Vergleich versucht es wohl richtig, scheitert aber irgendwo, Deine Beobachtungen kann ich bestätigen.

Icfu

[ghisler(Author)]

Ab 4096 Zeichen macht TC keinen Vergleich _innerhalb_ der Zeile mehr, sondern vergleicht nur noch die Zeilen untereinander. Das Limit musste ich setzen, weil sonst u.U. Megabytegrosse Dateien auf 1 Zeile verglichen werden müssten. Das ist dann nicht mehr dynamisch bei der Anzeige möglich, wie das der TC jetzt macht.