WideString, AnsiString, UTF8String, UCS4String Verwirrung

[mse]

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.

Oder intern nicht mit utf-8 codierten ansistrings, sondern mit widestrings arbeiten. Siehe MSEgui. Übrigens hatte ich MSEgui mal für 2 Monate auf utf-8 umgestellt, weil FPC mit widestrings zu grosse Probleme machte. Als ich erlebt habe, was utf-8 für ein Theater ist, kehrte ich zu widestrings zurück und schrieb so lange bug reports, bis FPC widestrings funktionierten...

[mse]

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).

FPC wird in zukünftigen Versionen einen referenz gezählten widestring auf allen Plattformen erhalten, der Typ nennt sich UnicodeString und ist in FPC trunk bereits implementiert.

[RSE]

Ich arbeite im Modus {$mode objfpc}{$H+}, und somit ist String bei mir ANSIString. Da ich bei meinem aktuellen Projekt sehr wenig an Strings herummanipuliere, ist das kein größeres Problem und somit halte ich ANSIString für mein Projekt auch für passend. Mein Vorschlag gilt allerdings weniger Speicherplatzproblemen als vielmehr der Vorbeugung von Problemen bei Anfängern und der Vereinfachung von Konvertierungen. Ich stelle mir dieses Objektinterface etwa so vor:

Code: Alles auswählen

TStr = class(TObject)
  ...
public
  property UTF8String: String read GetUTF8String write SetUTF8String;
  property UTF16String: String read GetUTF16String write SetUTF16String;
  property UTF32String: String read GetUTF32String write SetUTF32String;
  property UTF8ANSIString: ANSIString read GetUTF8ANSIString write SetUTF8ANSIString;
  property UTF16ANSIString: ANSIString read GetUTF16ANSIString write SetUTF16ANSIString;
  property UTF32ANSIString: ANSIString read GetUTF32ANSIString write SetUTF32ANSIString;
  property UTF8WString: WideString read GetUTF8WString write SetUTF8WString;
  property UTF16WString: WideString read GetUTF16WString write SetUTF16WString;
  property UTF32WString: WideString read GetUTF32WString write SetUTF32WString;
  function GetCharacterFromPosition(APosition: Cardinal): ANSIString;  // gibt den Buchstaben an der Position APosition im Wort zurück
  function CountCharacters: Cardinal;  // Zählt die Anzahl der Buchstaben
end;

Intern sollte die Umwandlung jeweils nur nach Notwendigkeit erfolgen, also auf Geschwindigkeit optimiert, nicht auf Speicherverbrauch. Dieses Konstrukt regt dazu an, sich mit den verschiedenen Codierungen auseinanderzusetzen und bietet zudem eine komfortable Speicher- und Umwandlungsmöglichkeit. Der Overhead sollte ertragbar bleiben, da ja in einer exe der Code für die Funktionen für jede Klasse nur 1x gespeichert wird, lediglich für die Felder wird für jede Instanz Speicher reserviert, und der Speicherplatzbedarf für die Felder dürfte in diesem Fall ziemlich gering ausfallen . Man könnte die Speicherung z.B. in einem Packed Record organisieren, in dem entweder ein ANSIString, ein WideString oder ein PChar steht (ich hoffe, ich habe das mit den Packed Records nicht falsch verstanden ).

[theo]

Deine Typen verstehe ich nicht.
Ein String ist ja normalerweise ein AnsiString. Pascal Strings brauchts hier wohl eher nicht.
Ein UTF16String und ein UTF32String passen nicht in einen String (AnsiString);

UTF8WString macht keinen Sinn.
UTF32WString ist kein WideString sondern ein 32 bit String (UCS4String).

Oder verstehe ich da was falsch?

[mschnell]

FPC wird in zukünftigen Versionen einen referenz gezählten widestring auf allen Plattformen erhalten, der Typ nennt sich UnicodeString und ist in FPC trunk bereits implementiert.

UniCodeString hört sich gut an. UCS2 ist ja auch UniCode

-Michael

[theo]

UniCodeString hört sich gut an. UCS2 ist ja auch UniCode

Tut aber nichts zur Sache, das bleibt ein WideString und Lazarus hat sich für UTF8 entschieden.
Übrigens ist alles Unicode auch UTF-8, UCS4 etc.

[RSE]

Deine Typen verstehe ich nicht.
Ein String ist ja normalerweise ein AnsiString. Pascal Strings brauchts hier wohl eher nicht.
Ein UTF16String und ein UTF32String passen nicht in einen String (AnsiString);

UTF8WString macht keinen Sinn.
UTF32WString ist kein WideString sondern ein 32 bit String (UCS4String).

Oder verstehe ich da was falsch?

Wenn ich das richtig verstanden habe, so ist die Standardeinstellung in Lazarus für String jetzt WideString. Bei mir ist es lediglich durch die Compilerschalter noch AnsiString. Lazarus arbeitet also mit UTF-8 auf WideStrings . Der Sinn ist mir momentan auch nicht so 100% klar. UTF16 und UTF32 könnten schon in AnsiString gespeichert werden, wenn jeweils 2 bzw. 4 Ansi-Zeichen für ein UTF-16 bzw. UTF-32 Zeichen verbraucht würden. Genau das ist ja die Trennung von Zeichensatz und Speicherung derselben. Und ich finde, dass so ein Datentyp, wenn er schon existiert, auch alle Möglichkeiten zur Verfügung stellen sollte.

[theo]

Wenn ich das richtig verstanden habe, so ist die Standardeinstellung in Lazarus für String jetzt WideString.

Falsch

Lazarus arbeitet also mit UTF-8 auf WideStrings .

Blödsinn UTF-8 ist für SingleByte Strings(AnsiString) nicht für DoubleByte Strings (WideString)

UTF16 und UTF32 könnten schon in AnsiString gespeichert werden, wenn jeweils 2 bzw. 4 Ansi-Zeichen für ein UTF-16 bzw. UTF-32 Zeichen verbraucht würden.

Ist aber nicht so. Nur UTF-8 kommt in einen AnsiString. UTF16 in einen WideString und UCS4 in einen UCS4String.

Alles Klar?

[mse]

Wenn ich das richtig verstanden habe, so ist die Standardeinstellung in Lazarus für String jetzt WideString. Bei mir ist es lediglich durch die Compilerschalter noch AnsiString. Lazarus arbeitet also mit UTF-8 auf WideStrings

Nein, nach wie vor gilt string=ansistring. Lazarus speichert Quelltext standardmässig in utf-8, die LCL erwartet und liefert ansistrings, welche utf-8 codierten Text enthalten. Alles klar?

[mse]

Alles Klar?

Wenn das keine Gedankenübertragung ist!

[mschnell]

function GetCharacterFromPosition(APosition: Cardinal): ANSIString; // gibt den Buchstaben an der Position APosition im Wort zurück

Warm keine array-property ?

function CountCharacters: Cardinal; // Zählt die Anzahl der Buchstaben

Warum nicht property count: Cardinal: read GetCount;

Man könnte die Speicherung z.B. in einem Packed Record organisieren, in dem entweder ein ANSIString, ein WideString oder ein PChar steht (ich hoffe, ich habe das mit den Packed Records nicht falsch verstanden ).

Warum nicht entweder UTF8: sehr langsam, wenig Speicher oder UCS-4, schnell, viel Speicher ?

-Michael

[mschnell]

Tut aber nichts zur Sache, das bleibt ein WideString und Lazarus hat sich für UTF8 entschieden.

Widestring kann man vielleicht als alles mögliche interpretieren, aber nicht als utf-8.

-Michael

[theo]

Wenn das keine Gedankenübertragung ist!

Das sagt man meistens, wenn es scheint, dass alles unklar ist.

[theo]

Tut aber nichts zur Sache, das bleibt ein WideString und Lazarus hat sich für UTF8 entschieden.

Widestring kann man vielleicht als alles mögliche interpretieren, aber nicht als utf-8.

Kann dir nicht folgen was du damit meinst.

[mschnell]

Wenn ich das richtig verstanden habe, so ist die Standardeinstellung in Lazarus für String jetzt WideString.

Das hatte ich auch gedacht, scheint sich aber als Irrtum herausgestellt zu haben. In meinem Beispiel, das ich ohne Veränderung irgendwelcher Einstellungen fabriziert habe ist String irgendeine 8-bit Kodierung und Uppercase für String ruft SYSUTILS_UPPERCASE$ANSISTRING$$ANSISTRING auf.
Genausowenig ist die Sourcecode-Datei utf-8 kodiert, obwohl die Einstellung (rechte Maustaste im Editor...) das behauptet. Die Datei ist eindeutig UCS2-Kodiert.

Und ich finde, dass so ein Datentyp, wenn er schon existiert, auch alle Möglichkeiten zur Verfügung stellen sollte.

Da bin ich ganz Deiner Meinung. Und eine Beschreibung, was diese Möglichkeiten genau sind und was genau passieren soll !

-Michael