RcX die Hundertste

[Jo78]

Hallo zusammen,
also ich muss zugeben ich schäme mich schon fast dieses Thema jetzt eröffnen zu müssen :oops:

Ich versuche seit mehreren Tagen eine RcX Verschlüsselung und Entschlüsselung hinzubekommen. Dazu nutze ich folgende Unit (vielen Dank an den Verfasser): http://www.delphipraxis.net/301240-post3.html

Ich möchte aus einer Textdatei mit der Endung.ini verschlüsselten Text in eine Listbox laden (listbox3) und diese dann in die Listbox2 entschlüsseln. In der Textdatei sind Zahlen die mittels | als Seperator getrennt sind.

Mein Problem ist, es funktioniert zwar grundsätzlich, aber nicht zuverlässig. Ich habe das Gefühl nicht sauber zu arbeiten und dadurch bei kleinen Abweichungen sofort keine gültige Verschlüsselung mehr zu haben.

Hier meine Prozedur:

Code:

procedure TForm1.encode;
var
  I: Integer;
  R: TRCxContext;
begin
listbox3.Items.LoadFromFile('sec.ini');
  ListBox3.Items.BeginUpdate;
  try
    RCxInit(R, 'pass1234');
    ListBox2.Items.Clear;
    for I := 0 to ListBox3.Items.Count -1 do
      ListBox2.Items.Add(RCxencode(R, listBox3.Items[I]));
  finally
    ListBox3.Items.EndUpdate;
    RCxDone(R);
  end;
end;

Zum Decoden das gleiche in grün mit RCxdecode.

1) Ist das grundsätzlich in Ordnung? Ich denke mal nicht :(

Zusätzlich habe ich auch das beschriebene Problem: http://www.delphipraxis.net/301240-post3.html

Allerdings kann ich mit der TStream Lösung nichts anfangen, da ich ja eben nicht die verschlüsselte Datei entschlüsselt speichern möchte, sondern nur temporär für das laufende Programm entschlüsseln.


2) Bei der Unit von Hagen wird GetTickCount reklamiert wenn ich nicht Zusatzangaben im uses Bereich mache, ist korrekt?

Ich mache Delphi nur Hobbymäßig und komm normalerweise mit meinen Sachen und über die Suche gut zurecht. Aber das ist für mich wohl noch ein Level zu hoch. Demnach würde ich mich wirklich freuen, wenn ihr mir weiterhelfen könntet.


Vielen Dank,
Gruß
Joachim

[p80286]

Wenn ich nichts übersehen habe, dann arbeitet die von Dir genutzte Unit mit 8BitChar, wenn Dein Delphi mit 16BitChar arbeitet, hast Du erst einmal ein Problem.
Und ein verschlüsselter String kann auch Zeichen enthalten, die nicht Darstelbar sind, da könnte es auch einmal krachen.
Was ist denn wenn Du einen zu verschlüsselden und einen verschlüsselten und einen entschlüsselten String nutzt?

Gruß
K-H

[Jo78]

Hallo,
vielen Dank für deine schnelle Antwort.

Ich darf durch Vitamn B Delphi XE mitnutzen. Ist die Unit dann ohne weiteres nicht kompatibel?

Deinen Vorschlag habe ich bisher noch nicht getestet und wüsste auch nicht wie ich den in der oben genannten Prozedur verwirklichen könnte.

Irgendwie dachte ich es würde zuverlässige Methoden geben das ganze sauber und ausfallsicher zu gestalten...

Vielen Dank,
Gruß
Joachim

[DeddyH]

Wie sieht es aus, wenn Du alle Strings explizit als AnsiStrings deklarierst (sowohl in der RcX-Unit als auch bei den übergebenen Argumenten)?

[Luckie]

Was p80286 sagen wollte: Die Unit wurde für und mit einem Delphi geschrieben, bei dem der Datentyp String noch ein AnsiString war. Bei dem Delphi, was du nutzt ist der Datentyp String aber ein WideString. Und somit passen die Unit und dein Delphi nicht zusammen.

Aber warum wollt ihr alles jetzt wieder auf AnsiString runterbrechen? Jahre lang wurde sich beschwert, dass Delphi kein Unicode unterstützt und jetzt tut es das und anstatt alten Code Unicode fähig zu machen, kommt hier immer der Vorschlag alles doch wieder auf AnsiStrings umzustellen. Das verstehe ich einfach nicht.

[DeddyH]

Vielleicht kam der Vorschlag, um zu ermitteln, ob es wirklich ausschließlich ein Ansi-/Unicode-Problem ist oder evtl. noch andere Dinge da hineinspielen könnten?

[Luckie]

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

[DeddyH]

Dann pass den Code doch an, ich habe das gerade "mal eben" versucht und bin geguttenbergt2 ("Vorerst gescheitert") :mrgreen:

[p80286]

Zitat:

Zitat von Luckie (Beitrag 1142531)

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

Nach meinem Dafürhalten, ist dies der richtige Weg, wenn man eine alte Unit outofthebox nutzt.
Für den zukünftigen Einsatz spricht nichts dagegen solche units mit den entsprechenden 16Bittern aufzurüsten.
Ich persönlich bevorzuge in solchen Fällen die Übergabe durch array of Byte, array of word etc.

Gruß
K-H

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1142531)

Der zweite Absatz bezog sich jetzt nicht speziell auf dieses Problem. Aber immer wieder wenn eine Ansi/Unicode Inkompatibilität auftaucht0, wird dazu geraten aus den Strings AnsiStrings zu machen, anstatt den Code entsprechend an Unicode anzupaasen. Der einzige, der das nicht macht ist himitsu.

Wobei es hier ein klitzekleines Problem gibt.

Da hier ein "String" binär verändert wird und man keinerlei gemeinsamkeiten zwische ANSI und Unicode herstellen kann, muß man sich auf ein Format einigen.

> Char/String war hier also schon immer ein Fehler.

* Entweder man macht alles mit ANSI (AnsiString)

* oder man macht alles mit Unicode (UnicodeString, bzw. WideString in älteren Delphis oder immer das delphifremde WideString)

* oder man lebt damit, daß die Ergebnisse nicht zwischen ANSI- und Unicode-kompilierten EXEn kompatibel sind
(abgesehn davon, daß RCx nunmal nicht "direkt" auf CHARs angewendet werden kann *1, da hinterher keine "korrekten" CHAR-Werte rauskommen, entsprechend dem zugrundeliegenden Encoding)

* oder man geht einen Kompromis ein und nimmt z.B. UTF-8

= in den jeweiligen Zielsystemen kann man die Texte/Variablen/Parameter ja entsprechend konvertieren, wie es einem beliebt.



- ANSI-Speicherung/Verschlüsselung > hier könnte es sein, daß nicht alles vom UNICODe gespeichert werden kann, aber Laden ist immer möglich

- Unicode (UTF-8 = Unicode) > hier kann es Probleme beim Laden geben, wenn es nach ANSI konvertriert wird, aber speichern ist immer möglich





Und nun zu diesem speziellen Problem:
Nicht die CHARs verschlüsseln, sondern die Bytes.

Die Datei also z.B. in einen Stream laden und dann byteweise verschlüsseln.
Ob die Datei nun Unicode oder ANSI ist ist dabei vollkommen egal ... Byte ist Byte. :angle:




1) Dass "früher" RCx direkt auf AnsiChar losgelassen wurde, war ein Fehler und entstand dadurch, daß "zufällig" SizeOf(AnsiChar) = SizeOf(Byte).
Da sich das Char aber angepaßt hat und jetzt ein WideChar ist, ergibt sie dieses Problem des SizeOf(WideChar) <> SizeOf(Byte), da RCx nunmal als byteweise Kodierung entwickelt wurde und am Ende auch noch "unberechenbare" Bytes rauskommen können, welche eine TEXT-weise Verrbeitung unmöglich macht.