Wolfgang Ehrhardts CRC/Hash Routinen - kompilieren schlägt fehl - IDE-Bug?

[a.def]

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

[gammatester]

Zitat von a.def:

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

Für Tokyo solltest Du die neueste http://www.wolfgang-ehrhardt.de/std.zip verwenden. Deine ist über ein Jahr alt, da gab es Tokyo noch nicht.

PS: Warum hast du eigentlich so viele Änderungen am Code vorgenommen (zB 124 bei sha256)?

[a.def]

Ich weiß nicht genau von welchen Änderungen du sprichst. Bis auf die Code-Formatierung habe ich nichts ausgeführt.
Irgendetwas mache ich trotzdem noch falsch. Selbst mit der neuen std bekomme ich falsche Ergebnisse.

[gammatester]

Ein letzter Versuch: Wenn Deine Funktion immernoch etwa so aussieht

Delphi-Quellcode:

function SHA1Text(const s: string): string;
var
 Context: THashContext;
 SHA256Digest: Hash.TSHA256Digest;
begin
 SHA256.SHA256Init(Context);
 SHA256.SHA256Update(Context, pChar(s), length(s));
 SHA256.SHA256Final(Context, SHA256Digest);
 Result := Mem_Util.HexStr(@SHA256Digest, SizeOf(SHA256Digest));
end;

hast Du wahrscheinlich ein Problem mit Unicodestrings wegen des pChar(s). Da char 16 Bit ist, müßtest Du auf jeden Fall length(s)*sizeof(char) verwenden. Doch ich bezweifele, daß Du überhaupt die vielen 0-Bytes eines Unicodestring haschen willst. Warum verwendest Du immer noch die dämlichen unangemessenen Strings? Gehascht werden sollte über Byte/Bit-Folgen, wie man es Dir in Deinem anderen Thread bereits nahegelegt hat.

Gute Nacht
Gammatester

[a.def]

Zitat:

Warum verwendest Du immer noch die dämlichen unangemessenen Strings? Gehascht werden sollte über Byte/Bit-Folgen, wie man es Dir in Deinem anderen Thread bereits nahegelegt hat.

Weil

a) ich weiß nicht wie (unkomplizierte Lösung)
b) habe ich den Code da oben bei StackOverflow gefunden
und
c) wenn ich den Hash anzeigen möchte, dann geht das halt nur über Strings.


Ist jetzt aber auch egal das Thema hat sich für mich erledigt.

[gammatester]

Zitat von a.def:

b) habe ich den Code da oben bei StackOverflow gefunden
und
c) wenn ich den Hash anzeigen möchte, dann geht das halt nur über Strings.

Allerletzter Kommentar:

Es geht ja nicht um die Ausgabe sondern die Eingabe. Der Code wäre halbwegs richtig für Delphi < 12, also prä- D2009 (allgemein, wenn string ein ansistring ist). Wenn Du keine abstrusen Zeichen benutzt, versuche also die Deklaration

function SHA1Text(const s: ansistring): ansistring;

[himitsu]

[edit]
Ich seh grade, dass sich dieses Thema eh endgültig "erledigt" hat.

Na gut, alles Wichtige wurde ja gesagt,
also Punkt und Ende.
[/edit]


function SHA1Text(const s: ansistring): ansistring; wäre in so weit richtig, wenn der Code die selben Ergebnisse liefern soll, wie vor Delphi 2009.
Das Result wäre natürlich egal, da Hexadezimal als ASCII überall gleich aussieht, also wäre IMHO String dafür ganz passend.

So wäre der Code halbwegs kompatibel zu Hashs, die vor D2009 generiert wurden.




Allerdings ist AnsiString als Eingang auch nicht sonderlich optimal, da es bei Nicht-ASCII-Inputs je nach CodePage (Systemstpache) unterschiedliche Ergebnisse liefern kann wird.

Fazit: Entweder man legt fest, dass eine bestimmte CodePage als Eingang vorgeschrieben ist, z.B. Latin1.

Delphi-Quellcode:

type
  Latin1 = type AnsiString(1252);  // ISO 8859-1

function SHA1Text(const S: Latin1): String;

Oder man legt es besser noch auf einen Unicode-Zeichensatz fest, wie z.B. Unicode (UnicodeString, bzw. auch WideString für vor Delphi 2009) oder besser UTF8String.
function SHA1Text(const S: UTF8String): String; (seit Delphi 2009 kümmert sich Windows automatisch um eine Konvertierung, wenn man da einen String oder AnsiString rein gibt.

Nur so ist gewährleistet, dass Hashs immer und überall gleich sind.
Blos zu Hashs der alten ANSI-Version ist es nicht kompatibel.