Unicode + BASE64?

[Zacherl]

Welche Zeile genau?

[blackdrake]

Bei der Copy-Zeile. Ich glaube 2tes Argument.

[Zacherl]

Dann versuch mal nur @UnicodeStr oder UnicodeStr[0] .. keine Ahnung wie sich das genau verhält.

[Bernhard Geyer]

Zitat von blackdrake:

Mhh... so in etwa? Hier sagt er, es seien inkompatible Typen.

[delphi]function WideStringToString_Lossyless(UnicodeStr: WideString): string;

Vergiss diesen Versuch! Ein String ist ein String und ein WideString ist ein WideString! Falls du des doch hinbekommst wirst du bei jeder Funktion scheitern die als Stopper ein #$00 am Ende des Strings erwartet.

[blackdrake]

Wie soll ich denn sonst das Problem lösen? Ich muss den WideString ja irgendwie in einen String umwandeln, diesen dann ver- und entschlüsseln und diese Umwandlung danach wieder Rückgängig machen, ohne dass Informationen verloren gehen. Die Grundproblematik ist doch klar, oder? Das ich einen japanischen Text von WideString nicht nach String umwandeln kann, ohne dass dieser nur komische Zeichen enthält, ist mir klar.

Edit: Außerdem gilt #00 bei Strings bzw. #00#00 bei WideStrings ja nur speicherintern bzw bei Streams. Nach der Verschlüsselung hab ich ja nichts mehr dergleichen. Wenn ich einen String "test" habe, ist ja das #00 auch nur innerhalb des RAMs da und nicht im String selbst.

[phXql]

Wieso musst du den Widestring in einen String umwandeln? Das geht nicht, da gehen dir Zeichen verloren. Du musst den Widestring in ein Byte-Array umwandeln und dieses dann verschlüsseln.

Das geht doch bestimmt über irgendwelche Pointer-tricks mit CopyMem(). Aber da kenn ich mich nicht wirklich aus. Ich gehe Pointern aus dem Weg

[blackdrake]

Das meine ich ja, mit Byte-Array zwischenstufe. Der String soll aufgebläht sein, sodass eben keine Informationen verloren gehen. Ist unter Umständen das vorher genannte UTF-8 das, was ich suche?

Wie gesagt, die strings sollen nur als Übergang dienen, weil die Verschlüsselungsroutine nur strings annimmt. Sie sollen keinen Sinn ergeben.

CopyMem() gibt's als Funktion nicht. Und Copy() dient trotz seiner Bezeichnung nur zum Abschneiden von Strings.

[phXql]

Ist CopyMem nicht so n toller Win32-API-Call?

Dass die Verschlüsselungsroutine nur Strings annimmt, is schon ein bisschen doof, wenn man Unicode verarbeiten will. Kannste die nicht auf ein byte-Array umschreiben?

Ein WideChar ist ja 16 Bit, ein normaler Char nur 8 Bit. Wenn du nun von deinem Widechar jeweils die ersten 8 Bit (Hi) in den ersten Char und die letzten 8 Bit (Lo) in den nächsten char kopierst, dann hast du einen doppelt so langen String, aber ohne Verlust von Informationen. Diesen kannst du dann verschlüsseln. Aber ich weiss nicht, ob eventuelle #0 im String Delphi durcheinanderbringen (aber ich denke, Delphi verwaltet die Strings anders als C mit den null-terminierten Strings)...

[blackdrake]

Danke für den Hinweis.

Delphi hat keine Probleme mit Strings und #0. Man hat lediglich Probleme wenn man einen solchen String ausgeben möchte. Er wirkt wie abgeschnitten, was er aber nicht ist.

Folgendes Funktioniert nun:

Delphi-Quellcode:

function WideStringToString_Lossyless(UnicodeStr: WideString): string;
var
  ByteArray: Array of Char;
begin
  SetLength(ByteArray, Length(UnicodeStr));
  CopyMemory(@ByteArray[0], @UnicodeStr[1], Length(UnicodeStr));
  result := string(ByteArray);
end;

Jetzt bin ich nur noch am rumprobieren mit der Reverse-Funktion:

Delphi-Quellcode:

function DoubleStringToWideString(DoubleString: WideString): widestring;
var
  ByteArray: Array of WideChar;
begin
  SetLength(ByteArray, Length(DoubleString) div 2);
  CopyMemory(@DoubleString[1], @ByteArray[0], Length(ByteArray));
  result := widestring(ByteArray);
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  // Sollte exakt ANSI "test" sein
  showmessage(DoubleStringToWideString(WideStringToString_Lossyless('test')));
end;

Diese funktioniert aber nicht ganz...

[Bernhard Geyer]

Wie schon gesagt: Entweder du suchst dir eine Funktion die mit einfachen Pointer + Längenangabe arbeitet oder du wandelst den String nach UTF8 um und hast das Ergebnis dan in einen String.

Deine Hacker-Funktionen werden scheitern wenn dein bisher ausgesuchte Base64-Methode geziehlt ein #$00 als Stop-Byte annimmt.

Schon mal überlegt ob die Zeile
SetLength(ByteArray, Length(UnicodeStr)); richtig ist wenn eine WideString-Character 2 Bytes einnimmt