uppercase und lowercase

[mse]

Was hat Dich auf die Idee gebracht ? Die Sourcecode-Datei ist jedenfalls nicht als utf-8, sondern als UCS2 abgespeichert (BOM= FFFE).

Dies ist sehr seltsam. Frag doch mal auf der Lazarus Mailinglist warum das so ist.

[theo]

beim Kompilieren -Fcutf8 anzugeben. FPC übersetzt dann zur Kompilierzeit die Stringkonstanten im Programm in widestrings,

Und wenn man die dann an die UTF-8 LCL schickt? Werden die auch automatisch wieder UTF-8?

[mschnell]

Warum mache ich mir denn solche Mühe, die Hintergründe aufzuzeigen, wenn du es doch nicht liest?

Recht hast Du ! Ich Wollte einfach nicht sehen, dass Lazarus die simple Zuweisung einer Konstante an einen WideString nicht richtig umsetzt .
Ich hätte es auch in meinem Erweiterten Beispiel sofort am Dump und an der Stringlänge sehen sollen, dass da etwas anders läuft als ich denke und es garnicht an der uppercase Funktion liegt.

Kannst Du meinen kurzen Beispiel-Code ("Button2Click", die dump()-procedure hatte ich in einer früheren Mail gepostet) nicht 'mal in MSEIDE (Windows und Linux) laufen lassen und das Ergebnis posten ?

-Michael

[mschnell]

Dies ist sehr seltsam. Frag doch mal auf der Lazarus Mailinglist warum das so ist.

Die Mailing-Liste funktioniert ziemlich schlecht (ich kann zwar mit dem Browser dort etwas posten, aber keine Mails hinschreiben). Das Forum ist momentan nicht erreichbar, Ich schreibe da was, wenn es wieder online ist.
-Michael

[mse]

Dies ist sehr seltsam. Frag doch mal auf der Lazarus Mailinglist warum das so ist.

Die Mailing-Liste funktioniert ziemlich schlecht (ich kann zwar mit dem Browser dort etwas posten, aber keine Mails hinschreiben). Das Forum ist momentan nicht erreichbar, Ich schreibe da was, wenn es wieder online ist.

Meinst du die Mailinglist lazarus@lazarus.freepascal.org? Die scheint zu funktionieren, die letzte Mail ist von 12:09:16.

[Christian]

Die Mailing-Liste funktioniert ziemlich schlecht

Das ding heisst MAILING Liste udn nicht Browser Liste. Da schickt mann ne E-MAIL mit suscribe hin und bekommt dann die Narichten weitergeleitet und kann ganz bequem mit dem Mail programm seiner Wahl mitschnacken.

[mse]

Und wenn man die dann an die UTF-8 LCL schickt? Werden die auch automatisch wieder UTF-8?

Nein, die Empfehlung richtet sich an MSEgui Anwender. Bei Lazarus darf -Fcutf8 nicht angegeben werden und es darf kein BOM vorhanden sein, sonst werden die durch den Compiler aus dem utf-8 Quelltext in widestring gewandelten String Konstanten zur Laufzeit mittels des widestringmanager und der aktuellen Systemcodierung bei der Zuweisung in ansistring oder UTF8String umgewandelt, was unter Windows in der Regel nicht die von Lazarus erwartete utf-8 Codierung ergibt. Siehe die Antwort von Jonas Maebe in fpc-devel:

When you set the encoding of an FPC source file to UTF-8 (either by
adding a BOM or by using {$codepage utf-8}), then
a) all constant strings containing utf-8 characters will be decoded
and converted to utf-16 (widestring)
b) at run time, these widestrings will again be converted to the
active code page when assigning them to ansistrings or shortstrings

If a file does not contain a BOM nor a {$codepage yyy} statement, then
constant strings are not parsed in anyway and will be appear literally
in the compiled program (and when assigning them to a widestring, they
will be "converted" from ansi to utf-16 and hence contain garbage at
the end).

This means that if you (ab)use ansistrings to store utf-8 strings
(rather than strings in the current ansi-encoding), you either have to
a) not use a bom/codepage, or
b) use UTF8Encode(widestringconstant)

Otherwise characters not representable using the active code page will
disappear during the run time conversion from widestring to ansistring
(and you won't end up with an utf-8 string in any case).

Durch den Verzicht auf -Fcutf8 wird leider die korrekte automatische widestring Konstantenbehandlung durch den Compiler verunmöglicht.

Martin

[theo]

@mse: Danke für die Klärung!
Ich hatte mir das so ähnlich schon gedacht und deshalb den Ansatz für Lazarus nicht weiter verfolgt.
Die automatische Umwandlung des Quelltextes nach WideString macht für Lazarus ja auch nicht wirklich Sinn.
Eine autom. Umwandlung bei Zuweisung von UTF8String an WideString (UTF-16) - und umgekehrt - zur Laufzeit wäre allerdings nicht schlecht.

[mschnell]

Da schickt mann ne E-MAIL mit suscribe hin und bekommt dann die Narichten weitergeleitet und kann ganz bequem mit dem Mail programm seiner Wahl mitschnacken.

Klar. Ich liebe mailing listen und verwende einige täglich. Aber die von Lazarus verwendet komische Software, wenn man auf Mail antwortet bekommt sie nicht die Liste, sondern der Administrator. Als der sich beschwert hat, habe ich damit aufgehört. Ist aber schon Jahre her...

-Michael

[mschnell]

Durch den Verzicht auf -Fcutf8 wird leider die korrekte automatische widestring Konstantenbehandlung durch den Compiler verunmöglicht.

Peinlich. Peinlich

-Michael

[mschnell]

Die automatische Umwandlung des Quelltextes nach WideString macht für Lazarus ja auch nicht wirklich Sinn.

Weil die LCL dann wieedr uÚTF8 verlangt und Verwendung jedweder LCL-Funktionalität mit weidestring durch die fehlerhafte automatische Umwandlung UTF8STtingWidestring durch den Compiler zu falschen Ergebnissen führt. Nur der Workaround mit umwandlung "von Hand" funktioniert korrekt

Eine autom. Umwandlung bei Zuweisung von UTF8String an WideString (UTF-16) - und umgekehrt - zur Laufzeit wäre allerdings nicht schlecht.

Meiner Ansicht nach absolut zwingend für eine Entwicklungsumgebung die nicht den ASnschein einer Bastelbude machen soll !!
Andererseits ist die Entscheidung, die LCL-API mit utf8 zu machen meiner Ansicht nach völlig blödsinnig !
-Michael

[Christian]

Aber die von Lazarus verwendet komische Software, wenn man auf Mail antwortet bekommt sie nicht die Liste, sondern der Administrator.

Nein, das ist korrektes verhalten du msst der liste antworten und nicht dem der den beitrag verfasst hat. Ordentliche Mail Programme haben speziell dafür einen button. Das ist komplett richtiges verhalten und wrd z.b. auch auf Listen vom CCC so gemacht. Durch die dummheit der Anwender haben einige Listen ihr verhalten nur umgestellt und dort kann man nun dem Beitragsersteller nicht mehr antworten weil man immer der Liste antwortet.

[theo]

Andererseits ist die Entscheidung, die LCL-API mit utf8 zu machen meiner Ansicht nach völlig blödsinnig !

"With the UTF-8 encoding, Unicode can be used in a convenient and backwards compatible way in environments that were designed entirely around ASCII, like Unix. UTF-8 is the way in which Unicode is used under Unix, Linux, and similar systems."

theo@theo102:~> echo $LANG
de_CH.UTF-8

[theo]

@mse:
Du schreibst in fpc-devel:
"One should normalize unicode text before processing. If normalized to fully
composed form there will be no problems with UCS2 single character processing
in Western Europe."

Hast du dafür einen Algorithmus auf Lager?

[mse]

Hast du dafür einen Algorithmus auf Lager?

MSEgui liefert grundsätzlich, bedingt durch Windows und X11 API, composed characters. MACOSX liefert Dateinamen in decomposed Form. Da Filenamen in MSEgui sowiso auf den MSEgui Stil normalisiert werden, werde ich in der Filenamenormalisierung auch auf composed character wandeln, falls es dann einmal eine OSX MSEgui version geben sollte. Bestimmt hat MACOSX eine entsprechende Funktion. Ich denke, auch in Linux gibt es eine entsprechende Bibliotheksroutine, utf8proc habe ich als Supportbibliothek mehrmals erwähnt gesehen. Die Umwandlung benötigt Tabellen und scheint sehr kompliziert zu sein:
http://www.unicode.org/reports/tr15/
http://en.wikipedia.org/wiki/Unicode_normalization