AnsiString zu String zuweisen ohne Konvertierung?

[Uwe Raabe]

Zitat:

Zitat von Rolf Frei (Beitrag 1453034)

Es handelt sich dabei um verschlüsselte Daten die ich entschlüsseln muss und dafür kann ich keine verfälschten Daten brauchen.

Also doch Byte-Sequenzen, die fälschlicherweise als Ansi-Char deklariert wurden. Du wirst mit Strings und TStringlist in dem Fall nicht glücklich werden (zumindest nicht bei Delphi-Versionen > D2007).

[Rolf Frei]

Schau dir bitte nochmals die letzte Nachricht an. Habe da noch Ergänzungen mit einem Beispiel gemacht.

Das sind nur Daten die so in einem INI File abgelegt sind und die ich beim Einlesen/Schreiben Ent/Verschlüssle. Als Resultat bekomme ich dann ganz normalen Text und nichts Binäres.

Und ja das würde ich heute nicht mehr so machen, aber das ist vor 20 Jahren so entstanden und hat nun gute 20 Jahre problemlos funktioniert. Werde auch im Zuge der Portierung des D7 Programms auf Rio diesen Teil überarbeiten und die Daten anders ablegen. Die bestehenden Daten muss ich aber dennoch verabreiten können.

[Bbommel]

Hallo Rolf,

ich habe mal ein kleines Testprogramm gebastelt und bekomme die Zeichen hier mit Hilfe eines RawByteString und mit TmemIniFile korrekt, wenn ich deine Anforderung richtig verstanden habe:

Delphi-Quellcode:

program readansiini;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  IniFiles;

var
  myIni: TMemIniFile;
  rawStr: RawByteString;
  uniStr: string;
  i: integer;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    myIni:=TMemIniFile.Create('test.ini',TEncoding.ANSI);
    rawStr:=rawByteString(myIni.ReadString('test1','password',''));
    write('Raw: ');
    for I := 1 to Length(rawStr) do
      write(ord(rawStr[i]).ToString+' -- ');
    Writeln(rawStr);
    Write('Unicode: ');
    uniStr:=myIni.ReadString('test1','password','');
    for I := 1 to Length(uniStr) do
      write(ord(unistr[i]).ToString+' -- ');
    writeln(uniStr);
    readln;
    myIni.Free;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

In der Datei test.ini steht an der zweiten Stelle das von dir erwähnte Zeichen Hex 96 (also Dec 150). Im rawByateString bleibt es auch korrekt erhalten, im Unicode-String wird es, wie von dir beschrieben, umgewandelt. Die Ausgabe vom Programm ist hier also (wichtig ist die zweite Zahl):

Code:

Raw: 116 -- 150 -- 116 -- 252 -- 116 -- 228 -- t-tütä
Unicode: 116 -- 8211 -- 116 -- 252 -- 116 -- 228 -- t-tütä

Das heißt: damit müsstest du deine bisherigen Daten doch ohne for-Schleife und ähnliches lesen und konvertieren können?

[TiGü]

Verstehe nicht, warum du dir nicht einfach TIniFile rauskopierst und die Aufrufe entsprechend anpasst:
GetPrivateProfileString -> GetPrivateProfileStringA
WritePrivateProfileString -> WritePrivateProfileStringA
MarshaledString -> MarshaledAString

Das ist doch eine Sache von zwei Minuten.
Du programmierst mindestens seit dem Jahre 2006 in Delphi, das ist doch kein Hexenwerk?!?!

[Rolf Frei]

@Bbommel
Danke für deine Bemühungen, aber das habe ich ja schon erwähnt, dass es mit einem TMemIniFile klappen würde. Das habe ich bereits in einem Post erwähnt und auch erklärt, wieso mir das nicht so recht gefällt. Dass da immer das ganze INI File geladen und geschrieben wird ist nicht ideal. Brauche es aber nun dennoch, weil so das Problem vorerst behoben ist.

@TiGü
Natürlich könnte ich das so machen, aber das wäre der absolut letzte Ausweg, wenn nichts anderes gehen würde. Ich kann das Problem mit einem TMemIniFile lösen, nur gefällt mir das eben nicht so gut, weil das das ganze File bearbeitet und nicht nur einen einzelnen Eintrag. Es hat also einen unnötig grossen Overhead.


Das Thema ist also hiermit für mich gelöst und somit abgeschlossen. Danke für all eure Tips und Ratschläge.

[Bbommel]

Zitat:

Zitat von Rolf Frei (Beitrag 1453049)

@Bbommel
Danke für deine Bemühungen, aber das habe ich ja schon erwähnt, dass es mit einem TMemIniFile klappen würde. Das habe ich bereits in einem Post erwähnt und auch erklärt, wieso mir das nicht so recht gefällt. Dass da immer das ganze INI File geladen und geschrieben wird ist nicht ideal. Brauche es aber nun dennoch, weil so das Problem vorerst behoben ist.

Ach, Mist, dann hatte ich genau den Post dazu übersehen. Sorry für den Hinweis auf etwas, was du schon wusstest. Aber wenigstens funktioniert es. :-)

[Moombas]

Mal eine komplett andere, vielleicht bekloppte Frage: Warum speicherst du die Ini-Datei nicht einfach im entsprechenden Format (von Delphi)?
Also:
- Original Datei öffnen
- Neue Datei erstellen (leer) und im richtigen Format speichern
- Inhalt der Original-Datei in die neue kopieren und abspeichern
- Original-Datei ersetzen

Dann müsste lesen/schreiben doch problemlos funktionieren!?
Zumindest hat mir das bei Lazarus den A**** gerettet, ohne das ich groß rum programmieren musste.

[TiGü]

Ähm...dir ist schon klar, was genau unter der Motorhaube passiert, wenn man mit dem TIniFile und damit mit den oben erwähnten Windows-Funktionen arbeitet?

Da wird die Datei auch immer komplett geöffnet (CreateFileW, CloseHandle) und zwar für JEDEN einzelnen String, den man sich per TIniFile.ReadString holt.
TMemIniFile ist in der Hinsicht sogar effizienter, weil man viel viel weniger mit dem Dateisystem hantiert.

Ein Blick in die Sourcen vom Wine-Projekt sind an der Stelle ganz erhellend:
https://github.com/ValveSoftware/win...rofile.c#L1088

[Uwe Raabe]

Also hier funktioniert das tadellos mit den Bytes und UnicodeStrings und AnsiStrings. Du darfst nur nicht mit den UnicodeStrings das encode/decode machen. Dafür nimmst du dann die Bytes.

Delphi-Quellcode:

var
  a: AnsiString;
  b: TBytes;
  s: String;
begin
  a := #$33#$95#$34;
  s := a;
  { Der Inhalt von s interessiert hier nicht. Zur Verarbeitung wandeln wir das in Bytes um. }
  b := TEncoding.ANSI.GetBytes(s);
  Assert(b[0] = $33);
  Assert(b[1] = $95);
  Assert(b[2] = $34);
  a := s;
  Assert(a = #$33#$95#$34);
end;

Ich habe jetzt gerade kein Beispiel mit TInifile, aber mit

Delphi-Quellcode:

LoadFromFile(<filename>, TEncoding.Ansi)

sollte das ebenso funktionieren.

[himitsu]

Zitat:

Zitat von Bbommel (Beitrag 1453040)

Hast du es mal mit TMemIniFile anstelle von TIniFile versucht?

Hier keine Lösung.

Bei TIniFile geht der Zugriff direkt auf die Datei, also ein zusätzliches ReadAnsiString wäre möglich.
Bei der TMemIniFile wurde bereits alles in Unicode umgewandelt und der Originale String ist nicht mehr vorhanden, wenn er sich nicht zurückumwandeln lässt.

Falls man bei TMemIniFile die Codepage/TEncoding beim Laden angeben kann, dann dort eine passende Codepage verwenden (z.B. siehe

Zitat:

Weil das nicht geht und ich dann ? Zeichen erhalte.

? ist das falsche Standard-Ersatzzeichen von Windows (das Unicode Consortium hat eigentlich was anderes definiert, aber egal).
Grundsätzlich sollten sich auch nahezu alle Zeichen auch verlustlos zurückkonvertieren lassen.
ANSI->Unicode->ANSI, vorausgesetzt auf beiden Seiten ist die selbe Codepage vorhanden (Codepage -> UCS2 bzw. UTF16 -> gleiche Codepage)


Wie gesagt, entweder sowas nicht machen, oder die Daten in der INI passend codieren.
Oder die Datei mit ANSI-APIs auslesen.