RcX die Hundertste

[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")

[p80286]

Zitat von 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.

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 von 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.

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.




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.

[Jo78]

Vielen Dank für eure Antworten.
Also wenn ich stur alle Strings zu AnsiStrings umschreibe läuft es trotzdem nicht sauber. Sprich teilweise funktioniert es, ändere ich den text etwas funktioniert es nicht mehr. Genau das was ich eben mit unsauber meinte.

Zudem haut mir der Compiler mehrfach diese nette Meldung um die Ohren:

Code:

[DCC Warnung] mcry.pas(74): W1058 Implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString'

Ich will mal ganz ehrlich sein: Irgendwie finde ich die ganze Methode mit diesen nicht darstellbaren Sonderzeichen unsauber.

himitsu, dein Vorschlag byteweise zu verschlüsseln hört sich gut an. Nur leider kann ich damit überhaupt nichts anfangen, sprich ich weiß nicht mal im Ansatz wie ich das umsetzen kann.

Was ich nicht verstehe ist warum hier nicht mehr Leute an Verschlüsselung interessiert sind. Es wird doch sichere mehrere Leuten geben die Sachen für ihr Programm extern abspeichern müssen und den ganzen Kram nicht jedem präsentieren möchten.

Edith sagt: Vielleicht sind meine Listboxen auch der falsche Ansatz? Nicht das die guten Boxen den Code weil er zu lang ist zerhackstückeln? Wüsste allerdings nicht welche Komponente ich dafür sonst nehmen sollte.


Vielen Dank,
Gruß
Joachim

[DeddyH]

Ich habe gerade noch ein älteren Thread zum Thema gefunden: http://www.delphipraxis.net/124699-r...r-delphi7.html

[Jo78]

Hallo,
vielen Dank nochmal für den Link. Habe dort den letzten Post befolgt.

Im Prinzip funktioniert es. Das Problem ist, teilweise verschluckt er sich ab einer gewissen Länge. Damit ihr nicht länger rumrätseln müsst was ich falsch gemacht habe, findet ihr die beiden pas Dateien anhängend.

Es wäre wirklich nett, wenn sich jemand den Kauderwelsch mal anschauen könnte

Zur Erklärung: In der oberen Listbox2 soll der Text in Klartext stehen, in Listbox3 verschlüsselt. Im Memofeld kann ich den Text bearbeiten.

Reihenfolge: Entschlüsseln (Button1) -> in Memobox laden (listbox2.onclick) -> bearbeiten (button3) -> verschlüsseln (button2) -> speichern(button4).

Anwendungsbeispiel (Eingabe):

Code:

123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789

Vielen Dank,
Gruß
Joachim

[p80286]

Für die Warnung ist folgendes verantwortlich:

Delphi-Quellcode:

   for I := 0 to ListBox3.Items.Count -1 do
      ListBox2.Items.Add(RCxencode(R, listBox3.Items[I]));

Insbesonders wenn Windows seine Finger im Spiel hat, kann es tödlich sein, visuelle Komponenten für die Textspeicherung zu nutzen.
Wenn Du schon mit listboxen arbeiten willst, dann mach es doch wenigstens so:

Delphi-Quellcode:

var
  myinstring : ansistring;
  myencryptedstring : ansistring;
  
  mydecryptedstring : ansistring;

 for I := 0 to ListBox3.Items.Count -1 do begin
   myinstring:=ListBox3.Items[i];
   myencryptedstring:=RCxencode(R, myinstring);
   ListBox2.Items.Add(myencryptedstring);
   mydecryptedstring:=RCxdecode(R, myencryptedstring);
 end;

Dann gibt es zwar immer noch die Warnung, aber Du kannst die notwendigen Daten wenigstens laufend überprüfen.

Und überprüfe einmal den Inhalt von myinstring und mydecryptedstring wenn beide einen unterschiedlichen Inhalt haben, dann ist ein Wurm in deiner Ver-/Entschlüsselung.

Gruß
K-H

[Jo78]

Hallo nochmal,
vielen vielen Dank für deine hilfreiche Antwort.

Ich habe mir das geschriebene zu Herzen genommen und arbeite nun komplett ohne visuelle Komponenten. Alles wird in AnsiStrings verarbeitet und dann direkt in die Textdatei geschrieben.

Die Überprüfung ob Eingabewert und Verschlüsselung übereinstimmen habe ich ebenfalls eingebaut. Ergebnis: Übereinstimmung Demnach muss das Verschlüsseln an sich jetzt korrekt sein.

Das Problem liegt möglicherweise im Speichern (und späteren Laden) in normale Textdateien. Wenn ich die Datei lade entschlüsselt er nicht richtig sondern nur einen Teil. Schaue ich mir die Verschlüsselung in der Textdatei an sind da neben nicht darstellbaren Sonderzeichen auch Leerzeichen.

Prozedur zum verschlüsseln & testen:

Code:

procedure TCry.btmakeClick(Sender: TObject);
var vergleich,fertig,textzeile: ansistring;
var R: TRCxContext; Datei: TextFile;
begin
Trim(textzeile);
try
    RCxInit(R, 'k9N7ZgV7aX');
      fertig:=(RCxdecode(R, textzeile));
  finally
    RCxDone(R);
     end;
AssignFile(Datei, 'sec.ini');
Rewrite(Datei);
if IOResult = 0 then
 begin
 writeln(Datei,fertig);
 closeFile(Datei);
   end;
// nur zum pruefen
   try
    RCxInit(R, 'k9N7ZgV7aX');
      vergleich:=(RCxencode(R, fertig));
  finally
    RCxDone(R);
     end;
if vergleich = textzeile then showmessage('Identisch');
  end;

Meine Prozedur zum Öffnen und Entschlüsseln:

Code:

procedure TForm1.laden;
var ergebnis,geladen:AnsiString; R: TRCxContext; Datei: TextFile;
begin
AssignFile(Datei, 'sec.ini');
Reset(Datei);
ReadLn(Datei,geladen);
CloseFile(Datei);
  try
    RCxInit(R, 'k9N7ZgV7aX');
      ergebnis:=RCxencode(R,geladen);
  finally
    RCxDone(R);
  end;
AssignFile(Datei, 'sec2.ini');
ReWrite(Datei);
WriteLn(Datei,ergebnis);
CloseFile(Datei);
end;

Findet dort jemand einen Fehler oder hat sonst eine Idee woran es liegen könnte? Da die Übereinstimmungsprüfung positiv ausfällt kann es ja "nur" am falschen Speichern oder Laden liegen?
Für die Hilfe welche mir bisher zu Gute gekommen ist nochmal herzlichen Dank an alle Beteiligten

Vielen Dank natürlich auch für weitere Hilfe!

Gruß
Joachim