Delphi 2010:
Folgendes konvertiert mir einen (Unicode)String zu AnsiString:

markieren

Delphi-Quellcode:

var
  u: UnicodeString;
  a: AnsiString;
begin
  u := 'abcäöü';
  a := AnsiString(u);

Beim AnsiString Cast gehen allerdings z.B. die deutschen Umlaute kaputt, bzw. werden in aou umgewandelt.

Es müsste doch möglich sein, anhand der aktuellen Codepage (GetACP) ein Umlaut aus einem UnicodeString in einen AnsiString zu retten, denke ich mir, nur weiß ich nicht wie. Dieses Schnipsel habe ich getestet, macht aber letztenendes dasselbe wie AnsiString():

zusammenfalten · markieren

Delphi-Quellcode:

function UnicodeStringToAnsiString(const ws: WideString; codePage: Word): AnsiString;
var
  l: integer;
begin
  if ws = '' then
    Result := '' 
  else
  begin
    l := WideCharToMultiByte(codePage,
      WC_COMPOSITECHECK or WC_DISCARDNS or WC_SEPCHARS or WC_DEFAULTCHAR,
      @ws[1], - 1, nil, 0, nil, nil);
    SetLength(Result, l - 1);
    if l > 1 then
      WideCharToMultiByte(codePage,
        WC_COMPOSITECHECK or WC_DISCARDNS or WC_SEPCHARS or WC_DEFAULTCHAR,
        @ws[1], - 1, @Result[1], l - 1, nil, nil);
  end;
end;

neee, genau andersrum
a := AnsiString(u); macht praktishc fast das Selbe, wie dein Code,
also per WideCharToMultiByte Unicode/UTF16 in einen AnsiString mit der aktuellen Codepage umwandeln.


Welche Codepage nutzt denn dein Windows? (bzw. welche Systemsprache ist dort eingestellt)
Wenn dort diese Zeichen nicht vorhanden sind, dann passen sie natürlich auch nicht dort rein.

Ach fu... normalerweise ein deutsches Vista mit deutscher Codepage, aber ich hatte ja noch zum Debuggen vor einiger Zeit eine russische Codepage eingestellt. Wenn die auf deutsch gestellt ist, klappt das casten mit AnsiString() auch mit den Umlauten. Danke für den Hinweis!

Als kleiner Tipp: Richte dir ein paar VMs ein teste dann dort.
So muß man nicht immer am Hauptsystem rumspielen
und hat auch noch den Vorteil ein einem "jungfräulichen" Windows zu testen.
(da ist dann vieles nicht installiert und man bekommt leichter mit, ob es auch bei Anderen laufen könnte)

Du hast ja so recht, mit VMs wird sowas zum Kinderspiel. Ich hatte sogar eine eingerichtet, die lief nur dann mit einer Windows Version in der dieser russische Fehler nicht auftrat. Die Idee mir eine zweite VM einzurichten ist natürlich genius...

Microsoft Virtual PC 2007 ist übrigens kostenlos und erfüllt seine Zwecke zum Debuggen.

Zitat von anse:

Ich hatte sogar eine eingerichtet, die lief nur dann mit einer Windows Version in der dieser russische Fehler nicht auftrat.

Eine blankes russisches Windows oder ein "getuntes"?
Auf russischen Windows wird teilweise die Codepage-Zuordnung von Windows "optimiert" um Nicht-Unicode-Apps zum laufen zu bekommen. Hier wird dann für die Übersetzungstabelle Unicod <-> Russisch die Westeuropäische Codepage konfiguriert so das hier deutsche Umlaute ein Wandlung "überleben".

Ein deutsches Windows XP, wo ich nur die Codepage umstellen musste. Unter deutschem Vista mit russischer Codepage hats mit dem Fehler dann "geklappt" Ob dat aber so wirklich stimmt weiß ich nicht mehr, ist schon etwas her.

Es könnte sein hier XP nicht weit genug umstellbar ist. Vista und neuer basieren auf den MUI-Ansatz von XP. Es gibt nur ein englisches Windows mit "aufgestülpter" Sprache. Sichbar auch an den System-Verzeichnisnamen die immer englisch sind und nur noch für die Darstellung übersetzt werden.