Entwickler-Ecke :: Thema anzeigen - 2 dateien vergleichen

Entwickler-Ecke

Windows API - 2 dateien vergleichen

Delete - Mi 13.08.03 19:59
Titel: 2 dateien vergleichen

hey, ich habe zwei txt dateien und möchte gerne testen, ob der inhalt der beiden dateien gleich ist, oder nicht. (möglichst automatisch :)) wisst ihr, wie ich das machen könnte??

nGerrit

UC-Chewie - Mi 13.08.03 20:01

1. Möglichkeit: Einlesen in ein Array und über CompareMem vergleichen. Ist aber langsam und bei großen Dateien speicherfressend

2. Möglichkeit: Bilden der Hashwerte (CRC, MD5, etc.) beider Dateien und diese vergleichen. Schneller.

Delete - Mi 13.08.03 20:50

dateien sind nicht groß 1kb.. wie genau bekomm ich die in ein array??? nGerrit

Adrian - Mi 13.08.03 21:27

Servus,

wie wär's mit "Shellexecute" und dem guten alten DOS-Befehl "FC"?

Gruß,

Adrian

BungeeBug - Mi 13.08.03 21:29

wie wär mal wieder mit dem genialen MD5 Algo? ... so genau schnell und sicher is FC unter Garantie nicht ;)

AndyB - Mi 13.08.03 22:50

BungeeBug hat folgendes geschrieben:

wie wär mal wieder mit dem genialen MD5 Algo?

Und was passiert, wenn man zwei Dateien erwischt, die den selben MD5 Wert haben, aber nicht identisch sind?

MD5 ist nicht eindeutig. Wenn das nämlich der Fall wäre, dann hätten die Erfinder von MD5 wohl die beste Komprimierungsmethode gefunden.

Delete - Mi 13.08.03 23:09

hey :) könnt ihr mir sagen, wie ich eine zeile einer txt datei in einen string einlesen kann? ich bekomms nicht hin :(

nGerrit

AndyB - Mi 13.08.03 23:47

Wenn du mit TextFile arbeitest:

Delphi-Quelltext

1:	ReadLn(FileVariable, StringVariable);

Oder, wenn du mit TStringList arbeitest:

Delphi-Quelltext

1:	StringVariable := Lines[Index];

Oder wenn du mit Streams arbeitest:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

var Ch: Char;
begin
  S := '';
  repeat
    Stream.Read(Ch, SizeOf(Ch));
    if not (Ch in [#10, #13]) then
      S := S + Ch;
  until Ch = #10;
end;

Delete - Do 14.08.03 00:19

jau thx. und was, wenn ich die zweite zeile (eigentlich 8-12)auslesen will?

Delete - Do 14.08.03 04:00

Ein Zeilenumbruch ist aber #13#10 unter Windows. :wink:

BungeeBug - Do 14.08.03 09:20

AndyB hat folgendes geschrieben:

BungeeBug hat folgendes geschrieben:

wie wär mal wieder mit dem genialen MD5 Algo?

MD5 ist eindeutig nur kann man es nicht rückganägig machen. Sprich du kannst ja nicht aus der Summe aller 1sen fest stellen wo die eigendlich hingehören. <- So funktioniert zwar der MD5 nicht aber als Beispiel is das garnicht schlecht :)

AndyB - Do 14.08.03 12:55

Luckie hat folgendes geschrieben:

Ein Zeilenumbruch ist aber #13#10 unter Windows. :wink:

Ja. Und das berücksichtigt meine Auslesefunktion auch. (Genauer hinschauen).

recall - Do 14.08.03 14:26

Ich würde es so machen:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:

procedure compare(File1, File2: String): Boolean;
var
  a, b: TextFile;
  Eq: Boolean;
  s1, s2: String;
begin
  AssignFile(a, File1);
  Reset(a);
  AssignFile(b, File2);
  Reset(b);
  Eq := True;
  While (not Eof(a)) and (not Eof(b)) and (not Eq) do
  begin
    Readln(a, s1);
    Readln(b, s2);
    if s1<>s2 then Eq := False;
  end;
  CloseFile(a);
  CloseFile(b);
  Result := Eq;
end;

Parameter beim Aufrufen sind wohl klar ;) .

@BungeeBug: Also NEIN. Es gibt keinen eindeutigen nicht umkehrbaren Algorithmus. Das wäre auch zu schön.

Das ganze ist mathematisch beweisbar, aber auch so:
Vergleich mal den MD5-Code von: 1101 und 0111 :)
(Ich kenn' MD5 nicht, nur aus dem was du geschrieben hast, ist es wohl die Summe aller Einsen ?)

=> Es gibt KEINE nicht reversible eindeutige Funktion, wenn es so wäre, dann könnte ich aus dem MD5-Code wieder einen MD5-Code machen usw... Am Ende wäre es dann eine 1 oder eine 0. Das kann ja wohl nicht eindeutig ein bestimmter vorher riesiger Datensatz gewesen sein, oder ?

=> Noch ein Grund: Vielleicht kennst du dich mit Verschlüsselung ein wenig aus ? Das was du beschreibst, hätten wohl alle Programmierer eines asymmetrischen Verfahrens gerne :) . Dann könnte man beiden PCs einen Anfangscode geben und daraus einen nicht reversiblen Code erzeugen => DIE ABSOLUT SICHERSTE VERSCHLÜSSELUNG ! EIN QUASI-ONE-TIME-PAD.

Viele Grüsse.

P.S.: Der obige Code ist im FOrum geschrieben, kann sein, dass ich Params vertauscht habe.

ShadowThief - Do 14.08.03 14:32

AndyB hat folgendes geschrieben:

Oder wenn du mit Streams arbeitest:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

var Ch: Char;
begin
  S := '';
  while Ch <> #10 do
  begin
    Stream.Read(Ch, SizeOf(Ch));
    if not (Ch in [#10, #13]) then
      S := S + Ch;
  end;
end;

ich glaube, das geht nur so:

Delphi-Quelltext

1:	Stream.Read(Ch[1], SizeOf(Ch));

shadow.

AndyB - Do 14.08.03 14:48

Zitat:

ich glaube, das geht nur so:

Glaube nicht, sondern probiere es aus. Der Compiler wird dir aber dabei was husten, denn ein Char ist ein Char und kein String. Anders ausgedrückt: Wie sieht denn das erste Zeichen eines einzelnen Zeichens aus? Und wie das zweite, dritte, ...?

Motzi - Do 14.08.03 15:09

MD5 ist eine OneWay-Hash Funktion die einen 128Bit Hash-Wert berechnet. D.h. es praktisch jede 2^128te Datei hat denselben MD5-Hash bzw als Zahl ausgedrückt jede 340282366920938463463374607431768211456te Datei erzeugt denselben Hash-Wert! Da Hashfunktionen normalerweise mehrere Werte auf ein und denselben Wert abbilden, kann man mit ihnen zwar nicht hundertprozentig aber mit ausreichender Sicherheit entscheiden ob 2 Strings identisch sind.

Aber ich würde SHA1 statt MD5 nehmen (erzeugt einen 160Bit Hash-Wert)!

PS: gute Hash-Funktionen sind kollisionsfrei, d.h. es ist schwierig 2 Originale mit demselben Hash-Wert zu generieren! Also nix mit "die Summe aller Einsen", das ist schon wesentlich komplexer mit tiefem math. Hintergrund!

recall - Do 14.08.03 19:40

@Motzi: Und bei welcher Länge soll diese Zahl gelten (Dateilänge) ?
Denn die sich-wiederholen-Zahl (Q) ist bei solchen Verfahren Q~size(File)^n n Element aus N>0.

Beweis: Nimm 2 Dateien mit je 1 Byte Länge ;).

Viele Grüsse.

P.S.: Aber man kann so eine Funktion ja als vorab-Test nehmen.
Erst wenns stimmt soll das Prog genauer gucken :D .

Motzi - Do 14.08.03 19:50

@recall: sorry, komm jetzt nicht ganz mit auf was du hinaus willst.. kannst du das mal näher erleutern?

recall - Do 14.08.03 20:06

Zitat:

340282366920938463463374607431768211456te Datei erzeugt denselben Hash-Wert!

Das geht doch gar nicht !! Nimm einfach mal eine Datei mit 1 Byte Länge.
Es gibt nur 256 Möglichkeiten, wie die Datei aussehen kann ;) .

Das jetzt nur ganz vereinfacht gesagt...
Also, ich will damit sagen, dass deine Zahl nur für EINE Dateigröße gilt, alle anderen erfasst du damit nicht.

Sollte diese Zahl jedoch die Wahrscheinlichkeit angeben, die wievielte Datei unter oo-vielen den gleichen Hash-Wert erzeugen, so würde ich die Methode wegschmeißen, denn es kann genauso gut sein, dass eine Datei mit MD5("001") = MD5("101") !

Viele Grüsse.

ShadowThief - Do 14.08.03 21:17

AndyB hat folgendes geschrieben:

Zitat:

ich glaube, das geht nur so:

huuuuups. hab mich jetzt total vertan. ich hab aus irgendeinem
unerklärlichen grund gedacht ch is ein string, aber es steht ja da, dass
es ein Char ist, außerdem würde man einen string nicht ch nennen.

ääähmm ... sorry.

shadow.

Motzi - Fr 15.08.03 13:00

recall hat folgendes geschrieben:

Zitat:

340282366920938463463374607431768211456te Datei erzeugt denselben Hash-Wert!

Das geht doch gar nicht !! Nimm einfach mal eine Datei mit 1 Byte Länge.
Es gibt nur 256 Möglichkeiten, wie die Datei aussehen kann ;) .

Ok, dann gibt es für diese Datei nur 256 Möglichkeiten, aber da der Hash-Wert 128 Bit hat kann er auch mehr als 256 verschiedene Werte annehmen! :roll: Sprich für jede der 256 Dateien kann ein eigener Hash-Wert gebildet werden. Soll heißen, in der Größenordnung von Dateien mit bis zu 16 Bytes (128Bit) ist der Hash-Wert sogar eindeutig! Für alle größeren Dateien gilt die Wahrscheinlichkeit von 1:2^128 dass sie denselben Hash-Wert erzeugen.

Zitat:

Sollte diese Zahl jedoch die Wahrscheinlichkeit angeben, die wievielte Datei unter oo-vielen den gleichen Hash-Wert erzeugen, so würde ich die Methode wegschmeißen, denn es kann genauso gut sein, dass eine Datei mit MD5("001") = MD5("101") !

Nein..! Hier mal ein Zitat aus meiner Fachbereisarbeit:

Zitat:

Hashfunktionen sind Einwegfunktionen die eine beliebig lange Nachricht M verarbeiten und dabei einen Hashwert h fester Länge erzeugen:
h = H(M) , wobei h die Länge m hat
Viele Funktionen akzeptieren Eingaben beliebiger Länge und erzeugen daraus eine Ausgabe fester Länge, doch Einweg-Hashfunktionen besitzen zusätzliche Eigenschaften, die diesen Namen erst rechtfertigen:

Zu gegebenem M ist es leicht, h zu berechnen.
Zu gegebenem h ist es schwer, ein M zu berechnen für das gilt H(M)=h
Zu gegebenem M ist es schwer, eine andere Nachricht M' zu berechnen für die gilt H(M)=H(M')

Der Zweck von Einweg-Hashfunktionen liegt darin, einen Fingerabdruck der Eingabe anzulegen, d.h. einen Wert zu erzeugen, der etwas darüber aussagt, ob eine bestimmteEingabe aller Wahrscheinlichkeit nach mit dem tatsächlichen Original übereinstimmt. Da Hashfunktionen normalerweise mehrere Werte auf ein und denselben Wert abbilden, können wir mit ihnen zwar nicht hundertprozentig, aber mit ausreichender Sicherheit entscheiden, ob zwei Eingaben identisch sind.

barfuesser - Fr 15.08.03 14:18
Titel: eindeutig oder reversibel

recall hat folgendes geschrieben:

=> Es gibt KEINE nicht reversible eindeutige Funktion,

Eine eindeutige nicht reversible Funktion ist das Quadrieren einer Zahl. Eindeutig heißt, daß ich aus einem Objekt O1 mittels einer Vorschrift immer wieder nur ein und das selbe neue Objekt O2 generieren kann. Wenn das Ganze reversibel ist, handelt es sich um eine eineindeutige Abbildung, wie z.B. die Negation. Bei MD5 handelt es sich um einen eindeutigen aber nicht um einen eineindeutigen Algorithmus.

barfuesser

Udontknow - Fr 15.08.03 14:32

Der Datenbank-Spezie wird es mit Relationen beschreiben:

Relation Datei -> Hash : n -> 1
Ich habe mehrere Dateien, die den gleichen Hashcode erzeugen, aber eine Datei erzeugt immer denselben Hashcode.

Zitat:

Soll heißen, in der Größenordnung von Dateien mit bis zu 16 Bytes (128Bit) ist der Hash-Wert sogar eindeutig!

Wenn du mit eindeutig meinst, daß dann jedem Hash nur eine Datei zugeordnet ist, liegst du falsch: Das hängt von dem verwendeten Hash ab.

Es kann in dieser Situation sein, daß der Hash eineindeutig ist, er muss es aber nicht sein.

Cu,
Udontknow

Motzi - Sa 16.08.03 09:18

Udontknow hat folgendes geschrieben:

Es kann in dieser Situation sein, daß der Hash eineindeutig ist, er muss es aber nicht sein.

Das stimmt schon, aber allein von der Länge des Hash-Wertes wäre es möglich in dieser Größenordnung eindeutig zu sein. Und wenn der Hash gut und kollisionsfrei ist hat man gute Chancen, dass das zutreffend ist.

AndyB - Sa 16.08.03 11:13

Bei MD5 müsst ihr trotzdem beide Dateien komplett einlesen. Da kann man die auch so überprüfen und bei der ersten nicht Übereinstimmung abbrechen. MD5 hingegen muss erst einmal auf die gesamten Daten angewendet werden. Was von beiden ist dann wohl schneller? (vorausgesetzt der Unterschied der beiden Dateien ist nicht das letzte Byte)

Udontknow - So 17.08.03 13:30

@AndyB:

Wenn ich beide Hashes erstellen muss, brauche ich beide Dateien, das ist richtig.

Aber es reicht zum Beispiel völlig aus, den Hash einer heruntergeladenen Datei zu erstellen und mit dem vom Publizierer bereitgestellten Hash zu vergleichen, um eine Authentizität der Datei festzustellen.

So wird es ja bei vielen Opensource-Projekten gemacht, um Virenbefall o.ä. auszuschliessen.

Cu, :)
Udontknow

AndyB - So 17.08.03 16:29

Udontknow hat folgendes geschrieben:

Aber es reicht zum Beispiel völlig aus, den Hash einer heruntergeladenen Datei zu erstellen und mit dem vom Publizierer bereitgestellten Hash zu vergleichen, um eine Authentizität der Datei festzustellen.

Und wo war hier die Rede von einer Checksum Datei?

Udontknow - So 17.08.03 18:28

Wieso? Es geht darum, zwei Dateien zu vergleichen.

Wenn man nun nicht beide Dateien vor Ort hat, ist es sinnvoll, nicht die andere Datei erst zu besorgen und die Dateien selber zu vergleichen, sondern die Hashes zu vergleichen.

Cu,
Udontknow

AndyB - So 17.08.03 23:18

Udontknow hat folgendes geschrieben:

Wieso? Es geht darum, zwei Dateien zu vergleichen.

Genau.

Zitat:

Wenn man nun nicht beide Dateien vor Ort hat

Lese dir einmal die Ausgangsfrage durch.

Zitat:

hey, ich habe zwei txt dateien und möchte gerne testen, ob der inhalt der beiden dateien gleich ist, oder nicht. (möglichst automatisch ) wisst ihr, wie ich das machen könnte??

Udontknow - Mo 18.08.03 07:40

Na gut! *Geschlagengeb*

Aber der Imperativ Singular von "Lesen" ist "Lies". :mrgreen:

Cu,
Udontknow

AndyB - Mo 18.08.03 09:36

Udontknow hat folgendes geschrieben:

Aber der Imperativ Singular von "Lesen" ist "Lies".

Hey, in der Deutschen Sprache ist "alles" erlaubt.

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!