Von wegen UTF-8 ist die Quelle allen Übels...

[theo]

ohne Fehlermeldung durch den Compiler geht, muss auch was sinnvolles rauskommen, egal welchen Type MyString hat.

Mit Ansi<>Unicode geht das einfach nicht sauber. Wenn der Compiler meinetwegen UTF8<>UTF16 automatisch konvertieren würde, hätte ich nichts dagegen.
Die automatische Ansi<>Unicode Konvertierung muss imho verschwinden.
Der Sinn des Delphi "Multi-Kulti-Strings" leuchtet mir eig. auch nicht so richtig ein. Es reicht doch intern mit Unicode zu arbeiten.
Wieso ich z.B. einen koi8 Codepage String mitschleppen sollte, erschliesst sich mir in einer Unicode Umgebung nicht so wirklich.

[mse]

Der Compiler konvertiert nicht ASCII Stringkonstanten zur Kompilierzeit nach utf-16, falls er die Codierung des Quellcodes kennt. Diese Stringkonstanten werden zur Laufzeit von utf-16 in die aktuelle Systemkodierung gewandelt, was je nach Locale nur mit Verlusten funktioniert. Bei utf-8 Locale ist die Wandlung immer verlustfrei. So übel finde ich das eigentlich nicht.
Dumm ist nur, dass der Kompiler bei Lazarus die Codierung des Quellcodes nicht wissen darf, da Lazarus AnsiString auch auf Platformen mit nicht utf-8 Systemcodierung als UTF8String verwendet.

[theo]

Dumm ist nur, dass der Kompiler bei Lazarus die Codierung des Quellcodes nicht wissen darf, da Lazarus AnsiString auch auf Platformen mit nicht utf-8 Systemcodierung als UTF8String verwendet.

Ich versteh das Problem eigentlich nicht ganz. Wieso kann der FPC die Lazarus Quellen nicht als UTF-8 behandeln?
ANSI brauchen wir eigentlich im System nicht mehr, bzw. das kann an der Peripherie in der RTL (Dateinamen etc.) mit SysToUTF8 bearbeitet werden.

Bin für Denkfehlermeldugen empfänglich.

[mse]

Ich versteh das Problem eigentlich nicht ganz. Wieso kann der FPC die Lazarus Quellen nicht als UTF-8 behandeln?

FPC wird halt nicht ausschliesslich von Lazarus verwendet und ist mit der Ansistring<->Wide-UnicodeString Konvertierung Delphi kompatibel.
Ich bin jetzt nicht ganz sicher, meinst du, warum der bestehende FPC Lazarus Quellen nicht als utf-8 behandeln darf, oder meinst du einen zukünftigen "Lazarus-only" FPC?

[theo]

Ich kenne die Internas des FPC nicht gut. Deshalb interessiert es mich (nicht in-depth) was möglich ist, und wo die Haken sind.
Ich meine, dass wenn Lazarus die Quellen mit einem UTF8-BOM speichern würde, die von mschnell geforderten WideString-Konstanten neben UTF8-Konstanten eigentlich machbar sein müssten (In einem jetzigen oder zukünftigen FPC?).
Wie das in der RTL mit Filenamen usw. gehandelt werden könnte, wäre eine weitere Frage. Wir bauen die RTL ja nicht extra für Lazarus, deshalb kommen Kompilerschalter (z.B. UTF8_RTL, UTF16_RTL, ANSI_RTL) wohl eher nicht in Frage.

[mse]

Im jetzigen FPC ist AnsiString ein 8bit String in der aktuellen Systemcodierung zur Laufzeit. Da die Codierung der AnsiString zur Compilezeit nicht bekannt ist, werden Stringkonstanten, die nicht ASCII-Zeichen enthalten, zur Compilezeit von der Codierung der Quelle in utf-16 gewandelt und als utf-16 im Binary gespeichert. Bei der Zuweisung der Stringkonstanten an AnsiString zur Laufzeit, wird utf-16, möglicherweise mit Verlust, in die jeweilige Systemcodierung gewandelt, der Widestringmanager erledigt dies. Bei der Zuweisung an Wide/UnicodeString muss nicht gewandelt werden.
Lazarus benützt AnsiString als Container für utf-8 auch unter Windows, wo die Systemcodierung meist nicht utf-8 ist. Daher muss dieser Mechanismus ausser Kraft gesetzt werden. Lazarus erreicht dies, indem FPC die Codierung der Quelle vorenthalten wird (kein BOM, kein -Fcutf8). Nun kann der Compiler nicht in utf-16 wandeln, sondern speichert die unveränderte Bytefolge im Binary. Bei der Zuweisung an AnsiString zur Laufzeit wird die Bytefolge unverändert kopiert, das heisst, der Laufzeit AnsiString hat die gleiche Codierung wie die Quelle. Dies widerspricht nun Anwendungen, wo man in AnsiString, wie von Delphi vorgesehen, gerne die aktuelle Systemcodierung hätte. Ebenfalls verunmöglicht das Verfahren die bequeme Verwendung von Wide/UnicodeStrings.

[theo]

Kleiner Einschub:
Hab grad mal wieder mseide gezogen und kurz ausprobiert.
Mit intuitivem Ansatz geht das mit den Umlauten aber schon mal tüchtig in die Hose.
Was habe ich falsch gemacht? Ich hab in die Demo nur den Code bei doitonexecute eingefügt und die Umlaute werden nicht richtig angezeigt (siehe label oberhalb doit).

EDIT: Ach so, ich muss bei Projekt Optionen das encoding auf iso-etcpp ändern. Aber wieso? Was hab ich unter Linux damit am Hut?

EDIT2: Das Anzeigen kyrillischer Zeichen gelingt mir aber mit keiner Einstellung:
z.B.
tlabel1.caption:='За драку, из-за которой';

[mse]

EDIT: Ach so, ich muss bei Projekt Optionen das encoding auf iso-etcpp ändern. Aber wieso? Was hab ich unter Linux damit am Hut?

EDIT2: Das Anzeigen kyrillischer Zeichen gelingt mir aber mit keiner Einstellung:
z.B.
tlabel1.caption:=;

Unter Linux muss die unit cwstring in uses aufgenommen werden um den Widestringmanager zu aktivieren. Werde das Demo entsprechend ergänzen.
Die platformübergreifende Unicode Einstellung ist utf8 als Source Codierung und -Fcutf8 als Compiler Parameter. Unter utf-8 Linux kann man diese Einstellungen auch weglassen und lediglich cwstring in uses aufnehmen.
Edit:
Wobei mir schleierhaft ist, warum cwstring im Demo nicht gelinkt wird, cwstring ist in uses von msesysintf und das wird doch in jedem Fall gebraucht?

[theo]

Unter Linux muss die unit cwstring in uses aufgenommen werden um den Widestringmanager zu aktivieren.

cwstring hilft nix.
Quelle ist in UTF-8 (mit Kwrite getestet), Projektoptionen Encoding utf8.
Sehe aber trotzdem Müll.

Free Pascal Compiler version 2.4.0 [2010/01/09] for i386
OpenSuSE 11.1
$LANG=de_CH.UTF-8

[mse]

Unter Linux muss die unit cwstring in uses aufgenommen werden um den Widestringmanager zu aktivieren.

cwstring hilft nix.

Habe ich auch soeben festgestellt, cwstring ist schon gelinkt. Scheinbar ist neuerdings der Compilerparameter -Fcutf8 obligatorisch ('Project'-'Options'-'Make'-'Make options'). Nun die Frage, warum?
Edit:
FPC scheint zur Kompilierzeit ohne BOM und ohne -Fcxxx ISO-Latin1 zur Konvertierung von Unicode Konstanten zu verwenden.
IIRC war das schon mal so, dann eine Zeit lang nicht mehr und jetzt wieder? Nun ja...
Übrigens wird im MSEgui Quellcode zur Vermeidung dieser Probleme ausschliesslich ASCII verwendet. MSEide hat im Editor den Popupmenu Befehl 'Convert to Pascal string' zur Umwandlung.

[theo]

Scheinbar ist neuerdings der Compilerparameter -Fcutf8 obligatorisch ('Project'-'Options'-'Make'-'Make options').

Ja, so geht's.

[theo]

Übrigens wird im MSEgui Quellcode zur Vermeidung dieser Probleme ausschliesslich ASCII verwendet. MSEide hat im Editor den Popupmenu Befehl 'Convert to Pascal string' zur Umwandlung.

Naja, das ist aber auch nicht das Gelbe vom Ei...

[mse]

Naja, das ist aber auch nicht das Gelbe vom Ei...

Für MSEgui mache ich es trotzdem so, damit sich die Anwender um nichts kümmern müssen.

[theo]

Zurück zum Thema

Stelle fest, dass in Lazarus mit der Einstellung:
{$codepage utf8}
folgender Code einwandfrei funzt:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var ws:widestring;
s:string;
const wsc:WideString='öäü';
const wcc:WideChar='Ω';
begin
 ws:='öäü';
 s:='öäü';
 Caption:=UTF8Encode(ws)+s+UTF8Encode(wsc)+UTF8Encode(wcc);
end;

Warum meinst du, dass das nicht die Standardeinstellung bei Lazarus sein kann?

[mschnell]

Der Compiler konvertiert nicht ASCII Stringkonstanten zur Kompilierzeit nach utf-16, falls er die Codierung des Quellcodes kennt. Diese Stringkonstanten werden zur Laufzeit von utf-16 in die aktuelle Systemkodierung gewandelt, was je nach Locale nur mit Verlusten funktioniert.

Hört sich aber nicht sehr clever an. Warum legt er die konstanten Strings nicht gleich in der Codierung an, wie sie benötigt werden ?
-Michael