versuche mal
Delphi-Quellcode:
function TfrmManager.EnCode(key, text: string): string;
begin
with TCipher_Rijndael.Create do
try
Mode := cmCBCx;
Init(THash_SHA1.KDFx(key, RandomBinary(16), Context.KeySize));
Result := EncodeBinary(text, TFormat_MIME64); // <------
finally
Free;
end;
end;
in .Decode() dann das gleiche.
Das Problem ist nämlich das der Datentyp "Binary" im Grunde ein simpler LongString ist. TStringList arbeitet intern aber mit PChar. Dh. ein LongString der ein Zeichen #0 -> Null-Terminator -> mitten drinnen enthält wird an dieser Stelle durch TStringList abgeschnitten. Man kann also in einem LongString binäre Daten speichern muß aber höllisch aufpassen das man diesen String nicht als normalen String betrachtet und eben nicht zb. einer TStringList zuweist. Bei deiner Zuweisung TStringList.Text := Encode(); gehen also Daten verloren da die
RTL/
VCL/TStringList das abschneidet wenn in den Daten ein #0 Zeichen vorkommt. Desweiteren konvertiert die TStringList -> TStringList.Text := XYZ, Methode auch die Zeichen #10 und #13 -> Line Feed und Carrige Return implizit. Aus dem binärem Datenstring werden also die Zeichen durch die TStringList entfernt (besonders wenn sie doppelt vorkommen) und stattdessen der String gesplittet in TStringList.Strings[0] .. TStringList.Strings[1] ... TStringList.Strings[x] abgespeichert. Wenn man nun mit XYZ := TStringList.Text diesen String wieder abfragt baut TStringList wieder #10#13 Zeichen in das Resulat rein. Diese stimmen dann aber nicht mehr mit dem Original Binärem Wert überein. Du hast also über TStringList den binären Wert ohne das du es merkst verändert. Das ein solch veränderter Wert nun nicht mehr den originalen entschlüsselten Text ergeben kann ist jetzt wohl logisch, oder ?
Übrigens, unter den 1000'enden EMail-Support-Anfragen die ich bekommen habe ist es dieser Fehler der in 90% aller Fälle gemacht wurde. Also ein typischer Anfängerfehler
[edit]
Ich habe sogar schon zwei EMail-Templates (in deutsch und englisch) angelegt um mir die Arbeit bei solchen Supportanfragen zu vereinfachen
[/edit]
Um das zu verhindern benutzt du statt dem binärem Datenformat eine Konvertierung in ein lesbares stringkompatibles Datenformat. Wie oben eben das Indernett MIME Base 64 Format.
Normalerweise macht es aber auch keinen Sinn, so wie du es machst, einer TStringList einen Binären Wert zuweisen zu wollen. Das was du da machst ist im Grunde also "unclever" (vorsichtig ausgedrückt).
Zum Glück machen alle
DEC Funktionen diese Konvertierungen inklusive, du musst es ihnen nur sagen. Statt MIME64 könntest du auch mal TFormat_HEX oder TFormat_ESCAPE versuchen.
Gruß Hagen
PS: um auf dieses Verhalten hinzuweisen habe ich im
DEC 5.1 eben den Datentype "Binary" eingeführt. Denn wenn man dieses Verhalten kennt ist der "Mißbrauch" eines LongStrings/Strings als boinärer Datenkontainer im Grunde eine gute Wahl. Ich hätte auch einen eigenen dynamischen Datentyp -> array of Byte -> benutzen können. Dieser wäre dann aber eben nicht mehr kompatibel zu LongStrings gewesen und konzeptionell die Schnittstellen im
DEC unnötig verkompliziert. Es ist also eine Kompromiß-Entscheidung meinerseits gewesen das so und nicht anders zu machen