Unnamed-Projekt > BigInt, MD5, RipeMD320, SHA, Streams usw.

[Bbommel]

Hier die Auflösung, vor allem, falls später noch mal jemand drüber stolpert. Das Verhalten der alten fhash-Unit kann man nachstellen, indem man an die neue Funktion aus der system.hash nicht direkt den String übergibt, sondern ihn sozusagen als Byte-Folge mitgibt. Hier ein Beispielprogramm, in welchem der Aufruf der "alten" FHash-Funktion und der bei Delphi jetzt mitgelieferten das selbe Ergebnis liefern:

Delphi-Quellcode:

uses
  System.SysUtils,
  FHash_single,
  System.Hash;

var md5: ThxMD5;
    md5system: THashMD5;
    md5_Fhash: string;
    md5_system: string;
    inStr: String;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    inStr:=ParamStr(1);
    md5.Init;
    md5.Update(inStr);
    md5.Final;
    md5_Fhash:=md5.asHexString;

    md5system.Reset;
    md5system.Update(inStr[1],Length(inStr)*2);
    md5_system:=md5system.HashAsString;

    writeln('md5 Fhash_single: '+md5_Fhash);
    writeln('md5 System      : '+md5_system);
    writeln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Während die Funktion aus Fhash (hier: fhash_single) immer mit zwei Bytes pro Buchstabe arbeitet, so scheint es mir bei dem richtigen Hash so zu sein, dass zumindest die abschließenden 0-Bytes abgeschnitten werden. Wenn man nun also die neue Funktion zwingt, auch immer zwei Bytes zu nehmen, dann funktioniert es.

Danke für eure Anregungen!

Bis denn
Bommel

[himitsu]

Das ist aber kein Fehlverhalten der Hashfunktion.

Ich selber wandle Strings inzwischen grundsätzlich immer nach UTF-8 und hashe diesen String dann, somit ist überall das Ergebnis gleich.
Ob man nun ANSI (Eine der vielen CodePages), UTF-8 oder Unicode (UTF-16) hasht, vom Ergebnis muß das andere Werte liefern, sonst ist die Hashfunktion ja kaputt, wenn sie bei unterschiedlichen Byte-Folgen gleiche Ergebnisse liefert.

In deinem Fall, also als Unicode (UTF-16) und dann hashen, egal mit welcher Funktion, und alles kann so bleiben
oder ein anderer "Daten"-Format und dann ist es auch egal welche Hashfunktion du nutzt.

[Bbommel]

Jo, ich hatte in meinem ersten Post "richtig" und "falsch" bewusst noch in Anführungszeichen gesetzt, weil mir schon klar war, dass es nicht wirklich richtig oder falsch ist, sondern darum geht, wie welche Bytes umgewandelt bzw. interpretiert werden. Das mit den Anführungszeichen war mir nachher nur zu lästig.

Ich kam darauf, das eine Ergebnis als "richtig" zu bezeichnen, weil halt die Funktion von Indy, System.hash und PHP (bei einem Online-Tool ausprobiert) dieses Ergebnis lieferte ohne, dass man bewusst irgendwelche Umwandlungen einstellen musste. Am Anfang hatte ich auch einfach nur den Buchstaben "a" als Eingabe für die Funktionen genommen.

Nun habe ich ja für meine existierenden Daten eine Lösung gefunden und für die Zukunft finde ich das Umwandeln in UTF8 eine gute Idee - dann sollte es plattform- und sprachübergreifend ja den gleichen Hash geben.

[himitsu]

PHP und z.B. FreePascal/Lazarus arbeiten an den meisten Stellen mit UTF-8 und müssen bei Systemaufrufen konvertieren. Delphi seit 2009 vorallem mit UTF-16, womit bei WinAPIs oft weiterhin ein PChar-Cast reicht.
Nja, und ich, unerfahren, wie ich war, hatte damals, bei der 2009-Anpassung, die ANSI-Versionen so gelassen, wie sie waren, damit sie gleiche Ergebnisse liefern,
aber die WideString-Versionen als Unicode gehasht, so wie sie rein kommen.