Hi,

ich habe mal 'ne Ferage zum CRC einer Datei. Meises Wissens ist es ja recht einfach einen CRC bzw. besser gesage eine Checksumme einer
Datei zu erstellen. Das einfachste dürfte nun mal sein eine Quersumme der in der/ einer Datei enthaltenen Bytes zu erstellen.

zB so:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  fs: TFileStream;
  c: integer;
  crc: int64;
  crc2: int64;
  count: integer;
begin
  fs := TFileStream.Create(ParamStr(0), fmOpenRead {or ...} );
  try
    c := 0;
    crc := 0;
    crc2 := 0;
    count := 0;

    fs.Position := 0;

    // "- sizeof(cardinal)" als Platzhalter
    while fs.Position <> fs.Size - sizeof(crc2) do
    begin
      fs.Read(c, 1);
      crc := crc + c + count; // count => zb. indexen der Nullwerte
    end;

    fs.Position := fs.Size - sizeof(crc2);
    fs.Read(crc2, sizeof(crc2));

  finally
    FreeAndNil(fs);
  end;

  if crc <> crc2 then Application.Terminate; // ...
end;

end.

Meine Frage dazu, wie könnte man das beschleunigen und wozu sind die CRC-Tabellen in Prüfalgor. ?

also c müste doch ein Byte sein.

und wenn du den gesammten fs vorher in einen TMemorystream kopierst und dann daraus arbeitest müste es schon deutlich schneller sein .

Ja, ist ja nur zusammengekloppt. Im Fall eines Falles könnte man auch noch einen extra Thread starten der das während des Programmablaufes
regelt.

Mir geht es nur darum das ich nicht verstehe was die "CRC-Leute" mit den Tabellengedöns machen...

"Nullpeilungssache das"

Die ist klar, dass das da oben kein CRC ist?

http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check

Zitat:

Durch Verwendung einer Tabelle, die etwa bei einer CRC-8 für jedes der 256 möglichen Bytes den zugehörigen CRC-Wert enthält, lässt sich obiger Algorithmus auf das Achtfache beschleunigen.

Das wird der Grund sein, dass die Typen Tabellen verwenden. Wenn man nicht nur für ein, sondern für 2 Bytes Tabellen erstellt dürfte das ganze nochmal etwas beschleunigt werden ...

Ja, ist ja eine Quersumme. Man kann aber auch damit feststellen ob eine Datei verändert wurde.

Bedenke bitte das sich bei mir bei den Begriffen Polynom ect. die Gehirnwindungen in Staub verflüchtigen...

Zitat von turboPASCAL:

Ja, ist ja eine Quersumme. Man kann aber auch damit feststellen ob eine Datei verändert wurde.

Bedenke bitte das sich bei mir bei den Begriffen Polynom ect. die Gehirnwindungen in Staub verflüchtigen...

Nicht nur bei dir

Manchmal ist es aber auch nur wichtig das es funktioniert, nicht aber wie

Zitat von turboPASCAL:

ich habe mal 'ne Ferage zum CRC einer Datei. Meises Wissens ist es ja recht einfach einen CRC bzw. besser gesage eine Checksumme einer
Datei zu erstellen. Das einfachste dürfte nun mal sein eine Quersumme der in der/ einer Datei enthaltenen Bytes zu erstellen.
Meine Frage dazu, wie könnte man das beschleunigen und wozu sind die CRC-Tabellen in Prüfalgor. ?

Hallo,

Quersumme und CRC sind völlig verschiedene Sachen. Quersumme muss man hoffentlich nicht noch erklären, bei CRC geht es darum, nicht irgendein Polynom zu wählen, sondern eines mit maximaler Periode, bei CRC16 also 65536. Es gibt nämlich unzählige Polynome, bei denen das nicht der Fall ist, die sich also in kürzeren Abständen wiederholen, um den entsprechenden Faktor ist dann die Sicherheit geringer. Es ist also längst nicht jedes Polynom bzw. die entsprechende Rückkopplung geeignet. Ob Mehrfach-Fehler erkannt werden, ist auch ein Gesichtspunkt.

Das ist also mathematisch abgesichert und alles andere als "Gedöns" - die Leute, die sich das ausgedacht haben, mögen ja inzwischen tot sein, aber das heisst noch lange nicht dass sie blöd waren.

Gruss Reinhard

Willst du mir sagen, dass bei CRC16 2^16 als Ding zum XORen benutzt wird und beim CRC8 eben 2^8?

Ich glaub das Ding mit dem XOR-t wird bezeichnet man als Polynom y?

Also ich finde, der Pseudocode hier veranschaulicht das Verfahren schon ganz gut:

markieren

Code:

Schieberegister := 0000... (Startwert)
solange Bits im String verbleiben:
  falls das am weitesten links stehende Bit vom Schieberegister
        ungleich zum nächsten Bit aus dem String ist:
    Schieberegister := (Schieberegister linksschieben um 1, rechtes Bit 0)
                       xor CRC-Polynom
                 
  andernfalls:
    Schieberegister := Schieberegister linksschieben um 1, rechtes Bit 0
  nächstes Bit im String
Schieberegister enthält das Ergebnis

"Schieberegister" ist halt der Speicher in dem das ganze stattfindet.

Und mit den Tabellen in denen das ganze Zeug beretis abgespeichert ist, erspart man sich halt das "linksschieben um 1" weil das auf modernen CPUs so schlecht möglich ist (wenn die Datenmengen größer werden)
Mit den Tabellen kann man eben immer um 8 verschieben (also immer 1 Byte)

Ah, jetzt ja.... danke.