Ich finde, du gehst das Problem da falsch an, und die Wahl von RawByteString ist da ganz wesentlicher Bestandteil der Ursache. RawByteString übernimmt die Zeichen byteweise wie sie sind. Gibt man einen AnsiString rein, wird er so übernommen. Nimmt man einen UTF8string, kommt auch dieser unbehandelt zum Einsatz. Damit macht sich die Implementierung vom tatsächlichen Encoding des RawByteString (und das gibt es!) abhängig.
Problematisch wird es halt bei den Zeichen > $7f, denn darunter sind beide Codierungen gleich. Mit Passwörtern im
ASCII-Bereich wird man keine Probleme feststellen. Verwendet man aber z.B. Umlaute wird man Unterschiede unter Windows mit einer JAVA-Referenz auf Linux feststellen (übrigens auch mit JAVA auf Windows).
Um das Problem diverser interner String-Codierungen plattformübergreifend zu lösen, muss man sich auf ein Encoding einigen. Herausgekommen ist dabei UTF8, wie man aus einer simplen JAVA-Implementation herauslesen kann:
Code:
passwordb = (password + (minor >= 'a' ? "\000" : "")).getBytes("UTF-8");
Wobei hier
passwordb als Bytearray deklariert ist.
Die straight forward Übersetzung in Delphi wäre somit die Verwendung von
TBytes für die internen Berechnungen und die Umwandlung des String-Password mittels
TEncoding.UTF8.GetBytes.
OT: Ich habe nie verstanden, warum bei Hash, Crypt und sonstigen Rechnungen mit Strings, seien es
Ansi oder RawByte, gearbeitet wird. Das ist doch geradezu eine Einladung für fehlerhafte Verwendung.
Zitat
Baum-Darstellung
