WideString, AnsiString, UTF8String, UCS4String Verwirrung

[theo]

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 !

Ich kann diesem Argument einfach nicht folgen (btw: Von welchem Datentyp sprecht ihr überhaupt ?)

Was hat denn z.B ein Integer oder ein AnsiString für "Möglichkeiten" und Vorschriften was passieren soll?
Es sind doch die Funktionen, die man darauf anwendet, nicht der Datentyp die was tun.
Ausser man macht eine Klasse daraus.

[mschnell]

Kann dir nicht folgen was du damit meinst.

Widestrings bestehen aus 16-Bit Speicher-Einheiten. Damit wäre eine UCS2-Kodierung möglich (nur eingeschränkte Menge von Unicode Zeichen darstellbar, jedes Zeichen belegt genau eine 16-Bit Einheit) oder UTF-16 (alle Unicode-Teichen darstellbar, ein Zeichen belegt entweder ein oder zwei 16-Bit-Einheiten).

Nicht aber utf-8 (8 Bit Speicher-Einheiten, alle Unicode-Zeichen sind darstellbar, ein Zeichen belegt entweder eine, zwei oder drei oder vier 8-Bit Einheiten).

-Michael

[mschnell]

Was hat denn z.B ein Integer oder ein AnsiString für "Möglichkeiten" und Vorschriften was passieren soll? Es sind doch die Funktionen, die man darauf anwendet, nicht der Datentyp die was tun.

Klar, aber es werden dieselben Funktionen und Operatoren hingeschrieben, egal welcher Typ die Variable ist.
Alle String-Typen bieten die Möglichkeit i:=length(s) und x:=s[2] zu schreiben. Dann sollte etwas vernünftiges und kompatibles (bei virtuell gleichem Inhalt an irgendwie darstellbaren Zeichen richtigerweise exakt dasselbe) passieren, egal welcher String Typ verwendet wird. Am besten ist Length die Anzahl der (gedachten) Zeichen, egal wie diese intern kodiert sind und bei der s-Notation sollte das i-te gedachte Zeichen gemeint sein, egal wie diese Zeichen intern dargestellt sind.
Es sind doch die Funktionen, die man darauf anwendet, nicht der Datentyp die was tun.

[RSE]

Da mein Vorschlag scheinbar Anklang findet hier ein neuer, fehlannahmenbereinigter Prototyp eines Interfaces:

Code: Alles auswählen

TStr = class(TObject)
  ...
public
  property AnsiString: String read GetAnsiString write SetAnsiString;
  property UTF8String: String read GetUTF8String write SetUTF8String;
  property AnsiAString: AnsiString read GetAnsiString write SetAnsiString;
  property UTF8AString: AnsiString read GetUTF8String write SetUTF8String;
 
  property UTF16String: String read GetUTF16String write SetUTF16String;
  property UCS2String: String read GetUCS2String write SetUCS2String;
  property UTF16WString: WideString read GetUTF16String write SetUTF16String;
  property UCS2WString: WideString read GetUCS2String write SetUCS2String;
 
  property UTF32String: String read GetUTF32String write SetUTF32String;
  property UCS4String: String read GetUCS4String write SetUCS4String;
  property UTF32String: UCS4String read GetUTF32String write SetUTF32String;
  property UCS4String: UCS4String read GetUCS4String write SetUCS4String;
 
  property Character[APosition: Cardinal]: AnsiString read GetCharacter write SetCharacter; default;  // damit kann man wie bei einem Ansi-Codierten String auf die Buchstaben zugreifen
  function Count: Cardinal;  // eine property ist hier sicherlich überflüssig, da sowieso nur gelesen wird
  property CodePage: ? read GetCodePage write SetCodePage;  // Voreinstellung muss hier natürlich die Codepage im System sein, falls das mit ANSI arbeitet, ansonsten irgendein sinnvoller Wert
end;

Die ganzen properties vom Typ String müssen dann noch entsprechend von Compilerweichen umrahmt werden, so dass nur diejenigen 2 implementiert werden, die dem aktuellen String-Typ entsprechen. Die Getter- und Setterfunktionen sind dementsprechend die gleichen für z.B. UTF8 AnsiString und String, wenn String = type AnsiString ist. Was habe ich noch vergessen, was man sonst noch braucht?

Edit:
property für die Ansi-Codepage hinzugefügt. Ob das sinnvoll und umsetzbar ist, eiß ich nich, habe keine Ahnung von Codepages und wie die verarbeitet/ umgerechnet (nach und von Unicode) werden können.

[theo]

Dann sollte etwas vernünftiges und kompatibles (bei virtuell gleichem Inhalt an irgendwie darstellbaren Zeichen richtigerweise exakt dasselbe) passieren, egal welcher String Typ verwendet wird.

Dazu hatte ich hier schon mal ne Frage gestellt: http://www.lazarusforum.de/viewtopic.php?p=24215#p24215" onclick="window.open(this.href);return false;

[theo]

Da mein Vorschlag scheinbar Anklang findet hier ein neuer, fehlannahmenbereinigter Prototyp eines Interfaces:

Das ist imho zuviel: Es würden UTF8String, WideString und UCS4String Getter und Setter reichen.
Was du mit String vs. AnsiString meinst versteh ich noch immer nicht. Meinst du ShortString?
Auf die Konvertierung mit CodePages würde ich verzichten, d.h. den eigentlichen AnsiString mit 256 Zeichen vergessen. Der ist sowieso nicht vollständig konvertierbar zu Unicode, allenfalls teilweise mit CodePages aber dann gute Nacht..

Dafür würde ich das Character Property überladen, sodass man alle Sorten abholen/setzen kann: UTF8String, WideChar und UCS4Char.

[RSE]

Was du mit String vs. AnsiString meinst versteh ich noch immer nicht. Meinst du ShortString?

Nein. Es gibt den Datentyp String. Dieser ist Standardmäßig String = type AnsiString;, das kann man aber durch Einstellungen offenbar auf String = type WideString; ändern. Dann müssten die 16-Bit String properties statt der 8-Bit String properties deklariert werden. Das sollte mit Compilerswitches machbar sein.

Das ist imho zuviel: Es würden UTF8String, WideString und UCS4String Getter und Setter reichen.

Nein, UTF-8 ist ungleich Ansi, UTF-16 ist ungleich UCS-2 und UTF-32 ist nicht ganz identisch mit UCS-4 (http://de.wikipedia.org/wiki/UTF-32" onclick="window.open(this.href);return false;). Also brauchen wir alle 6. Es soll ja gerade die Umwandlung zwischen den Codierungen gekapselt werden.

Auf die Konvertierung mit CodePages würde ich verzichten, d.h. den eigentlichen AnsiString mit 256 Zeichen vergessen. Der ist sowieso nicht vollständig konvertierbar zu Unicode, allenfalls teilweise mit CodePages aber dann gute Nacht..

dazu nur so viel:

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.

Dafür würde ich das Character Property überladen, sodass man alle Sorten abholen/setzen kann: UTF8String, WideChar und UCS4Char.

Wenn denn so etwas geht:

Code: Alles auswählen

function GetCharacter(APosition): AnsiString;
function GetCharacter(APosition): WideChar;
function GetCharacter(APosition): UCS4Char;

Zudem halte ich WideChar für ungünstig, da dort nicht jedes Zeichen reinpasst. Im fall der Benutzung der WideChar-Funktion würde dann wohl ein Laufzeitfehler nötig, wenn ein 3- oder 4-Byte-Zeichen ausgegeben werden muss. Aus diesem Grund würde ich mich dort auf AnsiString und UTF4Char beschränken wollen. Lediglich den Setter könnte man IMHO sinnigerweise mit AnsiString, WideString, Char, WideChar und UCS4Char überladen.

[theo]

Nein. Es gibt den Datentyp String. Dieser ist Standardmäßig String = type AnsiString;, das kann man aber durch Einstellungen offenbar auf String = type WideString; ändern.

Das ist mir nicht bekannt. Quelle?

Nein, UTF-8 ist ungleich Ansi, UTF-16 ist ungleich UCS-2 und UTF-32 ist nicht ganz identisch mit UCS-4 (http://de.wikipedia.org/wiki/UTF-32" onclick="window.open(this.href);return false;). Also brauchen wir alle 6. Es soll ja gerade die Umwandlung zwischen den Codierungen gekapselt werden.

Wie gesagt, Ansi (256 Zeichen) würde ich weglassen weil das kein Unicode ist. Unicode ist ja u.a. dazu da, dass diese Codepages verschwinden.
UCS2 ist ein Sonderfall von UTF32. Letzteres reicht imho.
Den Unterschied zwischen UCS-4 und UTF-32 müsstest du mir erklären.

Zudem halte ich WideChar für ungünstig, da dort nicht jedes Zeichen reinpasst.

Da hast du recht, dann müsste da halt ein WideString zurückgegeben werden, genauso wie bei UTF8 auch ein UTF8String den Buchstaben repräsentiert. Letzlich ist nur ein UCS4Char ein Datentyp fester Länge, welcher alle Zeichen halten kann.

[mschnell]

Da hast du recht, dann müsste da halt ein WideString zurückgegeben werden,

Finde ich ganz schlecht. Der "Character" - Rückgabe-Typ sollte schon ein Character des entsprechenden Typs sein. Wenn es sich nicht darstellen lässt sollte da vielleicht #0 zurückgegeben werden (auch bei ANSIChar falls das Zeichen nicht in der aktuellen Codepage ist). Vielleicht ist es sinnvoll für utf-8 und utf-16 zusätzlich eine Rückgabe in einem UTF8String und einem UT16FString vorzusehen.

-Michael

[mschnell]

function GetCharacter(APosition): AnsiString;

Nee bitte ein einzelner ANSIChar (entsprechend der eingestellten Codepage).
Möglicherweise zusätzliche "String-Character" für utf8 und utf16 (siehe anderer Beitrag)
-Michael

[theo]

Es gibt wie gesagt nur einen Char Typen der alles darstellen kann und das ist UCS4Char.
Alles andere ist gebastel.
Man könnte allerdings einen WideChar abrufen. Wenn dort ein Surrogat Paar ist, könnte man eine Exception auslösen.

[RSE]

Nein. Es gibt den Datentyp String. Dieser ist Standardmäßig String = type AnsiString;, das kann man aber durch Einstellungen offenbar auf String = type WideString; ändern.

Das ist mir nicht bekannt. Quelle?

Ist offenbar eine weitere Fehlannahme meinerseits gewesen. Damit fallen natürlich alle String-properties außer der 8-Bit-Version weg . Wieso redet ihr hier alle von WideString? Gibt es Betriebssysteme (Linux?), die mit WideString arbeiten? Kenne mich nur mit Windows aus.

Nein, UTF-8 ist ungleich Ansi, UTF-16 ist ungleich UCS-2 und UTF-32 ist nicht ganz identisch mit UCS-4 (http://de.wikipedia.org/wiki/UTF-32" onclick="window.open(this.href);return false;). Also brauchen wir alle 6. Es soll ja gerade die Umwandlung zwischen den Codierungen gekapselt werden.

Wie gesagt, Ansi (256 Zeichen) würde ich weglassen weil das kein Unicode ist. Unicode ist ja u.a. dazu da, dass diese Codepages verschwinden.
UCS2 ist ein Sonderfall von UTF32. Letzteres reicht imho.
Den Unterschied zwischen UCS-4 und UTF-32 müsstest du mir erklären.

Was meinst du, wozu ich den Link eingebaut habe? Ansi möchte ich auf keinen Fall außer Acht lassen, weil nämlich Windows mit Ansi arbeitet. Mir ist klar, dass die Codepages mächtig Ärger machen werden, aber ohne Ansi ist das ganze Konstrukt doch in der Windows-Welt reichlich unbrauchbar (zumindest, wenn man keine anderen Konvertierungen durchführen will, die ich ja gerade alle kapseln will).

Die Character-Property soll dazu da sein, um denjenigen Teilstring zurückzugeben, der für das Zeichen an Position x steht. Dieser Teilstring kann, muss aber nicht aus einem einzelnen Zeichen bestehen! Daher bin ich absolut dagegen (außer bei UTF32 und UCS4) mit Chars zu arbeiten. Dann könnten wir gleich bei den vorhandenen Stringtypen bleiben.

[theo]

Gibt es Betriebssysteme (Linux?), die mit WideString arbeiten?

Windows

Was meinst du, wozu ich den Link eingebaut habe?

Den Link sehe ich schon, aber den Unterschied erkenne ich nicht. In der weiterführenden Seite heisst es:
UCS-4: Kodierung in 4 Byte (entspricht UTF-32)

Ansi möchte ich auf keinen Fall außer Acht lassen, weil nämlich Windows mit Ansi arbeitet.

Das kann man so nicht sagen. Delphi arbeitete bis zur Version 2009 mit Ansi.
In Windows gibt es schon seit längerer Zeit Unicode:

"Obwohl man auf der Oberfläche von Windows noch viel mit ASCII bzw. ANSI arbeitet, arbeitet die Windows NT-Reihe (also auch Win2000, WinXP, Win2003) seit der Version 4.0 intern komplett mit Unicode."
http://www.lima-city.de/tutorials/show/1887" onclick="window.open(this.href);return false;

[RSE]

In Windows gibt es schon seit längerer Zeit Unicode:
"Obwohl man auf der Oberfläche von Windows noch viel mit ASCII bzw. ANSI arbeitet, arbeitet die Windows NT-Reihe (also auch Win2000, WinXP, Win2003) seit der Version 4.0 intern komplett mit Unicode."
http://www.lima-city.de/tutorials/show/1887" onclick="window.open(this.href);return false;

Sehr interessant. Laut http://en.wikipedia.org/wiki/UTF-16#Use ... vironments" onclick="window.open(this.href);return false; benutzt Windows UTF-16. Jetzt ist mir auch klar, was ihr immer mit WideString wollt . Danke für die Aufklärung.

Den Link sehe ich schon, aber den Unterschied erkenne ich nicht. In der weiterführenden Seite heisst es:
UCS-4: Kodierung in 4 Byte (entspricht UTF-32)

Das steht nicht auf der von mir verlinkten Seite, sondern auf http://de.wikipedia.org/wiki/Universal_Character_Set" onclick="window.open(this.href);return false; (habe ich durch Zufall gefunden).
Auf der von mir verlinkten Seite (http://de.wikipedia.org/wiki/UTF-32" onclick="window.open(this.href);return false;) steht folgendes: "Im aktuellen Unicode Standard 5.1 ist UTF-32 eine Untermenge von UCS-4." Offenbar hat sich da wohl gerade etwas geändert, oder bei Wiki steht mal wieder Mist.

Andere Überlegung: In der wstringh.inc gibt es lediglich Konvertierungsfunktionen zwischen Ansi UTF-8 WideString UCS-4. Ich hatte eigentlich geplant, diese Funktionen für die Konvertierungen zu benutzen. Laut mse in seinem Beitrag vom 19.10.2008, 12:28 ist WideString UTF-16 codiert:

ansistring -> widestring, der ansistring wird vom widestringmanager unter Verwendung der aktuellen Systemcodierung in utf-16 gewandelt, unter Linux muss dafür die unit cwstring unter uses aufgeführt werden.

Somit fallen UCS-2 und UTF-32 als Optionen weg, solange keiner eine Konvertierungsfunktion zwischen UCS-2 und UTF-16 findet und den genauen Unterschied zwischen UTF-32 und UCS-4 kennt (falls er nun existiert) oder dafür eine Konvertierungsfunktion findet.

Somit lautet die "aktuelle Version" folgendermaßen (wieder mit neuen Ideen aufgefüllt ):

Code: Alles auswählen

TStr = class(TObject)
  ...
public
  property AnsiString: AnsiString read GetAnsiString write SetAnsiString;
  property UTF8String: UTF8String read GetUTF8String write SetUTF8String;
  property UTF16String: WideString read GetUTF16String write SetUTF16String;
  property UCS4String: UCS4String read GetUCS4String write SetUCS4String;
 
  property AnsiChar[APosition: Cardinal]: Char read GetAnsiChar write SetAnsiChar;  // eigentlich unnötig
  property UTF8Char[APosition: Cardinal]: UTF8String read GetUTF8Char write SetUTF8Char;
  property UTF16Char[APosition: Cardinal]: WideString read GetUTF16Char write SetUTF16Char;
  property UCS4Char[APosition: Cardinal]: UCS4Char read GetUCS4Char write SetUCS4Char;  // eigentlich unnötig
 
  function AnsiSubStr(AStartPosition, ACharacterCount: Cardinal): AnsiString;  // eigentlich unnötig
  function UTF8SubStr(AStartPosition, ACharacterCount: Cardinal): UTF8String;
  function UTF16SubStr(AStartPosition, ACharacterCount: Cardinal): UTF16String;
  function UCS4SubStr(AStartPosition, ACharacterCount: Cardinal): UCS4String;  // eigentlich unnötig
 
  function AnsiLength(AStartPosition, ACharacterCount: Cardinal): Cardinal;  // eigentlich unnötig
  function UTF8Length(AStartPosition, ACharacterCount: Cardinal): Cardinal;
  function UTF16Length(AStartPosition, ACharacterCount: Cardinal): Cardinal;
  function UCS4Length(AStartPosition, ACharacterCount: Cardinal): Cardinal;  // eigentlich unnötig
 
  function AnsiCount: Cardinal;  // eigentlich unnötig
  function UTF8Count: Cardinal;
  function UTF16Count: Cardinal;
  function UCS4Count: Cardinal;  // eigentlich unnötig
 
  property CodePage: ? read GetCodePage write SetCodePage;  // aktuell verwendete Codepage, Voreinstellung ist z.B. die Codepage im System, falls es mit Ansi arbeitet
  function Suitable(ACodePage: ?): Boolean  // true, wenn der aktuell gespeicherte String mit der übergebenen Codepage komplett dargestellt werden kann.
  function GetSuitableCodepages: ?;  // Gibt eine Liste aller im System vorhandenen oder sonstwie bekannten Codepages zurück, die den aktuellen String darstellen können
end;

Damit ist nun auch in jedem Fall die Codierung klar. Bei den mit "// eigentlich unnötig" gekennzeichneten properties und Funktionen kann man auch auf althergebrachte Funktionen wie copy() und length() zurückgreifen.

[mschnell]

Somit fallen UCS-2 und UTF-32 als Optionen weg, solange keiner eine Konvertierungsfunktion zwischen UCS-2 und UTF-16 findet

UCS2 und UTF16 sind derselbe Code,solange keine extrem-Zeichen verwendet werden (alt-Ägyptisch etc). Nur dann treten surrogate pairs auf und die werden von der Widestring Funktionen nicht in irgendwie sinnvoll behandelt, sondern einfach als zwei separate Zeichen verwaltet. Demnach ist da auch keine sinnvolle Konvertierung möglich. Wenn Du spezielle utf-16 Funktionen einbauen willst (die möglicherweise den Datentyp widestring zum Speichern der Information verwenden), brauchst Du natürlich einen Konverter utf8utf16utf32. Das sollte relativ einfach gehen, weil keine Tabellen benötigt werden sondern ein Algorithmus, der sich aus der Unicode Definition ergibt

Ich glaube der Unterschied zwischen ucs4 und utf32 ist so minimal, dass er vernachlässigt werden kann.

function AnsiLength(AStartPosition, ACharacterCount: Cardinal): Cardinal; // eigentlich unnötig
function UTF8Length(AStartPosition, ACharacterCount: Cardinal): Cardinal;
function UTF16Length(AStartPosition, ACharacterCount: Cardinal): Cardinal;
function UCS4Length(AStartPosition, ACharacterCount: Cardinal): Cardinal; // eigentlich unnötig

Die Anzahl der "sichtbaren" Zeichen sollte doch für alle Codierungen gleich sein. Da reicht doch eine Funktion ????
(Ich vermute "??Count" ist die Anzahl der gleichgroßen Elemente, die je nach Zeichen unterschiedlich sein kann)

-Michael