AnsiString zu String zuweisen ohne Konvertierung?

[Uwe Raabe]

Hast du schon mal daran gedacht, anstatt der Unicodestrings besser TBytes zu verwenden? Dann kann dir das Encoding nämlich völlig egal sein.

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

[Dennis07]

Zitat von Uwe Raabe:

Hast du schon mal daran gedacht, anstatt der Unicodestrings besser TBytes zu verwenden? Dann kann dir das Encoding nämlich völlig egal sein.

Ist ja quasi was ich geschrieben habe. Nur wirst du mit TBytes das selbe Problem haben wie mit PAnsiChar@UnicodeString, nämlich, dass du nicht richtig darauf zugreifen kannst, wenn du die Anpassung der Byte-Offsets nicht vornimmst. Es gibt sicher auch eine Funktion dafür, die mir allerdings zum jetzigen Zeitpunkt nicht bekannt ist.

[Rolf Frei]

@Dennis07
Herzlichen Dank für deine Erklärung. Dann gibt es also keine Möglichkeit das ohne "Aufwand" zu lösen. Meine for-Schlauefe würde dann ja auch das mache was ich will und wäre viel einfacher, als dein Code. Vermutlich aber auch etwas langsamer. Das wäre hier aber keine Problem, da diese Routine nur sehr vereinzelt aufgerufen wird.

Ich mache nun sowas in der Art:

Delphi-Quellcode:

var
  a: AnsiString;
  s: String;
begin
  a := #$33#$95#$34;
  SetLength(s, Length(a));
  for i := 1 to Length(a) do
    s[i] := Char(Ord(a[i])); 
end;

Damit kann ich leben und sollte für meine Zwecke auch schnell genug sein.

@Uwe Raabe
Ja an TBytes habe ich schon gedacht, aber das dann auch recht schnell wieder verworfen, das das sonst zu umständlich wäre, diese Funktion in der ich das so brauche, aufzurufen. Müsste ja dann von extern in ein TBytes umgewandelt werden. Ich möchte der Funktion aber ein String übergeben, damit das nicht bei jedem Aufruf der Funktion so umständlich wird.

Was mir aber immer noch Probleme macht, ist das TIniFile, das mir die ANSI Werte falsch liefert. Kann da zwar TMemIniFile mit Angabe einer Encoding verwenden, das hat aber meines erachtens zu viel Overhead, da damit immer das ganze File verabeitet wird. Wenn ich nur einen einzlnen Wert schreiben/lesen will, ist das nicht gerade optimal. Da müsste auch ein Read-/WriteAnsiString existieren um das Problem zu lösen. Dass es das nicht gibt empfinde ich schon als grober Fehler in der TIniFile Implementation, da es so nicht möglich ist einen sauberen AnsiString zu erhalten. 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.

[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