Decrypten von Daten in TStringList fehlerhaft

[Kytrix]

Ich nutze XE2 wie behebe ich den jetzt das problem ? ich weiß nicht wo ich ansetzen soll

[Sir Rufo]

Stell dir vor, du bist ein Zauberer, der Äpfel (Strings) in ein rohes heiles Ei verwandeln (encrypten) und auch wieder zurück in einen Apfel verwandeln (decrypten) kann.
Deine Assistentin kann mit verbundenen Augen Äpfel fangen.
Du verwandelst jetzt einen Apfel in ein Ei und wirfst es der Assistentin zu.
Die erwartet aber einen Apfel und was kann passieren?
Jo, das Ei könnte kaputt gehen, und die Rückverwandlung klappt nicht mehr.

Genau das passiert mit deinem verschlüsslten String. Nach der Verschlüsselung ist das kein String mehr und darf infolge dessen auch nicht mehr als solcher behandelt werden (was du aber machst) ;)

[jfheins]

Zitat:

Zitat von Kytrix (Beitrag 1179901)

Ich nutze XE2 wie behebe ich den jetzt das problem ? ich weiß nicht wo ich ansetzen soll

Ich praktiziere jetzt mal "Hilfe zur Selbsthilfe" :wink:
Wie in Beitrag #10 gesagt, empfiehlt sich ein Filestream. Damit kannst du "Binärdaten" (also auch nicht druckbare Zeichen und so) problemlos verarbeiten.
Gundzüge sehen ungefähr so aus:

Delphi-Quellcode:

str := Encrypt(...);
fs := TFilestream.Create(...);
try
  fs.WriteBuffer(Length(str));
  fs.WriteBuffer(str[1]);
finally
  fs.free();
end;

Konkrete Codebeispiele kannst du sicher über eine Suchmaschine finden.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1179903)

Stell dir vor, du bist ein Zauberer, der Äpfel (Strings) in ein rohes heiles Ei verwandeln (encrypten) und auch wieder zurück in einen Apfel verwandeln (decrypten) kann.
Deine Assistentin kann mit verbundenen Augen Äpfel fangen.
Du verwandelst jetzt einen Apfel in ein Ei und wirfst es der Assistentin zu.
Die erwartet aber einen Apfel und was kann passieren?
Jo, das Ei könnte kaputt gehen, und die Rückverwandlung klappt nicht mehr.

Vermutlich entsteht Apfelmus.

Sehr schöne Analogie :thumb:

[p80286]

Das Apfelmus passt inhaltlich ja besser, trotzdem :thumb::thumb::thumb:

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von jfheins (Beitrag 1179908)

Delphi-Quellcode:

str := Encrypt(...);

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

[jfheins]

Zitat:

Zitat von Sir Rufo (Beitrag 1179913)

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

Soll ja auch nur ungefähr sein :mrgreen:
Andererseits eigenen sich in Delphi Strings zur Aufnahme binärer Daten und seine Funktion gibt ja bereits eine String zurück. Müsste also schon gehen... oder?

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1179913)

Zitat:

Zitat von jfheins (Beitrag 1179908)

Delphi-Quellcode:

str := Encrypt(...);

Irgendwie sieht das wieder falsch aus, denn man könnte bei der Variable str vermuten, dass diese als string deklariert ist, und das ist nach dem Encrypten eben nicht mehr zutreffend.

Ein Delphi-String ist durchaus in der Lage, nicht-druckbare Zeichen, wie CR, LF oder #0 korrekt zu speichern. Macht man daraus aber durch Zuweisung oder Cast einen PChar, dann wird beim ersten #0 abgeschnitten.

[p80286]

Da hast Du natürlich recht, aber
seitdem das Windows-API an sehr vielen Stellen, auch unbeabsichtig mitspielt, ist diese Benutzung mit Vorsicht zu genießen.
es gibt hier im Forum viele Posts, die darauf schließen lassen, daß ein String ein irgendwie magischer Datenspeicher ist, der alle in ihm enthaltene Daten auf magische Weise sinnvoll darstellen kann;
Und irgendwie ist dies nicht auszurotten.
Selbst für gestandene Delphianer ist dies ein Thema, was nicht ohne Tücken ist. ((Unicode)-Char)
(und da muß dann ein x0000 als Begrenzer herhalten.)

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1179918)

Da hast Du natürlich recht, aber
seitdem das Windows-API an sehr vielen Stellen, auch unbeabsichtig mitspielt, ist diese Benutzung mit Vorsicht zu genießen.

Ich wollte damit auch nicht die Verwendung rechtfertigen, sondern nur aufzeigen, warum es in manchen Situationen scheinbar funktioniert. Ein String als Datentyp für einen Binärwert ist natürlich Unsinn, aber gegen einen harten Cast auf PChar, damit der API-Aufruf kompiliert, ist auch der korrekte Typ machtlos.