martin_frb hat geschrieben:Nur wenn das ä normalisiert ist. ä kann auch als 2 codepoints a und "2 punkte drüber" gespeichert werden.
Das gilt für utf-8 auch. Benutzt du in deinen Programmen die decomposed Form ohne dass du davon weisst? Benutzt ein Anfänger solche Sachen? Ist es für den Anfänger nicht ein Nutzen, wenn er sich nicht schon am ersten Tag um die Fussangeln der Textverarbeitung kümmern muss? Gibt es hier im Deutschen Lazarusforum Themen mit Umlautproblemen, welche in utf-16 ebenfalls auftreten würden?
Und während europäisch Zeichen meist eine Normalform haben stimmt das in anderen Sprachen nicht. Im z.B. Arabischen (IIRC) gibt es Zeichen mit mehreren Akzenten, und die sind immer in mehreren codepoints gespeichert (utf8 und utf16 und afaik utf32)
Dann sollen wir von einer für uns möglichen Vereinfachung keinen Nutzen haben, weil es Sprachgruppen gibt, die davon nicht profitieren können? Dann müsste man ja konsequenterweise utf-8 zu ASCII inkompatibel machen, da die ASCII Kompatibilität den englischsprechenden Programmierern die Arbeit erleichtert.
Zudem werden arabische Programmierer vielleicht auch nach dem Zeichenstamm suchen wollen, mit utf-16 ist das mittels character und Indizierung möglich, mit utf-8 nicht.
Das heißt string[x] funktioniert nur fuer einen kleinen Teil der Welt. Egal mit welchem utf-n.
string[x]-Suche nach BMP-codepoints funktioniert für utf-16 auf der ganzen Welt. Für utf-8 funktioniert sie nirgends.
Die Tatsache das in UTF16 weniger Zeichen mehr als einen Codepoint brauchen, sehe ich als Nachteil. Der Programmierer hat eine geringere Wahrscheinlichkeit, das er selber beim testen eine fehlende multi-codepoint Unterstützung findet. Der BUG wird erst vom Anwender gefunden.
Das ist ein weithergeholtes Argument...
Beim durchschnittlichen Programmierer besteht durchaus auch die Möglichkeit, dass er mit multi-codeunit handling zusätzliche Fehler macht, welche erst die Anwenderin bemerkt.
multi-codepoint Probleme sind von der Codierung unabhängig.