MSElang, der zukünftige Compiler für MSEide+MSEgui

[mse]

Gut. Der Index funktioniert für UCS-2. Für UTF-16 funktioniert er eben leider nicht... da kann man das Wort Basic Multilingual Plane so oft schreiben wie man will, für UTF-16 funktioniert der Index trotzdem nicht.

Darum habe ich im Deutschen Lazarus Forum auch bestimmt schon mehr als 10 mal geschrieben: bei der Suche nach bekannten Zeichen. Die können bei utf-8 zwischen #$00 und #$7f liegen, bei utf-16 zwischen #$0000 und #$d7ff. Das funktioniert auch wenn sich im utf-8 string mehrbyte codepoints und im utf-16 string surrogate pairs befinden. Ist das nicht deutlich genug?

[mschnell]

Seit wann interessierst du dich für pragmatische Lösungen? :

UTF16 mit entsprechender Doku finde ich pragmatisch. UTF8 ohne ernsthafte Warnung in der Doku in einem Datentyp, der auch noch verwirrender Weise ANSIString heißt, finde ich nicht pragmatisch, eben weil nicht nur Smilies, sondern auch einfache Umlaute nicht gleichzeitig mit explizitem Index auf einen String verwendet werden können.
-Michael

[mschnell]

Suche nach bekannten Zeichen. Die können bei utf-8 zwischen #$00 und #$7f liegen, bei utf-16 zwischen #$0000 und #$d7ff. Das funktioniert auch wenn sich im utf-8 string mehrbyte codepoints und im utf-16 string surrogate pairs befinden. Ist das nicht deutlich genug?

Stimmt, wenn alle beteiligten "Zeichen" in Strings gespeichert sind (pos(), copy(), ...)

Wenn das Zeichen in einem Character-Typ erwartet wird oder gespeichert werden soll, (der natürliche so viele Bits hat, wie ein Code in dem zugehörigen String-Typ), funktioniert das eben nicht.

Das ist bei UTF-8 quasi immer katastrophal, bei UTF-16 fällt es in den meisten praktischen Anwendungen nicht ins Gewicht.

-Michael

[Patito]

Was ihr damit meint ist mir nicht so recht klar. Das ganze klingt vom Anwendungsfall jetzt etwas speziell und etwas anders als das Argument aus meinem ursprünglichen Zitat.

Aber egal. Wenn ich z.B. in Pascal-Quellcode nach einem bekannten ASCII-Keyword suche, ist das in UTF-8 und UTF-16 eine Suche von einem Haufen Bytes in einem anderen Haufen Bytes. So einen klareren Vorteil Richtung UTF-16 kann ich da nicht finden.

UTF-16 ist insgesamt etwas schwergewichtiger (der Haufen ist oft um den Faktor 2 größer), dafür gehen dann eben manche Suchfunktionen einen Tick schneller.
Für mich ist es praktisch so, dass die Operationen, bei denen UTF-16 schlechter ist praktisch immer gemacht werden müssen (Konvertierung beim einlesen + doppelter Speicherverbrauch - doppelt so viele Bytes kopieren + Konvertierung von ASCII zu UTF-16) - und die theoretischen Vorteile von UTF-16 in manchen Algorithmen dagegen dann recht klein aussehen.

[mse]

Stimmt, wenn alle beteiligten "Zeichen" in Strings gespeichert sind (pos(), copy(), ...)

Wenn das Zeichen in einem Character-Typ erwartet wird oder gespeichert werden soll, (der natürliche so viele Bits hat, wie ein Code in dem zugehörigen String-Typ), funktioniert das eben nicht.

Bei *bekannten* Zeichen schon!!!

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

funktioniert in utf-16 immer weil 'ä' < #$d800 ist in utf-8 nie, da 'ä' > #$7f ist. Ist das wirklich so schwierig?

[mschnell]

Bei *bekannten* Zeichen schon!!!

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

funktioniert in utf-16 immer weil 'ä' < #$d800 ist in utf-8 nie, da 'ä' > #$7f ist. Ist das wirklich so schwierig?

Genau das meinte ich doch. Bei UTF16 ist 'ä' ein einzelner code, ein Smilie aber nicht. str1[5] ist - auch wenn es ein ä ist, ein 16Bit "Char".

-Michael

[martin_frb]

Bei *bekannten* Zeichen schon!!!

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

funktioniert in utf-16 immer weil 'ä' < #$d800 ist in utf-8 nie, da 'ä' > #$7f ist. Ist das wirklich so schwierig?

Nur wenn das ä normalisiert ist. ä kann auch als 2 codepoints a und "2 punkte drüber" gespeichert werden.

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)

Das heißt string[x] funktioniert nur fuer einen kleinen Teil der Welt. Egal mit welchem utf-n.

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.

Ausnahme: EIn Program nur fuer Europa and Amerika, mit 100% Garantie, das wirklich nie, irgendwelche Daten (z.b. Namen) mit multicodepoint Zeichen auftreten. Und das alle Zeichen normalisiert sind

[BeniBela]

Bei *bekannten* Zeichen schon!!!

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

funktioniert in utf-16 immer weil 'ä' < #$d800 ist in utf-8 nie, da 'ä' > #$7f ist. Ist das wirklich so schwierig?

Das funktioniert auch bei UTF-8, man muss nur etwas casten

[mse]

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.

[mse]

Das funktioniert auch bei UTF-8, man muss nur etwas casten

Dann zeige mal wie.

[mschnell]

Das heißt string[x] funktioniert nur fuer einen kleinen Teil der Welt.

Aber eben in Europa (inklusive Türkei), USA, Südamerika und Australien. Genau das meinte ich mit "pragmatisch aber nicht wirklich Unicode-aware" . (Wie ist es mit Hebräisch?)
-Michael

[BeniBela]

Das funktioniert auch bei UTF-8, man muss nur etwas casten

Dann zeige mal wie.

Code: Alles auswählen

 
if PWord(@s[5])^ = PWord(@'ä'[1])^ then 
 

oder

Code: Alles auswählen

 
if PWord(@s[5])^ = $A4C3 then 
 

[martin_frb]

Ja utf16 in in Sachen "Codepoint" einfacher.

Aber daraus eine Vereinfachung, oder einen Nutzen abzuleiten ist IMHO weit hergeholt (Genaugenomen: Das Gegenteil. Auf einen nahen Raum begrenzt, den Englisch/Europäischen Sprachraum).

Die meisten Programmierer sind doch an Zeichen interessiert. Einige wissen nicht mal was ein Codepoint ist.
Und in Sachen Zeichen, ist UTf16 nicht besser als UTF8. Es erweckt lediglich *oberflächlich* den Eindruck, das es besser wäre.

In Sachen normalisiert vs nicht normalisiert. Sobald Input von außen vorliegt, kann der nicht normalisiert sein.
(Ja die Lazarus IDE handelt das auch nicht, aber UTF16 wuerde das auch nicht fixen)

Und mit Utf8 ist es ggf leichter zu fixen. In UTF8 muss bereits der Datentyp fuer einen Codepoint multi-byte sein, und oft wird hier ein String verwendet. In Utf16 wuerde das ein WideChar sein.
In einem String kann man natürlich auch eine Codepoint Sequenz (ein Zeichen) speichern. In einem WideChar nicht.

-----
Mir ist es ja egal, ob Du utf8 oder UTF16 verwendest. Aber ich habe bisher kein wirklich Argument fuer UTF16 gesehen. Und wenn es eins gibt, wuerde ich es gerne mal kennen.

Das heisst eins gibt es, und ich kenne es:
In UTF8 sind die meisten europäischen Texte weniger Speicherplatz beduerftigt.
IN UTF16 gilt das fuer nicht europäischen Texte, da in anderen Sprachen UTF8 codepoints ggf 3 oder 4 bytes sind, und UTF16 Codepoints nur 2 bytes.

[mschnell]

>>> if PWord(@s[5])^ = PWord(@'ä'[1])^ then

Igitt. Warum dann nicht gleich alles in Assembler schreiben ?

-Michael

[mse]

Code: Alles auswählen

 
if PWord(@s[5])^ = PWord(@'ä'[1])^ then 
 

Das geht mit {$codepage utf8} vermutlich nicht und läuft für ASCII Zeichen schief.

Code: Alles auswählen

 
if PWord(@s[5])^ = $A4C3 then 
 

Und was ist angenehmer zu programmieren und zu lesen

Code: Alles auswählen

 
 if PWord(@s[5])^ = $A4C3 then 
 

oder

Code: Alles auswählen

 
 if s[5] = 'ä' then 
 

?