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

[mse]

Ich würde allerdings uncodierte 8-Bit Strings als allgemein verwendbaren Datenspeicher sehr vermissen.

Ich auch. Manchmal habe ich wirklich das Gefühl, dass du nicht so genau liest, was ich schreibe, nichts für ungut.

[mschnell]

Ich auch.

Weiß ich.
Aber im "MSElang" Prospekt steht nichts davon sondern dass alles möglichst wenig überladen werden soll. Und ich weiß aus vielen Diskussionen, dass Du für Zeichenketten UTF16 bevorzugst. Da könnten uncodierte 8-Bit Strings als weniger wichtig erkannt werden.

-Michael

[mse]

Ich habe den Text angepasst.

[mschnell]

Ich habe den Text angepasst.

"8-bit strings will not be "codepage aware". Ist immer noch ziemlich uneindeutig. (Es ist natürlich in der frühen Projekt-Phase auch noch nicht nötig, das genau festzulegen.)

Ich vermute Du meinst :
- Druckbare/anzeigbare Text-Strings sind immer UTF-16 kodiert, Codepoints > 2^15 sind erlaubt, werden aber vom System nicht explizit unterstützt. Die implizite Zeichen-Zählung in diesen Strings ist in 16-Bit Worden organisiert.
- Für allgemeine Datenspeicherung wird zusätzlich ein Byte-String Typ ohne nativ interpretierbare Kodierung definiert. Die implizite Zeichen-Zählung in diesen Strings ist in 8-Bit ytes organisiert. Byte-Strings könnnen ANSI-Kodierte Daten enthalten. Die "Codepage" ist dem Benutzer freigestellt und dem System nicht bekannt. Um diese Strings anzuzeigen, müssen explizit RTL-Funktionen aufgerufen werden, die eine Umwandling in 16 Bit Unicode Strings vornehmen. Dasselbe gilt wenn UTF-8 codierte Daten in solchen Strings gespeichert wird..

(Ich hoffe die Bezeichnung "ANSI" taucht außer in explizit aufrufbaren RTL-Funktionen zum Unkodieren nirgends auf !!!! )

Das halte ich für einen sehr pragmatischen Ansatz. Dadurch dass 8-Bit Strings nicht direkt anzeigbar sind wird die "ANSI-Codepage" und UTF-8-Zeichenzählung"s - Verwirrung minimiert.

Unicode-Experten werden sich grausen.

-Michael

[mse]

Ich zitiere von hier:
http://www.lazarusforum.de/viewtopic.php?f=53&t=7313

Ich finde die FPC 2.6 Lösung Ideal, ein utf-16 string für reinen Text der für praktisch alle Anwendungen die Zeichen-Extraktion mittels Index zulässt und ein 8-Bit string der in der Regel Text in der Systemcodierung enthält, aber auch binäre Daten oder beliebige 8-bit-Codierungen enthalten kann, mit automatischer Umwandlung zwischen Systemcodierung <> utf-16. Wobei man über letzteres bereits diskutieren kann. Ich bin noch nicht sicher, ob das im MSEcompiler implementiert wird.

Also:
Reiner Text wird in UnicodeString gespeichert. UnicodeString ist utf-16 codiert.
Für 8-bit Text und/oder Daten gibt es weitere String Typen, die Delphi 7 "AnsiString", auch shortstrings gedenke ich beizubehalten.
Ich würde gerne für Arrays und Strings einheitlich nullbasierende Indizes verwenden.

Code: Alles auswählen

array[0..9] of integer;

wird zu

Code: Alles auswählen

array[10] of integer;

[mse]

Codepoints > 2^15 sind erlaubt, werden aber vom System nicht explizit unterstützt.

Was meinst du damit? Was utf-16 bedeutet ist doch klar? Die Indizierung von UnicodeString meint "code units" = 16bit word. Was meinst du mit "anzeigbar"? Übrigens erlaubt utf-16 auch codepoints > 2^15 in einem code unit, die 2-Wort codepoints beginnen erst bei $d800.

[mschnell]

Reiner Text wird in UnicodeString gespeichert. UnicodeString ist utf-16 codiert.

finde ich - wie gesagt - ausgesprochen pragmatisch.

Für 8-bit Text und/oder Daten gibt es weitere String Typen, die Delphi 7 "AnsiString", auch shortstrings gedenke ich beizubehalten.

Ich halte die short strings für absolut verzichtbar. Ich würde den Begriff "ANSI" unbedingt vermeide, weil der User darin auch was anderes speichern kann und es dem Compiler egal ist.

Ich würde gerne für Arrays und Strings einheitlich nullbasierende Indizes verwenden.

Ich finde die "base 1" Indizierung für Strings und die "base irgenwas" Indizierung für Arrays auch völlig idiotisch. Wenn es Dir nichts macht, dass etwas anderes kompatibel zu nichts wäre, Ich habe persönlich nichts gegen Indizierung grundsätzlich base 0.
-Michael

[mschnell]

Was meinst du damit? Was utf-16 bedeutet ist doch klar?

Natürlich. Ich meine das System kümmert sich nicht um die potentielle Zusammenfassung von mehreren 16-Codes zu "druckbaren Zeichen." Der Index auf Strings und pos() etc läuft in 16-Bit Codes. Das muss dem Anwender klar sein.

-Michael

[Patito]

Ich zitiere von hier:

Ich finde die FPC 2.6 Lösung Ideal, ein utf-16 string für reinen Text der für praktisch alle Anwendungen die Zeichen-Extraktion mittels Index zulässt und ein 8-Bit string der in der Regel Text in der Systemcodierung enthält, aber auch binäre Daten oder beliebige 8-bit-Codierungen enthalten kann, mit automatischer Umwandlung zwischen Systemcodierung <> utf-16. Wobei man über letzteres bereits diskutieren kann. Ich bin noch nicht sicher, ob das im MSEcompiler implementiert wird.

Also:
Reiner Text wird in UnicodeString gespeichert. UnicodeString ist utf-16 codiert.

Das Problem damit ist eben nur, dass diese Zeichen-Extraktion mittels Index bei UTF-16 so nicht funktioniert. (Sobald z.B. Smileys im Text sind ...)
http://www.delphitools.info/2013/10/11/ ... iacritics/

UnicodeString als Synonym für UTF-16 zu nehmen ist von der Namensgebung irgendwie falsch. An manchen Stellen mag ein UTF-16 String zwar brauchbar sein, und man sollte so einen Typ irgendwo implementieren, aber technologisch ist UTF-16 doch die Unicode Encoding, die am wenigsten Sinn ergiebt. UTF-32 (als direkte Liste von Unicode-Code-Point-Integern) hätte die Bezeichnung UnicodeString wohl am ehesten verdient.

Ansonsten:
http://www.utf8everywhere.org/

[mse]

Das Problem damit ist eben nur, dass diese Zeichen-Extraktion mittels Index bei UTF-16 so nicht funktioniert. (Sobald z.B. Smileys im Text sind ...)

Solange man nach bekannten Zeichen sucht funktioniert das schon. Mit utf-16 mit codepoints von #$0000 bis #$d7ff, das heisst die gesamte Basic Multilingual Plane, mit utf-8 #$00 bis #$7f das heisst ASCII.

Ansonsten:
http://www.utf8everywhere.org/

Für mich ist das Quatsch. utf-8 ist am besten geeignet für den Datenaustausch, MSEgui benutzt für Dateien und Inter-Prozess-Kommunikation nach Möglichkeit utf-8, utf-8 ist aber sicher nicht überall die geeignetste Codierung.

[Patito]

Solange man nach bekannten Zeichen sucht funktioniert das schon. Mit utf-16 mit codepoints von #$0000 bis #$d7ff, das heisst die gesamte Basic Multilingual Plane, mit utf-8 #$00 bis #$7f das heisst ASCII.

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.

Ansonsten:
http://www.utf8everywhere.org/

Für mich ist das Quatsch. utf-8 ist am besten geeignet für den Datenaustausch, MSEgui benutzt für Dateien und Inter-Prozess-Kommunikation nach Möglichkeit utf-8, utf-8 ist aber sicher nicht überall die geeignetste Codierung.

Es gibt da recht konkrete Argumente für UTF-8. Das pauschal als Quatsch abzutun ist etwas gewagt. Ein wirkliches Argument, das UTF-16 intern irgendwie besser wäre hab ich aber noch nicht gesehen. Dein Argument (einfache Zeichen-Extraktion mittels Index) funktioniert bei UTF-16 einfach nicht, da UTF-16 eben kein UCS-2 ist.

[mschnell]

UnicodeString als Synonym für UTF-16 zu nehmen ist von der Namensgebung irgendwie falsch.

Ich bin auch für eine ehrliche Namensgebung also "UTF16String" und "ByteString".

Der entsprechende Character sollte dann "UTF16Char" bzw "Byte" heißen.

Eine Namensgebung mit "Unicode" oder "ANSI" finde ich hochgradig verwirrend, weil weder Unicode noch ANSI ohne zusätzliche Angabe eindeutig spezifiziert ist. ("String", "ANSIString" und "UnicodeString" gehen ehrlicherweise nur bei "code aware" String Typen).

Ich würde in jedem Fall auch komplett neue Namen nehmen und die überfrachteten Namen aus Delphi und FPC (wie "String", ANSIString, ..." komplett vermeiden. Wer ein Programm portiert kann leicht eine Zeile

{$ifdef MSElang} Type String = UTF16String; ...

einbauen.

Dadurch kann auch mse später bei Bedarf immer noch Delphi oder fpc kompatible String Typen zusätzlich implementieren.

-Michael

[mschnell]

Ein wirkliches Argument, das UTF-16 intern irgendwie besser wäre hab ich aber noch nicht gesehen.

Ist bei Microsoft aber die generelle Vorgabe. Die mögen zwar problematisch sein, aber ganz blöd sind die auch nicht.

MSE's Argument (einfache Zeichen-Extraktion mittels Index) funktioniert bei UTF-16 einfach nicht, da UTF-16 eben kein UCS-2 ist.

Stimmt, und muss deshalb in der Doku dick vermerkt werden. Aber da es in Europa in den allermeisten Praxis-Fällen funktioniert, ist es eine recht pragmatische Lösung. (Kaum jemand benutzt gleichzeitig Smilies und explizite String-Indizes.)

-Michael

[Patito]

Ist bei Microsoft aber die generelle Vorgabe. Die mögen zwar problematisch sein, aber ganz blöd sind die auch nicht.

Denkst Du...

Aber da es in Europa in den allermeisten Praxis-Fällen funktioniert, ist es eine recht pragmatische Lösung. (Kaum jemand benutzt gleichzeitig Smilies und explizite String-Indizes.)

Sich darauf zu verlassen, dass man nur UCS-2 braucht ist aber nicht pragmatisch sondern eher eine Sollbruchstelle. Unicode ist ein Standard, der in Bewegung ist. Es gibt ständig Updates der Character-Liste und die werden nicht gerade versuchen möglicst unpopuläre Buchstaben hinzuzufügen nur damit halbgarer alter Code nicht auseinanderfällt. Die neuen Emoticons sind in manchen Bereichen schon populärer als so manches seltene ASCII-Zeichen...

[theo]

Aber da es in Europa in den allermeisten Praxis-Fällen funktioniert, ist es eine recht pragmatische Lösung.

Seit wann interessierst du dich für pragmatische Lösungen?
Dachte immer dir geht es nur ums rumeiern.