widestring

[sancho1980]

Hallo,
sagt mal, wie muss ich mir eigentlich den WideString-Typ vorstellen? Das ist doch Unicode, oder? Wieviele Bytes werden da pro Zeichen verwendet? Habe neulich gelesen, dass es auch bei Unicode nochmal Unterscheidungen zwischen den einzelnen Formaten gibt. Welches wird denn da bei WideString verwendet? Weiß das einer?
Danke,
Martin

[himitsu]

der WideString ist im UCS2-Format, also 2 Byte pro Zeichen.

Allerdings ist der nicht wie der AnsiString ein "Delphi-eigenes Format", sonder wird über einen OLE-String gehandhabt, was auch erklärt warum die WideStrings keine Referenzzählung besitzen :cry:

Für's neuere UCS4 gibt es in Delphi leider auch noch keine Möglichkeiten -.-''

[Bernhard Geyer]

Zitat:

Zitat von himitsu

der WideString ist im UCS2-Format, also 2 Byte pro Zeichen.

Erst ab W2K. NT kennt UCS2 nicht.

Zitat:

Zitat von himitsu

Für's neuere UCS4 gibt es in Delphi leider auch noch keine Möglichkeiten -.-''

AFAIk auch keine Win-API-Funktionen um es auf den Bildschirm zu bekommen.

Zitat:

Zitat von sancho1980

Habe neulich gelesen, dass es auch bei Unicode nochmal Unterscheidungen zwischen den einzelnen Formaten gibt.

Vermutlich meinst Du die Speicherformate wie z.B. UTF8.

[sancho1980]

hmmm
von ole hab ich auch schon mal was gehört; aber was es damit auf hat war mir bisher immer ein rätsel
würd's dir was ausmachen, mir noch zu erklären, was du mit der referenzzählung meinst?

Zitat:

Vermutlich meinst Du die Speicherformate wie z.B. UTF8

Ja, genau.
Ist UCS2 auch so ein Speicherformat oder is das wieder was anderes?

[Hawkeye219]

Hallo,

hier ist ein Link zum Thema Referenzzählung bei Ansistrings.

Gruß Hawkeye

[himitsu]

Stimmt nicht ganz, es gibt inzwischen Möglichkeiten die UCS4-Zeichen darzustellen, nur hab ich bisher selber noch nicht rausfinden konnte wie das möglich ist, aber dafür daß es geht gibt es Beweise ... das Program CharMap z.B.

Delphi-Quellcode:

Erst ab W2K. NT kennt UCS2 nicht.

tja und darum funktioniert meine Unicodversion vom Opendialog nicht in den alten WindowsVersionen, diese haben zwar schon die API-Funktionen drin, aber leider sind diese total lehr, so daß es nichtmal ein Fehler gibt, wenn man diese aufruft, es passiert halt einfach nur nichts :cry:


Der OLE-String wird von der OLE32.dll verwaltet ... delphi leitet einfach alle nötigen Aufrufe an diese DLL weiter ... es verwaltet den String halt nicht selber, so wie es z.B. beim AnsiString der Fall ist.



UCS2 ist einfach nur ein nur ein UniCodeString mit 2 Bytes pro Zeichen, halt von den Daten her das selbe, wie es im WideString vorkommt

Beim UTF8 kann man alle Zeichen codieren, wobei ein Zeichen keine feste Länge hat, wärend ANSI/ASCII/UCS1/UCS2/UCS4 eine feste Länge haben (beim ANSI gibts aber auch ausnahmen, da dieses eigentlich auch ein Multibytezeichensatz ist, aber ich kenne noch keine Sprache/Codetabelle, wo dieses auch genutzt wird)

[Bernhard Geyer]

Zitat:

Zitat von himitsu

... da dieses eigentlich auch ein Multibytezeichensatz ist, aber ich kenne noch keine Sprache/Codetabelle, wo dieses auch genutzt wird)

AFAIK arbeiten die Japanischen/chinesichen Windows-Versionen im "Nicht-Unicode-Modus" so.

[himitsu]

Zitat:

Zitat von Bernhard Geyer

AFAIK arbeiten die Japanischen/chinesichen Windows-Versionen im "Nicht-Unicode-Modus" so.

dann möchte ich aber viele "Delphi"-Programme in diesen Windowsversionen nicht testen, denn leider sind zuviele Codes nicht MultiByte-fähig, vorallem wenn diese Zeichenketten Charweise verarbeiten ._.
(ich geb zu meine codes sind das auch nicht alle, aber ich versuche das Stück für Stück zu beheben)

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Zitat:

Zitat von Bernhard Geyer

AFAIK arbeiten die Japanischen/chinesichen Windows-Versionen im "Nicht-Unicode-Modus" so.

dann möchte ich aber viele "Delphi"-Programme in diesen Windowsversionen nicht testen, denn leider sind zuviele Codes nicht MultiByte-fähig, vorallem wenn diese Zeichenketten Charweise verarbeiten ._.

Kann sein das viele Nicht-Unicode-Anwendungen (wird nicht nur Delphi-Anwendungen betreffen) probleme mit solchen Sprachen haben.

[himitsu]

Das ist jetzt auch ein Grund, warum ich seit 'ner Weile versuche von ANSI Abstand zu nehmen, also entweder richtig Unicode (UCS2) zu verwenden und wenn schon 1-Byte, dann ASCII, oder ähnliches, aber halt nichts MultiByte-mäßiges ... dann hat man da zumindestens keine Probleme in dieser Richtung mehr ^^ (nur schade daß Delphi standardmäßig ANSI will -.-'')

[Ydobon]

UCS4 ist doch nicht unbedingt eine neuere Variante und große Zukunftsaussichten hat es auch nicht, dazu ist die Speicherverschwendung selbst bei CJK(V) Texten einfach viel zu riesig.
Delphi kennt aber trotzdem z.B. die Typen UCS4Char = type LongWord; und UCS4String = array of UCS4Char;

Es dürften aber nur wenige Gelegenheiten existieren, wo man dies brauchen könnte, da man in Windows (ab 2000?) die Unterstützung für Surrogate Code Pairs (2 x 2 Byte) aktivieren kann und damit in Windows also auch in Delphi mit WideStrings den kompletten Unicodebereich zur Verfügung hat.

Für nicht Unicodeprogramme in anderen Sprachen kann man ab Win2k einstellen, dass Windows unabhängig von der eigenen Sprachversion diese Sprachen unterstützen soll. Mit AppLocale wird es auch noch etwas bequemer. So bekommt man dann chinesische oder japanische Programme mit deutschem Windows zum Laufen.

Eine interessante Frage wäre, ob sich die Delphiquelltexte mit Microsoft Layer for Unicode etwas aufmöbeln lassen würden, so dass man auch mit Delphi Unicodeprogramme für Win < 2000 schreiben könnte.

[himitsu]

Zitat:

Zitat von Ydobon

UCS4 ist doch nicht unbedingt eine neuere Variante und große Zukunftsaussichten hat es auch nicht, dazu ist die Speicherverschwendung selbst bei CJK(V) Texten einfach viel zu riesig.
Delphi kennt aber trotzdem z.B. die Typen UCS4Char = type LongWord; und UCS4String = array of UCS4Char;

Also solche Typen sind bereits definiert, auch wenn sie bei mir etwas anders heißen :roll:

Auch wenn ich im Moment noch keinen Gerbrauch davon machen ... na ja, wenigstens ist für die Stringverarbeitung schon "alles" vorhanten (bei mir), also angefangen mit SetLength/Length, über Copy und was man sonst noch so brauchen könnte ^^

Und soviel Wichtiges ist in UCS4 ja wirklich nicht drin, außer ein paar Zeichen, die in UCS2 keinen Platz mehr hatten und halt ein paar Zeichen in verschiedenen Schriftarten (Fett/Kursiv/Alt...)

[Ydobon]

:?: Mit Unicode werden nur die Codepunkte für die Zeichen definiert, wie sie dann dargestellt werden (fett usw.) ist eine andere Geschichte.
Unicode wurde auf etwas mehr als 1 Mio Codepunkte beschränkt, diese lassen sich auch mit UCS2 bzw. UTF-16 durch diesen Surrogate Spaß darstellen, von dort stammt ja die Begrenzung. Einen richtigen Grund immer mit 4 Byte zu arbeiten gibt es daher eigentlich nicht.

[Bernhard Geyer]

Zitat:

Zitat von Ydobon

Eine interessante Frage wäre, ob sich die Delphiquelltexte mit Microsoft Layer for Unicode etwas aufmöbeln lassen würden, so dass man auch mit Delphi Unicodeprogramme für Win < 2000 schreiben könnte.

Vergis den Microsoft Layer for Unicode. Unter Win9x/ME ruft er eh nur die ANSI-Versionen der API-Funktionen auf da die Widestring-Versionen nur Dummies sind. Nur mit dem ElPack kannst Du mit Delphi auch unter Win9x/ME Unicode unterstützen. Mehr als selbst .NET dir bieten kann.