2 Textdateien vergleichen

[Gausi]

Warum bei zwei Dateien überhaupt die Hashwerte bilden, wenn man nur wissen will, ob die beiden Files gleich sind? Den Aufwand, den Hash zu berechnen (gut, der hält sich in aller Regel in Grenzen), kann man sich doch sparen, und einfach den Dateiinhalt vergleichen. Oder sind Dinge wie CompareMem so CPU-lastig? :gruebel:

Mit Hashwerten würde ich nur arbeiten, wenn ich mehr als nur eine Datei habe, und z.B. in einem Dokumenten-Verwaltungssystem checken möchte, ob eine Datei bereits im System vorhanden ist oder nicht (zumindest mit einer i.A. ausreichend hohen Wahrscheinlichkeit).

[freimatz]

Zitat:

Zitat von Gausi (Beitrag 1474187)

Warum bei zwei Dateien überhaupt die Hashwerte bilden, wenn man nur wissen will, ob die beiden Files gleich sind?

Weil es nichts existierendes gibt und ein

Delphi-Quellcode:

THashMD5.GetHashStringFromFile(file1)=THashMD5.GetHashStringFromFile(file2)

schnell hingeschrieben ist, Geschwindigkeit keine Rolle spielt und man noch mehr zu tun hat. ;-)

[Delphi.Narium]

Zwei Hashwerte getrennt von zwei 4 GB großen (oder auch größeren) Dateien zu berechnen, dürfte deutlich einfacher sein, als beide Dateien ins Ram zu laden und sie dann dort zu vergleichen.

Zum Dublettensuchen nehme ich seit Jahr und Tag MD5. Ist sau schnell und treffsicher. Und Du musst nicht beide Dateien gleichzeitig im Speicher halten und Du muss nicht mal was Programmieren, um den Vergleich durchzuführen.

Einfacher, als mit dem Beispiel von KodeZwerg, kriegst Du das nicht hin und alles mit bereits vorhanden Hausmitteln, mit hinlänglich bekannten und verbreiteten Algorithmen.

In meiner Musikdateienverwaltung steht zu jeder Datei auch der entsprechende MD5-Hash. Kommt 'ne neue Datei, wird deren MD5 berechnet und der eindeutige Index haut mir das beim Speichern direkt um die Ohren.

Wie willst Du sowas denn einfacher machen?

So kannst Du sogar zwei Dateien vergleichen, von denen Du bis dahin nichtmal wusstest, dass ein Vergleich zur Dublettenerkennung erforderlich sein könnte.

OK: Der Vorschlag von freimatz ist noch kürzer, den kann man klar verständlich irgendwo im Quelltext in 'nem If then else stehen haben und fertig.

[einbeliebigername]

Hallo,

Zitat:

Zitat von KodeZwerg (Beitrag 1474183)

Ein Hash wird über die Bytes generiert.

Ja, richtig. Genauer gesagt über die gesamten Bytes. Sonst macht das garkeinen Sinn. Aber dazu später mehr.

Zitat:

Zitat von KodeZwerg (Beitrag 1474183)

Hättest Du die Güte ein Beispiel zu posten damit das was Du sagst nachvollziehbar ist?

Nein. Das ist mir zu aufwendig, bzw. der Strom ist mir zu teuer, zwei Dateien zu suchen wo dein Algorithmus falsche Ergebnisse liefert. Mir reicht es das es diese zwei Dateien theoretisch geben kann.

Zitat:

Zitat von KodeZwerg (Beitrag 1474183)

Das 2 unterschiedliche Dateien den gleichen MD5 Hash liefern... möglich ja aber eher die Ausnahme als die Regel.

Es reicht, dass es möglich ist. Denn wir wollen Programme scheiben die 100,0% richtig funktionieren.

Zitat:

Zitat von KodeZwerg (Beitrag 1474183)

so etwas hier wollte ich verhindern...

Beim überfliegen scheint das aber erst mal mit jedem Pärchen 100,0% richtig zu funktionieren.

Zitat:

Zitat von KodeZwerg (Beitrag 1474183)

Ich hatte halt Geschwindigkeit im Vordergrund.

Da verliert deinen Lösung mit Hash aber haushoch. Was ist denn langsam? Über den byteweisen vergleich gähnt die CPU heutzutage nur müde. Es ist doch das lesen der Dateien von der Festplatte, was langsam ist. Selbst bei einer sehr guten SSD hat die CPU neben bei noch genügend Zeit. Und das Problem an deiner Lösung mit Hash ist, neben dem Problem mit der mangelnden Aussagekraft bei gleichen Hashwerten, dass bei beiden Dateien immer der gesamte Inhalt gelesen werden muss, selbst wenn das erste Byte schon unterschiedlich ist. Und selbst wenn die heutigen CPU's die Berechnung eines Hash spielend erledigen, ist der Aufwand für die Hash-Berechnungen deutlich höher als für den byteweisen Vergleich.

Hash’s kann man einsetzten um den kreuzweisen Vergleich vieler Dateien zu optimieren. Dabei muss man dann aber auf die Eigenheiten der Hash-Algorithmen eingehen. Und läuft Gefahr, dass die Optimierung bei manchen Situationen nach hinten los geht.

[Rollo62]

Ich denke eigentlich auch, dass das direkte Vergleichen mit frühem Abbruch am am schnellsten sein wird.
Zumindest wenn es statistisch verteilt ist, und sich die Files nicht nur am Ende unterscheiden.

Es sei denn, der Hash wird für spätere Vergleiche "aufgehoben",
dann könnte der Hash auch Sinn machen.

Ich bin aber gar nicht sicher ob MD5 überhaupt noch zeitgemäß ist,
das kommt doch aus der Hash-Urzeit.
Gibt es da nicht mittlerweile viel effizientere Hashes für große Text- und Binärdateien ?

[freimatz]

Falls das interessiert würde ich bei git nachschauen.

[Rollo62]

Ja, gute Idee.
So einfach ist das bei GIT aber anscheinend auch nicht:
https://www.golem.de/news/hashfunkti...02-139145.html

[TigerLilly]

Hat mich jetzt interessiert.

Bei identen Dateien, egal welche Größe, ist Hash schneller, weil der Vergleich ja bis zum letzten Byte laufen muss.
Wenn es Unterschiede gibt, und auch wenn die erst im letzten Viertel sind, ist der Vergleich schneller, auch hier unabhängig von der Größe.

Die Dateien waren Textdateien, Zeilen zwischne 1000 und 100.000. Wobei die Unterschiede nicht groß sind:

Zeilen: 100000 Änderung bei 0 Dauer 341 296
Zeilen: 100000 Änderung bei 25 Dauer 257 305
Zeilen: 100000 Änderung bei 75 Dauer 302 350

Zeiten sind Millisekunden, Vergleich und dann Hash. Die "Änderung bei" gibt an, in welchem Teil der Datei der erste Unterschied ist, in %.
Um den Einfluß des Windows Cache zu elimieren, erfolgt der Vergleich mehrfach und die Zeit wird gemittelt.

[Gausi]

Zitat:

Zitat von TigerLilly (Beitrag 1474208)

Bei identen Dateien, egal welche Größe, ist Hash schneller, weil der Vergleich ja bis zum letzten Byte laufen muss.

Und beim Hashen muss nicht die gesamte Datei gelesen und verarbeitet werden? Mir leuchtet immer noch nicht ein, wieso hashen schneller sein soll bzw. kann. Wie hast du denn die Textdateien verglichen? Mit StringList1.Text = StingList2.Text, von dem weiter vorne schon geklärt wurde, dass das alles andere als optimal ist? (Egal ob die Ressource "Zeit" oder "Speicher" betrachtet wird).
Der Weg über CompareMem (deutlich mehr "eigener Code", was ja auch ein Maß für Effizienz sein kann) sollte eigentlich deutlich schneller sein als hashen ...

[Rollo62]

Zitat:

Zitat von TigerLilly (Beitrag 1474208)

Bei identen Dateien, egal welche Größe, ist Hash schneller, weil der Vergleich ja bis zum letzten Byte laufen muss.

Wundert mich aber,
Byte-Vergleich ist doch optimal schnell, wohingegen der der Hash jedes Byte Berechnen, verschieben und sonstwie vermuscheln muss.
https://de.wikipedia.org/wiki/Messag...st_Algorithm_5