Unicode und WideChar API-Funktionen

[Dalai]

Hallo ihr .

Aus bestimmten Gründen versuche ich mich derzeit an Free Pascal. Leider blieb ich sehr schnell an der Thematik Unicode und WideChar API-Funktionen hängen, und auch die vielfältigen Angaben im Internet helfen mir nicht dabei, die Sache für mich zufriedenstellend - mit möglichst wenigen Änderungen am Code - zu lösen.

Gegeben sei folgender, auf das Wesentliche reduzierte Beispiel-Code:

Delphi-Quellcode:

program project1;

{$MODE DELPHI}

uses Classes, SysUtils, CustApp, Windows;

type
  TMyApplication = class(TCustomApplication)
  private
    FStr: string;
  [...]
  end;

procedure TMyApplication.DoRun;
begin
  [...]
  SetLength(FStr, 32768);
  SetLength(FStr, ExpandEnvironmentStrings(PChar('%SystemRoot%\System32'), @FStr[1], Length(FStr))-1);
  WriteLn(FStr);
  ReadLn;
end;

Funktioniert einwandfrei. Aber es wird die ANSI-Variante der API-Funktion (ExpandEnvironmentStringsA) importiert. Nun wollte ich die Sache unicodefähig machen, also dachte ich mir, setze ich {$MODE DELPHIUNICODE} . Leider Fehlanzeige:

Code:

Compile Project, Mode: Debug, Target: project1.exe: Exit code 1, Errors: 1, Warnings: 2
project1.lpr(36,14) Warning: Implicit string type conversion from "AnsiString" to "UnicodeString"
project1.lpr(38,44) Warning: Implicit string type conversion with potential data loss from "UnicodeString" to "AnsiString"
project1.lpr(52,50) Error: Incompatible type for arg no. 1: Got "PWideChar", expected "PChar"

(Der Error wird an der Stelle des Calls der API-Funktion gemeldet.) Soweit ich das bisher verstandenn habe, liegt das daran, dass nur die eigene Unit in Bezug auf Strings und PChars umdefiniert wird, die von FPC mitgebrachten Units aber nicht. Es wird also weiterhin ExpandEnvironmentStringsA benutzt.

Wie kann man das lösen bzw. was ist der empfohlene Weg, dass der Code sowohl in Delphi als auch FPC verwendbar ist? Es kann ja nicht Sinn der Sache sein, den Code mit expliziten Aufrufen der Wide-Funktionen und - bei umfangreicherem Code - zahllosen IFDEFs zuzupflastern...

Grüße
Dalai

[himitsu]

Dann mach es doch explizit als Unicode?

Delphi-Quellcode:

  private
    FStr: UnicodeString;  // oder WideString

  SetLength(FStr, ExpandEnvironmentStringsW(PWideChar('%SystemRoot%\System32'), @FStr[1], Length(FStr))-1);

Als ich zuletzt in FreePascal / Lazarus schautet, dann war da nichts mit "Unicode".
Oft wurde aber mit UTF-8 in einem "AnsiString" gearbeitet.

Windows benutzt aber UTF-16 bzw. früher UCS-2.

[Dalai]

Zitat von himitsu:

Dann mach es doch explizit als Unicode?

Das geht zwar, dann müsste ich aber sämtliche Variablen umstellen und alle API-Aufrufe ersetzen - bei beiden mit einigen Ausnahmen, weil es API-Funktionen gibt, die ANSI-Chars erwarten bzw. ausgeben. Den Aufwand, diese Änderungen in wahrscheinlich einem Dutzend eigener Units durchzuführen, will ich vermeiden. Zumal dabei die Gefahr besteht, im alten Delphi funktionierenden Code zu vermurksen.

Zitat:

Als ich zuletzt in FreePascal / Lazarus schautet, dann war da nichts mit "Unicode".

Auch wenn es den Mode jetzt gibt, nützt das IMO überhaupt gar nichts, wenn nicht auch die mitgelieferten Units mit umgestellt sind/werden. Praktisch verwendbar ist diese nur partielle Umstellung nicht. Aber vielleicht gibt es noch einen mir bislang unbekannten Weg, der keine umfangreichen Umbauarbeiten erfordert.

Grüße
Dalai

[Dalai]

Das Eingangsbeispiel ist wohl etwas zu knapp ausgefallen ist. Hier ein etwas längeres, das die Problematik (hoffentlich) besser verdeutlicht:

Delphi-Quellcode:

program project1;

{$MODE DELPHI}

uses Classes, SysUtils, CustApp, Windows, IniFiles;

type
  TMyApplication = class(TCustomApplication)
  private
    FStr: WideString;
    FValue: WideString;
    FFileName: WideString;
  [...]
  end;

procedure TMyApplication.DoRun;
begin
  [...]
  FFileName:= 'C:\irgendeine.ini';
  FIni:= TIniFile.Create(FFileName);        // <--
  try
    FValue:= FIni.ReadString('foo', 'bar', 'blub');   // <--
    SetLength(FStr, 32768);
    SetLength(FStr, ExpandEnvironmentStringsW(PWideChar(FValue), @FStr[1], Length(FStr))-1);
  finally
    FIni.Free;
  end;
  WriteLn(FStr);
  ReadLn;
end;

Die markierten Zeilen werfen folgende Warnungen:

Code:

Compile Project, Mode: Debug, Target: project1.exe: Success, Warnings: 2
project1.lpr(55,35) Warning: Implicit string type conversion with potential data loss from "WideString" to "AnsiString"
project1.lpr(57,18) Warning: Implicit string type conversion from "AnsiString" to "WideString"

Das heißt, selbst wenn ich explizit WideString nutze, renne ich gegen eine andere Wand. Das muss doch besser gehen.

Grüße
Dalai

[himitsu]

Bei implizitem Cast wird gemeckert,

aber bei expliziten Casts nicht:

Delphi-Quellcode:

  FIni:= TIniFile.Create(AnsiString(FFileName));
  try
    FValue:= WideString(FIni.ReadString('foo', 'bar', 'blub'));

Das Zweite wäre kein Problem, da ja Klein zu Groß und es somit rein passen würde.

Beim Ersten, sieht es anders aus ... also problematisch, wenn Unicodezeichen im Dateiname vorkommen würden, welche außerhalb des jeweiligen ANSI-Zeichenraumes liegen.


ABER, ist das wirklich AnsiString, oder nicht vielleicht doch z.B. UTF-8 String?

Ich dachte der FPC hätte in seiner RTL schon "Unicode" und eben nicht ANSI.
Wenn z.B. ein UTF8-String, dann wäre es schon unpraktisch, wenn FPC keine automatische Konvertierung zwischen den String-Typen bietet.


Wie genau sind denn TIniFile.Create und TIniFile.ReadString "wirklich" deklariert?
https://www.freepascal.org/docs-html...eadstring.html

Wenn tatsächlich "String" und String = AnsiString, dann ... Wo bitte hat FPC denn seine unicode-fähige INI-Klasse versteckt?

[jaenicke]

Es gibt bei Lazarus eine Includedatei für Ansi und eine für Unicode für den Zugriff auf die API. Ich habe aber keine Ahnung, wie man die Unicodeversion aktiviert. Der Schalter in den Projekteinstellungen scheint es nicht zu sein.

Ich habe aktuell Lazarus nicht installiert und kann nicht nachschauen. Ich hatte aber mal gesucht.

Soweit ich das sehe, wird intern zwar UTF-8 verwendet, aber statt dieses dann umgewandelt in UTF-16 automatisch an die Unicode-API zu füttern, wird offenbar (mit den Standarddirektiven) fest Ansi verwendet.

Das war bei Delphi 7, an das ja auch die Oberfläche von Lazarus angelehnt ist, aber auch nicht anders. Insofern...