AnsiString zu String zuweisen ohne Konvertierung?

[himitsu]

Zitat von Uwe Raabe:

Für mich sieht das so aus, als ob die die Strings (Ansi oder Unicode) nicht wirklich als Strings verwendest, sondern als Byte-Speicher.

Das (dafür sollte er mindestens gesteinigt werden) oder er hat im AnsiString eine andere Codierung und vergessen das dem AnsiString mitzuteilen.

Zitat:

255 umgewandelt und mit diesen kann ich nicht weiter arbeiten, da meine Routine verlangt, dass da nur 1-Byte Zeichen (Werte 0-255) kommen.

Und warum konvertierst du das dann nicht wieder zurück in einen AnsiString?

Nja, ansonsten bleibt dir nur noch die INI direkt auszulesen (als ANSI) und den Inhalt selbst zuparsen,
oder du könntest auch die ANSI-Version der INI-API benutzen (in Delphi ist seit 2009 nur noch die Unicode-API als Klasse implementiert (bis Delphi 2006/2007 die AnsiAPI).
GetPrivateProfileStringA (GetPrivateProfileString)

PS: RawByteString

[p80286]

Zitat von himitsu:

Zitat von Uwe Raabe:

Für mich sieht das so aus, als ob die die Strings (Ansi oder Unicode) nicht wirklich als Strings verwendest, sondern als Byte-Speicher.

Das (dafür sollte er mindestens gesteinigt werden) ...

Steinigen halte ich für übertrieben. Er verwendet wohl eine Technik die viele Jahre lang (bis zur Einführung von 16Bit Zeichensätzen) gut funktioniert hat, Wenn er aus der C-Ecke kommt "Zum Speichern eines Zeichens (sowie von kleinen Zahlen) verwendet man in C üblicherweise den Datentyp Character, geschrieben als char." ist das auch verständlich.

Zitat:

Wenn du deinen konkreten Anwendungsfall beschreiben könntest, und nicht nur das Symptom, dann könnte man vielleicht eine Lösung formulieren

#8
Eigentlich ist dem nichts hinzu zu fügen.

Gruß
K-H

[himitsu]

Joar, was aber nicht bedeutet, das es jemals "richtig" war.
Tja, wenn er weiterhin AnsiString statt String/UnicodeString verwendet hätte, dann wäre es zwar immernoch nicht ganz richtig, aber naja.

PS: hier ist es nur #$95, aber es gibt noch massig andere Sprachen im Windows.
Ihr wollt nicht wissen was dann alles bei Russisch, Chinesisch usw. passiert.

Aber ByteArrays gibt es schon lange und wie gesagt RawByteString, SetCodePage usw.
Allergings ist RawByteString auch ein AnsiString, so wie der UTF8String, welcher mit Einführungen von NextGen leider am Aussterben ist.

Seit 2009 ist im AnsiString/UnicodeString neben neben Length und RefCount auch die Codepage und CharSize gespeichert, was man auch gut nutzen kann.

[Rolf Frei]

Zitat von himitsu:

Und warum konvertierst du das dann nicht wieder zurück in einen AnsiString?

Weil das nicht geht und ich dann ? Zeichen erhalte. Das $95 ist im Ansi ein Kontrollzeichen und wird bei der Umwandlung dann zu einem ?.

In D7 war das problemlos möglich ein Inifile mit beliebigen Zeichen zu füttern. In Rio muss ich diese Daten auch lesen können, da diese so exisitieren und ich diese verarbeiten muss. Es handelt sich dabei um verschlüsselte Daten die ich entschlüsseln muss und dafür kann ich keine verfälschten Daten brauchen. TIniFile soll doch bitte eine Möglichkeit bieten, dass ich gleich an die Daten rankomme wie bisher, also das ich Ansi Daten aus einem Ansi INI-File auch als solche erhalten kann. Da fehlt einen Funktion zum Lesen reiner Ansidaten ohene Konvertierung, da ein zurückwandelt in ein Ansi String dann ? enthalten könnte und somit die ganze Daten wertlos sind.

Rawbyte hilft mir hier nicht weiter, habe das schon alles x-fach getestet und es macht keinen Unterschied ob ich da RawByteString oder AnsiString nutze. Das TIniFile liefert einen Unicodesrting retour, obwohl das INI-File ein Ansi File ist und das ist schlicht falsch.

@Gausi
Wir reden hier von $95 (HEX) und nicht 95 Dezimal.


Hier mal ein Beispiel eines INI-File Werteintrages wie er aktuell besteht und den ich nun unter Rio verarbeiten muss:

Code:

Password2=«œ¨¥‹‘ÓÆÁý   

Beispiel ist so nicht richtig, da ich keine Unicodezeichen im Original habe! Die Forumsoftware hat das leider umgewandelt. Aber mein Problem dahinter versteht ihr vieleicht nun besser.

[Klaus01]

.. seit Delphi 2009 ist der String ein Unicode String.
Somit gibt TiniFile.ReadString auch einen Unicode String zurück.

Könntest Du es nicht mit einem Class-Helper für TiniFile
die Methode ReadString:AnsiSring überschreiben?

Ein Beispiel für einen Helper mit TIniFile findest Du hier.
Sehe gerade das man mitHelper keine Methode überschreiben kann.
Du könntest eine eigene Methode einführen.

Oder TIniFile ableiten und ReadString überschreiben.


Grüße
Klaus

[Bbommel]

Hast du es mal mit TMemIniFile anstelle von TIniFile versucht? Hier kannst du eine Encoding mitgeben, die die Quelle haben soll. Zumindest beim Lesen der ini in die Stringlist wird diese Encoding dann auch beachtet. Müsstest du mal testen, ob dir das hilft - ich habe hier kein passendes Beispiel, um das auf die Schnelle herauszubekommen.

[himitsu]

Zitat von Bbommel:

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.

[Uwe Raabe]

Zitat von Rolf Frei:

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?