MD5 - Unterschiede zw. Indy und DEC6

[EdAdvokat]

ich habe "Testwert" (natürlich ohne ") in das DEC-Hash eingegeben und erhalte das beigefügte Ergebnis genau wie mit Indy.
Ich habe für das Programm DEC Hash Vcl DEC 6.41 (also das aktuelle DEC) verwendet.

[TurboMagic]

Hallo,

schön, dass ihr das schon alleine rausbekommen habt.
Danke an SGlienke!

Nach dem halt UnicodeString in DelphiUTF16 ist, würde ich so ein
Verhalten auch ehrlicherweise erwarten.

Warum?

1. Weil es wie von Stefan richtig bemerkt ja extra eine RawByteString
Variante davon gibt die man in den anderen Fällen nutzen kann.

2. Man sonst bei wirklicher Ausnutzung eines UnicodeString/string
mit Zeichen > 255 Schwierigkeiten hätte. Dann bräuchte man gar keine
Variante mit UnicodeString/string anzubieten.

Grüße
TurboMagic

[dschiffler]

Hallo,

danke an Stefan für den Hinweis zu UTF8.

Allerdings kann ich bei Indy nichts am Aufruf von HashStringAsHex ändern, da die Klasse TIdHashMessageDigest5 intern in TIdDigestAuthentication verwendet wird.

Frage an TurboMagic:
Die Hash-Methode von Delphi (System.Hash.THashMD5.GetHashString) kann ich ganz normal mit einem String aufrufen, da dort intern eine Umwandlung des Parameters erfolgt (TEncoding.UTF8.GetBytes(...)).
Wäre das nicht auch bei den DEC-Funktionen sinnvoll, damit man die Umwandlung mit UTF8String nicht immer selber machen muss?

[himitsu]

Du kannst die String-Variable auch einfach als

Delphi-Quellcode:

UTF8String

deklarieren, anstatt als

Delphi-Quellcode:

string

.

[TurboMagic]

Hallo,

ich bin mir noch nicht sicher ob ich Himitsu richtig verstehe.
Wenn man einen normalen String mit den DEC string Funktionen benutzt ist der ja
UTF16 in Delphi. Weißt man einen UTF8String einem String zu dürfte der ja in UTF16
konvertiert werden, oder?

Dann käme ja nicht das richtige raus.
Wenn man die DEC erweitern möchte (weil es zu müßig ist RawByteString Typecasts
hinzuschreiben, dann müsste man wohl noch UTF8String basierte Overloads hinzufügen.

Oder was hab' ich jetzt falsch verstanden? :?

Falls wir uns einig werden was der richtige Ansatz ist bin ich auch für Codespenden dankbar ;-)

Grüße
TurboMagic

[himitsu]

Gäbe es bloß ein CalcString mit string, würde es stimmen.

Aber da es eine Überladung mit einem kompatiblen Typen zum UTF8String gibt, wird Jenes verwendet, also RawByteString.



Bei einer Überladung von String (bzw. UnicodeString/WideString) und AnsiString, da wird es schwieriger.
Vor 2009 wäre der UTF8String in jeden anderen AnsiString-Typen übergegangen, womöglich sogar ohne Konvertierung.
Jetzt wird es komplizierter. Ich würde hoffen es ginge da auf String/UnicodeString, aber es wäre auch möglich, dass es mit Konvertierung in den AnsiString ginge (was blöd wäre).

[DieDolly]

Ich habe noch eine etwas ältere Version von DEC (Version 6.2 laut readme).

Delphi-Quellcode:

function TDECHash.CalcString(const Value: RawByteString; Format: TDECFormatClass): RawByteString;
var
 Buf: TBytes;
begin
 Result := '';
 if Length(Value) > 0 then
  {$IF CompilerVersion >= 24.0}
  Result := BytesToRawString(ValidFormat(Format).Encode(CalcBuffer(Value[low(Value)], Length(Value) * SizeOf(Value[low(Value)]))))
  {$ELSE}
  Result := BytesToRawString(ValidFormat(Format).Encode(CalcBuffer(Value[1], Length(Value) * SizeOf(Value[1]))))
  {$IFEND}
 else
  begin
   SetLength(Buf, 0);
   Result := BytesToRawString(ValidFormat(Format).Encode(CalcBuffer(Buf, 0)));
  end;
end;

Hier kommt der richtige MD5-Hash raus.

[TurboMagic]

Naja, in deinem Fall ist auch klar warum das richtige raus kommt:
Die benutzt RawByteString, also 8-Bit pro Zeichen.

Und wie ja schon ermittelt wurde kommt auch bei der aktuellen Version
das richtige raus, wenn man das richtige Overload aufruft.
=> also ggf. TypeCast

Grüße

TurboMagic

[Kas Ob.]

@TurboMagic

It will be nice if there a demo, a specific one to point and emphasize how strings being handled and how other library does it, eg. Indy or any popular PHP library .. etc

[himitsu]

Nja, eine gute Überladung von UTF8String mit String+RawByteString lässt sich leider nicht bilden, da es bei "anderen" AnsiString-Typen keinen wirklich sicheren Pfad ergibt,
außer man würde RawByteString und String/UnicodeString nehmen und intern immer nach UTF-8 konvertieren, was aber den Leuten die Möglichkeit nehmen würde, auch andere Konvertierungen zu nutzen.



Am Einfachsten wäre wohl eine Standardfunktion, mit Typ UTF8String (ohne Überladungen), da das vermutlich der häufigste/nützlichste Fall sein dürfte und Delphi alle übergebenen Stringtypen automatisch konvertieren würde,
und daneben eine andere überladene Funktion mit RawByteString, String/UnicodeString, TBytes und Pointer+Len, für alle anderen Fälle und Daten/Strings in allen möglichen Datenformaten, welche ohne automatische Konvertierung behandelt werden.

Alternativ eben nur die letzte überladene Parameter-Variante, mit einem zusätzlichen Parameter, welcher das interne Encoding vorgibt, in was vor der Hash-Berechnung konvertiert würde, also z.B. ein Enum oder TEncoding, mit Default auf UTF-8.
Alles in Richtung TBytes und oder Pointer (RawByteString als Kopie mit SetCodePage oder einfach an String/UnicodeString übergeben, sowie den UnicodeString mit TEncoding in ein TBytes und am Ende dann daraus der Hash)