Unicode-Zeichen in TLabel.Caption

[Winni]

Hi!

Nun nötigt ihr noch n alten Mann zu Windows.

Anbei ein (vergrößerter) Schreenshot mit Super- und Subscript unter Windows7.

Ich weiß nicht, wo Eure Probleme liegen.

Oder ist das wieder einmal ein Win10/Win11-Problem?

Winni

[PascalDragon]

Bei der Gelegenheit könnte mit bitte jemand erklären, warum das Konstrukt oben funktioniert, ein direkter Typecast aber nicht. Ich versteh das nicht - sollte doch äquivalent sein?!

Code: Alles auswählen

  Label1.Caption := Unicodechar($03C3)+'_M'; // erzeugt ?_M

Ich hab's jetzt nicht ausprobiert, aber wahrscheinlich ist es folgendes: in deinem ersten Beispiel wird der String zur Laufzeit erzeugt, da ja ein Funktionsaufruf vorhanden ist (für diesen Punkt ist es nicht relevant, ob inline oder nicht). Die Lazarus IDE nutzt ja UTF-8, also wird auch ein entsprechender UTF-8 String zur Laufzeit erzeugt.
Im zweiten Beispiel wird der String zur Kompilierzeit erzeugt, FPC hat in dem Fall aber keine Ahnung, dass es UTF-8 ist (dazu muss entweder explizit $codepage utf8 genutzt werden oder die Datei eine UTF-8 BOM haben) und nimmt daher die Standardcogepage an, wofür es keine gültige Umwandung für $03C3 gibt. Daher das Fragezeichen.

[Jorg3000]

Hi!

Code: Alles auswählen

Label1.Caption := UnicodeChar($03C3)+'_M';  // erzeugt ?_M

Wenn UnicodeChar() verwendet wird, sollte es einem WideString/UnicodeString zugewiesen werden, damit kein Datenschwund eintritt.
Und da die Caption irgendeinen AnsiString erwartet, muss der UnicodeString zunächst in 8-Bit kodiert werden, wie im Folgenden z.B. in UTF-8.
Dann klappt's ...

Code: Alles auswählen

Label1.Caption := Utf8Encode( UnicodeChar($03C3)+'_M' );  // erzeugt σ_M

Grüße, Jörg

[Mathias]

Da gehen echt lustige Sachen, ob es mit Windows geht, keine Ahnung.

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  Caption:='❤️🧡💛💚💙💜🖤🤎';
end;  

[Socke]

Und da die Caption irgendeinen AnsiString erwartet, muss der UnicodeString zunächst in 8-Bit kodiert werden, wie im Folgenden z.B. in UTF-8.
Dann klappt's ...

Der Compiler fügt die Konvertierungen automatisch ein; er sagt nur nicht, welche Ziel-Codepage er verwendet und normalerweise informiert er darüber.

Ich habe aber die Vermutung, dass der Compiler die Konvertierung bereits selbst durchführt und sich dabei in der Kodierung vergreift. Ich hab da nochmal die effektiv verwendeten Codepages im Debugging verglichen:

Code: Alles auswählen

var
  uS: UnicodeString;
begin
  uS := UnicodeChar($03C3)+'_M';
  Label1.Caption := us;  // implizite Konvertierung von UnicodeString in einen AnsiString mit CodePage UTF-8
  
  Label1.Caption := UnicodeChar($03C3)+'_M';  // erzeugt einen AnsiString mit Codepage CP_ACP
end;

Dass ich das Verhalten mit {$codepage UTF-8} lösen kann, ist mir bewusst. Warum aber wird bei Konstanten eine andere Ziel-Codepage ausgewählt?

[PascalDragon]

Dass ich das Verhalten mit {$codepage UTF-8} lösen kann, ist mir bewusst. Warum aber wird bei Konstanten eine andere Ziel-Codepage ausgewählt?

Weil der Compiler keine Ahnung hat, dass zur Laufzeit die Codepage auf UTF-8 gesetzt wird (das macht nämlich die LCL während der Initialisierung). Untypisierte Stringkonstanten sind immer in CP_ACP und wenn die CodePage zur Kompilierzeit nicht mit der CodePage zur Laufzeit übereinstimmt dann hast du eben Buchstabensalat.

[theo]

Das mit den automatischen Umwandlungen bzw Codepages ist schon ein ziemlicher PITA (Was ich schon immer befürchtet hatte).

Ich hatte hier so einen Fall und mir ist das alles bis heute nicht ganz geheuer.
https://gitlab.com/freepascal.org/fpc/s ... sues/39554
Mich deucht, noch nicht einmal die FPC Entwickler sind mit der Problematik richtig vertraut.
Für den Normalo ist es schwierig zu durchschauen.