Lazarus geht mit ihren UTF8-Weg schon ziemlich einen ungewöhnlichen Weg. Viele Systeme (.NET/Java/Windows/Delphi) gehen den UTF-16 Weg.
Einspruch:
https://en.wikipedia.org/wiki/UTF-8
"UTF-8 is the dominant character encoding for the World Wide Web, accounting for 85.1% of all Web pages in September 2015"
UTF16 ist durch Windows weit verbreitet, wer sich aber mal eine typische Textdatei im Hex Editor anschaut, sieht sofort die Nachteile von UTF16, denn wie der Name schon beeinhaltet, ist für jedes Zeichen immer mindestens 2 Byte Platz erforderlich, auch wenn da nur
Ascii Zeichen wie A-Z und 0-9 drin stehen. Das betrifft im westeuropäischen Sprachraum sicherlich den Großteil aller Daten. Die Dateien sind daher bei gleichem Inhalt fast doppelt so groß. Und für den restlichen Bereich (Asien etc) sind die meisten Zeichen 4 Byte lang. Daher ist UTF8 im Sinne von Übertragung und Speicherung meistens ökonomischer. Das ist zwar eigentlich Haarspalterei, aber UTF8 ist keineswegs ungewöhnlich.
Trotzdem sollte eine Bibliothek die man (kostenpflichtig? Kauft) schon alle Eigenheiten des Unterstützen System berücksichtigen und nicht sagen: "Wir machen es in allen Systemen anders, also passt ihr euch an".
Ich frag mich sogar noch mehr, ob die das überhaupt umfassend testen. Den Vorschlag, das dann im GetText zu konvertieren, halte ich für eine komplette Bankrotterklärung. Man sollte nicht vergessen, das Komponenten wie die in Lazarus eingebauten
SQL DB Komponenten es auf jeder Plattform (windows, Linux, Mac usw) hinkriegen, ohne manuelles GetText das richtige Zeichen auf den Bildschirm zu bekommen.
Wenn man also als Komponentenhersteller die Komponenten aus reinem Opportunismus auf dieser Plattform "benutzbar" macht, in dem es sich kompilieren lässt und für einige der unterstützten Plattformen bzw Charsets auch benutzen lässt, dann sollten die den potentitellen Käufer doch drauf hinweisen. Wenn manfred_h der erste ist, der das gemerkt hat und man erst Tage später nach intensiven Nachhaken eine unbefriedigende Erklärung dazu geben kann, ist das im Sinne einer Produkthaftung sicherlich Grund genug, das Geld zurückfordern zu können. Ich gehe nämich auch davon aus, das beim Schreiben SetText ebenso behandelt werden müsste und spätestens jetzt macht die Komponente mehr Arbeit als man dadurch einspart, im Vergleich zu den eingebauten
SQL DB Komponenten.