WideString, AnsiString, UTF8String, UCS4String Verwirrung

[mschnell]

Naja, kann man so sehen. Aber das Problem ist genau das gleiche wie bei ANSI und UTF8. Gewisse Chars in UTF8 sind vollständige Zeichen, andere nur Teil eines Codes / einer Sequenz.

Natürlich. Der ANSI-String heisst aber auch ANSIString und verhält sich entsprechend (wie Strings sich eben traditionell verhalten). Der UTF8-String heißt UTF8String und verhält sich nach neuen Algorithmen. Der Widestring hat ein "UTF" im Namen und sollte sich auch nicht so verhalten, dass man auf surrogats achten muss. Und wenn der Typ "String" nun als WideString definiert ist sollte sich Widestring ganz bestimmt wie ein traditioneller String verhalten und nicht wie ein UTF-Ding. Sonst ist das nicht mehr kompatibel zu irgendwas.....

-Michael

[theo]

Natürlich. Der ANSI-String heisst aber auch ANSIString und verhält sich entsprechend (wie Strings sich eben traditionell verhalten). Der UTF8-String heißt UTF8String und verhält sich nach neuen Algorithmen.

Ich glaube das ist ein Missverständnis deinerseits. Der UTF8String "tut" afaik gar nichts. Das ist nur ein AnsiString mit anderem Namen.
Der "verhält" sich nicht. Deshalb muss man ihn auch duch die UTF8... Funktîonen jagen.
Es ist vollkommen wurscht ob deine UTF8 Sequenzen in einem Ansistring oder einem UTF8String liegen.
Das wollte ich auch hier schon sagen: http://www.lazarusforum.de/viewtopic.php?p=24092#p24092" onclick="window.open(this.href);return false; mit
"Auch sollte man die grundlegenden Datentypen nicht mit Codierungen in einen Topf werfen."

UTF8String = type ansistring;

[mschnell]

Der UTF8String "tut" afaik gar nichts. Das ist nur ein AnsiString mit anderem Namen.Der "verhält" sich nicht. Deshalb muss man ihn auch duRch die UTF8... Funktîonen jagen.

Habe ich - wie gesagt - nichts gegen. utf8string ist wie am Namen leicht erkennbar ein neuer Typ (auch wenn es nur ein neuer Name für ANSIString bzw den "alten 8-Bit String ist). Er "verhält" sich also nach einer neu definierten Methode auch wenn das bedeutet, dass sich seine 8-bit-Elemente wie die Character in einem ANSI-String verhalten und über seine utf8-codierten Element (die ja 8, 16, 24 oder 32 bit groß sein können) weiter nichts ausgesagt ist.

Es ist vollkommen wurscht ob deine UTF8 Sequenzen in einem Ansistring oder einem UTF8String liegen.

Klar, habe ich - wie gesagt - ja auch nix gegen einzuwenden.

Gegen Widestrings (= "Strings" im neuen Lazarus) habe ich auch nichts einzuwenden. Wie sie funktionieren ('mal abgesehen von lazy copy, was mit der Codierung nichts zu tun hat) finde ich völlig in Ordnung und die Umstellung des "String" Typs geht auch in Ordnung, weil Widestrings sicherlich in den meisten Anwendungen besser geeignet sind als ANSIstrings. Ich werde vermutlich nie in die Verlegenheit komme, Zeichen verwenden zu wollen, die nicht im 16-Bit UCS2 Code enthalten sind.

Wo ich etwas gegen habe ist, die WideStrings als uft16 kodiert zu bezeichnen. Sie sie es wären, müsste die RTL das auch berücksichtigen und z.B. mit s[3] das dritte utf16 kodierte Zeichen finden, egal ob es ein 16-Bit kodiertes oder ein 32 Bit kodiertes Zeichen ist und egal ob die beiden Zeichen die vorher im Strings stehen mit 16 oder mit 32 Bit kodiert sind, und egal ob am Anfang des Strings ein Kenn-Code steht, der besagt, dass es eine utf16-Zeichenkette ist. Die Length des Strings müsste die Anzahl der utf16-kodierten Zeichen sein. Und ein Widechar müsste 32 Bit speichern, um ein beliebiges utf16 Zeichen aufnehmen zu können.

Wie gesagt, ich brauche das alles nicht und bin mit den ucs16 kodierten WideStrings und WideChars völlig zufrieden. Nur sollte man sie dann auch so nennen.

-Michael

[theo]

Wo ich etwas gegen habe ist, die WideStrings als uft16 kodiert zu bezeichnen.

Aber wer tut das denn?
Ich habe ja gerade gesagt dass ein AnsiString/WideString mit der Codierung erstmal nichts zu tun hat.
Was da drin ist und wie man es interpretiert ist doch eine andere Sache.

Ich kann deiner Begründung schon folgen, wenn du sagst, dass ein WideChar keine Daten über $FFFF halten kann und da für dich der WideString die Summe der WideChar ist, ergo auch ein WideString nicht mehr als UCS-2 können kann.
Mit der selben Begründung könntest du sagen, dass FPC kein UTF8 kann weil es keinen Datentypen fester Länge für einen "Buchstaben" davon gibt.

Aber das hilft uns nicht weiter...

[mschnell]

Mit der selben Begründung könntest du sagen, dass FPC kein UTF8 kann weil es keinen Datentypen fester Länge für einen "Buchstaben" davon gibt.

Klar "kann" es utf8 in ANSI-Strings (im Sinne von speichern). Es kann aber kein utf8 im Sinne von "der Codegenerator erzeugt aus Standard-Operatoren automatisch auf die Eigenschaften von utf8 angepassten Code". Bei ANSI-Strings ("alten" Strings) ist das aber der Fall (wenn der Inhalt als Kette von chars interpretiert wird) , ebenso bei Widestrings ("neuen" Strings), wenn der Inhalt als Kette von (UCS2-kodierten) WideChars interpretiert wird, nicht aber wenn man den Inhalt als utf16 interpretiert.

-Michael

[theo]

Na gut, wie müsste der Compiler denn den UTF8String behandeln?
Als Array of String[4] ? Dann sind wir Speichermässig wieder bei UCS-4.

Wie müsste der Rückgabewert von UTF8String[n] denn sein? Ein UTF8String oder ein Cardinal resp. UCS4Char?

Aber auch wenn der Compiler das intern behandelt, muss er doch auch durch den String rattern, um die Position zu mappen.

Ich sehe hier keine schlaue Lösung für den Compiler.

Ich glaube sowieso dass UTF-8 eher was für's Streamen / Speichern ist. In-Memory ist das "a pain in the ass".
Ich bleibe bei WideString und UCS-2. Allenfalls könnte man noch Surrogat-Paare durch Spaces ersetzen oder sowas.
Mich interessiert das Gedöns oberhalb des BMP nicht.

[Euklid]

Der letzte Begriff im Titel des Threads scheint die Situation wohl am ehesten zu beschreiben

[theo]

Der letzte Begriff im Titel des Threads scheint die Situation wohl am ehesten zu beschreiben

Es gibt gaanz dicke Bücher darüber...

[Euklid]

Ist ja schön, dass es in Lazarus bzw. Pascal von Natur aus einen String-Typ gibt, durch den der Programmierer viel Arbeit abgenommen bekommt. Wenn man zudem noch das Handling von Strings programmieren müsste (wie in einigen anderen Sprachen), gute Nacht!

[mschnell]

Ist ja schön, dass es in Lazarus bzw. Pascal von Natur aus einen String-Typ gibt, durch den der Programmierer viel Arbeit abgenommen bekommt.

Schön wär's, aber es gibt nicht einen String typen, sondern mehrere und bei allen scheint - wenn man z.B. deutsche Umlaute verwendet - simple rtl-Funktionen wie "uppercase()" nicht (d.h. schlechter als in Turbo-Delphi) zu funktionieren (siehe anderer Thread).

-Michael

[theo]

simple rtl-Funktionen wie "uppercase()" nicht (d.h. schlechter als in Turbo-Delphi) zu funktionieren (siehe anderer Thread).

Sei vorsichtig mit solchen Aussagen wenn du dir nicht ganz sicher bist, was du tust.

[mschnell]

Sei vorsichtig mit solchen Aussagen wenn du dir nicht ganz sicher bist, was du tust.

OK, dann ergänze bitte: "bei Default-Einstellungen". Wäre natürlich zu hoffen, dass es Einstellungen gibt, wo es geht.
-Michael

[RSE]

Vielleicht wäre es bei so viel Verwirrung bzw. nötigen Kenntnissen sogar sinnvoll, einen Datentypen zu schaffen, der UTF8 so speichert, dass man leicht auf den x. Buchstaben zugreifen kann und entsprechende Funktionen, um diesen Typen dann mit den Standard-String-Funktionen verwenden zu können. Wenn mal effizient mit Strings gearbeitet werden muss, muss man natürlich wieder wissen, was man tut. Aber für Anfänger und an zeitunkritischen Stellen wär das vielleicht ganz hilfreich. Ich denke da an ein Objekt mit entsprechenden Eigenschaften, die entsprechend geschrieben und gelesen werden können.

[mschnell]

Vielleicht wäre es bei so viel Verwirrung bzw. nötigen Kenntnissen sogar sinnvoll, einen Datentypen zu schaffen, der UTF8 so speichert, dass man leicht auf den x. Buchstaben zugreifen kann

Ist eine gute Idee, wenn man Speicherplatz-Probleme hat und die Ablauf-Geschwindigkeit nicht kritisch ist. UCS2-kodierte Widestrings brauchen zwar mehr Platz funktionieren aber flott und stellen für fast alle Anwendungen jedes relevante Zeichen dar. Deshalb hatte ich ja vermutet, dass String nun = Widestring ist, weil das wohl in 90% der Anwendungen die ideale Lösung ist (zumindest wenn derselbe "layz-copy" algorithmus verwendet wird wie bei "alten" ANSIStrings).

-Michael

[theo]

Vielleicht wäre es bei so viel Verwirrung bzw. nötigen Kenntnissen sogar sinnvoll, einen Datentypen zu schaffen, der UTF8 so speichert, dass man leicht auf den x. Buchstaben zugreifen kann

Hatte ich hier mal kurz aufgeworfen http://www.lazarusforum.de/viewtopic.php?p=24215#p24215" onclick="window.open(this.href);return false;