AnsiString zu String zuweisen ohne Konvertierung?

[p80286]

Zitat von Rolf Frei:

Da beim Einlsenen der Werte diese in einen Unicodestring umgewandelt werden, werden diverse Zeichen in einen Wert > 255 umgewandelt und mit diesen kann ich nicht weiter arbeiten, da meine Routine verlangt, dass da nur 1-Byte Zeichen (Werte 0-255) kommen.

Etwas anders formuliert:
TIniFile liefert nur 16Bit-Werte und Deine Routine kann nur 8Bit-Werte verarbeiten. Da bleibn letztlich zwei Möglichkeiten, schreib TIniFile neu oder deine Routine. Wobei ich Dir empfehle Deine Routine zu überarbeiten Da sie augenscheinlich mit binären werten arbeitet und mit Zeichen gefüttert wird. Das ist schon immer eine ungute Mischung gewesen.

Gruß
K-H

[Gausi]

Nun, da wird ja korrekt umgewandelt. In Windows-1252 ist das Zeichen #95 ein Punkt. In der Unicode-Nummerierung steht da jedoch ein nicht-druckbares Zeichen. Die 95 wird dann korrekt auf #2022 gemappt, siehe auch https://de.wikipedia.org/wiki/Windows-1252

Wenn du das nicht gebrauchen kannst, dann musst du konsequent mit AnsiStrings arbeiten, oder auf Byte-Ebene runter und von der Interpretation als "String" (d.h. die angezeigten Buchstaben und Zeichen). Oder du versucht es mit Codepages, wo die #95 eben dieses nicht-druckbare Zeichen ist. Aber was das für Nebenwirkungen bei der Anzeige und Delphi-internen Stringverarbeitung haben kann, weiß ich nicht ...

Sinnvoller wäre sicherlich die Verarbeitungsmethode anzupassen, wie p80286 auch schon schrieb.

[Uwe Raabe]

Ich vermisse immer noch eine Erklärung für die Anforderung, daß ein #95 eines AnsiStrings gerade nicht als #2022 eines UnicodeStrings wiedergegeben werden soll. Für mich sieht das so aus, als ob die die Strings (Ansi oder Unicode) nicht wirklich als Strings verwendest, sondern als Byte-Speicher.

[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

[himitsu]

[deleted] weil doppelpost

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