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

[mse]

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.

Dann zeige doch bitte wie gross der Anteil an Umlautproblem-Themen im Deutschen Lazarusforum ist, welche ebenfalls bestehen würden, wenn Lazarus UnicodeString statt "utf-8 in AnsiString ohne BOM oder {$codepage utf8} oder -Fcutf8" verwenden würde. Ich vermute der Anteil ist gering.

[Patito]

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?

In UTF-16 muss man prüfen, ob an der Speicherstelle str1[5] die nächsten 2 Bytes 00e4 sind
bei UTF-8 muss man prüfen, ob die nächsten 2 Bytes c3a4 sind.
Von den Operationen her ist das fast identisch (die Buffer-Overflow-Prüfung ist nicht ganz identisch, aber sehr sehr ähnlich).
Wobei man bei UTF-16 - Algorithmen im allgemeinen eher mehr Ärger mit Buffer-Enden hat, da normalerweise
weniger in die Buffer passt.

Das Problem von Pascal hier ist eventuell, dass die Konstanten nicht ordentlich auf UTF-8 bzw. UTF-16 typisiert sind,
es gibt keine schöne Syntax dafür, und der Compiler rät einfach zuviel. (daher vielleicht auch die Ideen mit den Casts, mit
denen man die Raterei eventuell aushebeln kann).
Die Konstanten sind aber ein Problem der Pascal-Syntax - von einem Vorteil von UTF-16 ist da weit und breit nichts zu sehen.

[mschnell]

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

In diesem Thread geht es momentan ja gerade darum die Datentypen "???String" und den passenden "???Char" für den neuen Compiler zu definieren. Das müssen nicht "String" und "Char" sein wie aus irgendeiner Delphi oder fpc-Version bekannt (in den unterschiedlichen Versionen sind die ja teilweise unter der Hand umdefiniert worden).

-Michael

[mschnell]

Das Problem von Pascal hier ist eventuell, dass die Konstanten nicht ordentlich auf UTF-8 bzw. UTF-16 typisiert sind,
es gibt keine schöne Syntax dafür, und der Compiler rät einfach zuviel.

Daher mein Vorschlag, dass echte Texte (also auch Konstanten) immer UTF16 sind, und 8 - Bit Strings immer als "RawByte" behandelt werden, die nicht direkt anzeigbar und auch nicht automatisch auf UTF16Strings konvertierbar sind. Konvertierung ist nur durch den expliziten Aufruf von RTL-Funktionen möglich, bei denen die gewünschte Kodierung explizit angegeben wird (als Funktions-Name oder als Argument).

Das ist meiner Ansicht nach die einzige pragmatisch sinnvolle Alternative zu einer ordentlichen (!!) Implementierung von "Code Aware" Strings um Unicode zu ermöglichen.

-Michael

[mse]

MSElang soll ermöglichen, hocheffizienten Code zu schreiben. Wenn man innerhalb der BMP zur Zeichendarstellung mit WideChar arbeiten kann statt mit String arbeiten zu müssen, ist dies ein Vorteil.
@mschnell:
Das sehe ich auch so.

[martin_frb]

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.

Dann zeige doch bitte wie gross der Anteil an Umlautproblem-Themen im Deutschen Lazarusforum ist, welche ebenfalls bestehen würden, wenn Lazarus UnicodeString statt "utf-8 in AnsiString ohne BOM oder {$codepage utf8} oder -Fcutf8" verwenden würde. Ich vermute der Anteil ist gering.

Das ist doch genau der Punkt.

In UTF16 tritt de Fehler seltener (bei weniger Zeichen/Codepoints) auf. Die meisten Leute bemerken den Fehler bei solchen Zeichen/Codepoints die in UTF16 den Fehler nicht bemerkbar machen.

Nur:
Der Fehler ist deswegen mit UTF16 NICHT behoben. Er existiert noch. Er ist nur besser versteckt.
UTF16 behebt den Fehler nicht, sondern versteckt in nur (in vielen Faellen).

In my (very personal) Opinion:
Es ist NIE gut einen Fehler zu verstecken, statt ihn zu beheben. (Auch nicht fuer den blutigsten Anfaenger)

[martin_frb]

MSElang soll ermöglichen, hocheffizienten Code zu schreiben. Wenn man innerhalb der BMP zur Zeichendarstellung mit WideChar arbeiten kann statt mit String arbeiten zu müssen, ist dies ein Vorteil.
@mschnell:
Das sehe ich auch so.

Wie gesagt, ich will hier niemand überzeugen. Weder fuer noch gegen UTF8/16
Ich wuerde nur gern die Motivation fuer utf16 verstehen.

Wenn der Anwender sich im klaren ist, das er unvollständiges/Fehlerhaftes utf handling programmiert, dann ist das OK.

Das Risiko das der Fehler sich auswirkt, ist ja in utf16 geringer. Wer das Rest Risiko akzeptieren will, kann das tun.

Ich denke nur, das in UTF16 weniger Programmierer überhaupt erst erkennen, das es dieses Risiko gibt

[mse]

Ich denke nur, das in UTF16 weniger Programmierer überhaupt erst erkennen, das es dieses Risiko gibt

Dann nochmals, in welchen Themen im Deutschen Lazarusforum mit Umlautproblemen würden die Programmierer ein Risiko eingehen, wenn Lazarus UnicodeString statt "utf-8 in AnsiString ohne BOM oder {$codepage utf8} oder -Fcutf8" verwenden würde? Wo liegt bei

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

das Risiko?

[mschnell]

Es ist NIE gut einen Fehler zu verstecken, statt ihn zu beheben. (Auch nicht fuer den blutigsten Anfaenger)

Deshalb habe ich schon ganz zu Anfang darauf hingewiesen, dass das Verhalten der Strings ordentlich dokumentiert werden muss und dabei auf eventuelle Probleme hingewiesen wird.

-Michael

[mschnell]

Wo liegt bei

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

das Risiko?

Wenn aus irgendwelchen obskuren Gründen das ä im String ein zusammengesetzter UTF-16 Code ist (a + Pünktle drüber).

Außerdem: macht man

Code: Alles auswählen

 
if str1[5] = smily then begin
 

mit einer Variable smily, die der passende (UTF16) Character-Typ ist und versucht vorher auf smily etwas zuzuweisen, geht das schief, wenn es ein zusammengesetzter UTF16 Code ist, was bei einem Smily sicher, aber auch bei einem ä möglich ist.

Das Problem ist also noch mehr der Char-Type als der String-Typ.

(wird in meinen Anwendungen vermutlich nie vorkommen.)
-Michael

[mse]

Wenn aus irgendwelchen obskuren Gründen das ä im String ein zusammengesetzter UTF-16 Code ist (a + Pünktle drüber).

Das ist unabhängig davon, ob str1 in utf-8 oder utf16 ist. Zudem wird nicht nach "a+Pünktle drüber" gesucht sondern nach 'ä'.

Außerdem: macht man

Code: Alles auswählen

 
if str1[5] = smily then begin
 

Ich nehme an <smily> ist nicht in der BMP. Dann reklamiert der Compiler für eine '<smily>' Konstante.

mit einer Variable smily, die der passende (UTF16) Character-Typ ist und versucht vorher auf smily etwas zuzuweisen, geht das schief, wenn es ein zusammengesetzter UTF16 Code ist,

Auch hier reklamiert der compiler. An ein UnicodeChar kann kein UnicodeString zugewiesen werden. Zudem handelt es sich ja um die Suche nach *bekannten* Zeichen (war das jetzt das 15.mal?)

[mschnell]

Das ist unabhängig davon, ob str1 in utf-8 oder utf16 ist.

.. und auch in UTF32 / UC4

Absolut korrekt. Das ist ein allgemeines Unicode Problem:

Sind die beiden Strings "ä" und "a plus Pünktle" gleich, obwohl sie (in jeder Codierung, sie ich kenne) unterschiedlich lang sind. ???

Wer sich auf zusammengesetzte Zeichen einlässt, muss wissen, was er tut. Ein Anfänger, dem das passiert ist mit Mitteln der Sprache wohl nicht zu helfen.

-Michael

[Patito]

Dann nochmals, in welchen Themen im Deutschen Lazarusforum mit Umlautproblemen würden die Programmierer ein Risiko eingehen, wenn Lazarus UnicodeString statt "utf-8 in AnsiString ohne BOM oder {$codepage utf8} oder -Fcutf8" verwenden würde?

Wenn man einen risikofreien anfängerfreundlichen Stringtyp haben will, wäre wohl UTF-32 die richtige Wahl. UTF-16 funktioniert für Texte mit manchen Smylies nicht so wie es ein Anfänger erwarten würde.

Ich denke UTF-16 ist für Anfänger nur scheinbar besser als UTF-8 (weniger sichtbar verbuggt) - und für Experten ist es schlecht.

Wie bereits erwähnt, passt auf UTF-32 die Bezeichnung "UnicodeString" wesentlich besser. Man hätte dann auch einen Character Typ, der auch das bedeutet was man von ihm denkt.

Soweit ich sehe sieht es so aus:
- Leute, die es einfach haben wollen benutzen UTF-32
- Leute, die es effizient haben wollen benutzen UTF-8
- Leute, die sich gerne mit der Windows-API unterhalten oder gerne halb-verbuggten Code schreiben nehmen UTF-16.

[mschnell]

Wie bereits erwähnt, passt auf UTF-32 die Bezeichnung "UnicodeString" wesentlich besser. Man hätte dann auch einen Character Typ, der auch das bedeutet was man von ihm denkt.

Nee "UnicodeString" sollte sich nur ein Code aware String-Typ nennen dürfen, der in jeder Kodierung korrekt arbeitet. Fest codierte Strings sollten ehrlicherweise auch so heißen: "UTF8String", "UTF16String", "UTF32String"

- Leute, die sich gerne mit der Windows-API unterhalten oder gerne halb-verbuggten Code schreiben nehmen UTF-16.

Blödsinn !

Betriebssystem-API Aufrufe sind bei fast allen Anwendungen zeitlich so selten, und die Strings i.A. so kurz, dass das ein Umcodieren an dieser Stelle kaum auffällt.

Die diskutierten Probleme treten bei allen Codierungs-Arten auf. Man kann nur Platz- und Performance-Verschwendung gegen die Wahrscheinlichkeit, dass es einen trifft, austartieren. Und dabei ist UTF-16 - je nach Geschmack - ein relatives Optimum. UTF32 natürlich auch. UTF-8 ist nur optimal, wenn es hauptsächlich auf minimalen Platzbedarf ankommt, man aber unbedingt (warum auch immer) Unicode machen möchte, obwohl lokale-abhängiges 8 Bit ANSI eigentlich alle Anforderungen erfüllt.

-Michael

[martin_frb]

Ich denke nur, das in UTF16 weniger Programmierer überhaupt erst erkennen, das es dieses Risiko gibt

Dann nochmals, in welchen Themen im Deutschen Lazarusforum mit Umlautproblemen würden die Programmierer ein Risiko eingehen, wenn Lazarus UnicodeString statt "utf-8 in AnsiString ohne BOM oder {$codepage utf8} oder -Fcutf8" verwenden würde? Wo liegt bei

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

das Risiko?

Nochmals:
Die meisten Probleme die Leute mit UTF8 posten, , wuerden Sie unter UTF16 nicht bemerken.

Das ist korrekt. Und das scheint ja auch der Hintergrund deiner Referenz zu den "Problemen im Forum"?

Dann bleibt die Frage:
Die Probleme entstehen, weil der Code fehlerhaft ist. Wenn nun entsprechender Code mit UTF16 geschrieben wird, ist er dann Fehlerfrei?

Ich sage NEIN.

ABER, das haengt davon ab, wie man den Fehler interpretiert>

Wenn ein Programmierer (in UTF8 oder 16) schreibt

Code: Alles auswählen

 
if str1[5] = 'ä' then begin
 

Was will er eigentlich das sein Programm machen soll?
A) Testen auf den Buchstaben 'ä'
B) Testen auf den CodePoint fuer die normalisierte Repräsentation von 'ä'

Wenn er (B) will (und das setzt voraus, er kennt den Unterschied zwischen A und B), also wenn er B will, dann hast du Recht, UTF 16 loest das Problem.

Wenn er A will (und das beinhaltet "wenn er den unterschied zwischen A und B NICHT kennt; denn B kann nur wollen wer weiss, das es B gibt, und wer das weiss kennt auch den Unterschied). Also wenn er A will, dann hilft im UTF16 eben nicht. [1]

Und, wenn er A will, weil er eben den Unterschied nicht kennt, dann ist UTF 16 gar nicht hilfreich. Denn UTF 16 versteckt den Fehler, und laesst Ihn in dem Glauben, er habe die korrekte Loesung fuer A. Hat er aber nicht.
Mit UTF8 kriegt er nen Fehler. Er wird dann fragen oder googeln. Er hat ein Chance sein wissen zu erweitern (Ob er es tut, und ob er es ausreichend erweitert, ist natuerlich auch in diesem Fall nicht garantiert).

Also
UTF8: Fehler, dann Chance wissen zu erlangen
UTF16: Meist kein Fehler [1], daher auch keine Chance Wissen zu erlangen.

[1] Weil wenn er zum Beispiel texte aus Dateien oder Datenbanken oder Webseiten nach 'ä' durchucht, wird irgendwann mal ein Text dabei sein in dem das 'ä' NICHT normalisiert ist.

--------------------
Bleibt als letztes:

Viele Programmierer die den Unterschied zwischen A und B kennen, entscheiden sich dann eh dafuer, das Problem mit nicht normalisierten Zeichen zu ignorieren.

Wenn sich der Programmierer dafuer entscheidet, dann ist UTF16 wieder besser.
Aber dafuer muss er eben erst den unterschied kennen.....

Und: Viele != Alle