Ist wahres Unicode mit Delphi überhaupt möglich?

[raiguen]

Zitat von Zacherl:

...
€: @toms: Mh irgendwie stehen da zwar viele Komponenten, aber nichts über die Ribbons. Oder bin ich mal wieder blind

Nö,nö...du bist nicht blind Die paar 'wunderhübschen' neuen Komponenten sind m.E. nun wirklich nicht der Bringer ... und wie die unter XP aussehen -> Windoof 3.11-Style *öörgs*

Zitat:

It's not graceful degradation - in XP the application is not themed!!!! It has a Windows 2000 look and feel, not XP. Probably it's just because you didn't have a theme active, but *before* taking the screenshot would have been nice to activate one. That't not a good propaganda for Tiburon!

Ich für meine Teil werde NICHT dem (teuren)Update-Wahn verfallen - mir scheinen die bekannten Bugs der Vorgängerversionen etc noch nicht in Gänze gefixt... aslo von daher bleibe ich (noch) bei meiner 'guten' alten D7E mit den entsprechenden Zusatzkompos (spez. TNT und Konsorten...); da weiss ich was ich hab und btw: XP-Style lässt sich auch gut 'implementieren' (XP-Manifest einbinden und gut ist's...)

Gruss
Rainer

[rakekniven]

Um nochmal auf den Titel des Threads zurückzukommen:

Ja, mit Delphi 2009 ist es möglich "wahres Unicode" zu verwenden. (Wobei noch zu definieren wäre, was wahres Unicode ist )
Habe heute mit eigenen Augen D2009 gesehen. Viele Beispiele wurde gezeigt, egal ob nun Stringoperationen, Datenbankinhalte/migration oder auch die IDE selbst. Es ist echter Unicode.

Auch die Rechts-nach-links Sprachen wurden berücksichtigt, d.h wenn in einem TEdit ein String vorkommt, der aus lateinischen Zeichen besteht und in der Mitte z.B. arabische Zeichen vorkommen dann hüpt der Cursor bei rechter Pfeiltaste schön von links nach rechts, erreicht er den arabischen Teil überspringt er diesen, hüpft dann von rechts nach links durch den Teil und springt danach wieder rechts hinter den arabischen Teil um die weiteren Zeichen nach rechts zu durchlaufen.

Übrigens wird nicht UTF16 sondern für alles UTF8 verwendet. Man kann durch explizite Vorgabe aber auch UTF16 verwenden. Somit kann es Zeichen geben die ein bis sechs Byte brauchen.
Ein Umstellen der Datenbank führt nicht zu einer Verdoppelung der Größe, wie vielfach erwähnt, das Unicode nicht 2 Byte pro Zeichen bedeutet.

Freue mich schon!

Gruß

[blackdrake]

Klingt ja echt verlockend. Hoffentlich wird es mal wieder ein Turbo Delphi mit der Technik von 2009+ geben. In USA scheint der Releasetermin für D2009 der 25. August zu sein, auch in Europa?

Schade finde ich, dass in Delphi immer alles verspätet kommt. Viele Technologien kommen meist viel zu spät und Delphi war mir schon immer zu stark Datenbankorientiert. Unicode gibts ja bereits seit Windows 95 (Widestrings in den EXE Dateien) und hätte in Delphi schon viel früher implementiert werden sollen. Jetzt ist es ja endlich so weit und benötigt kaum Portierungsarbeit.

Irgendwie blöd, dass das alles so teuer ist und man in den Personal-Editionen nur sehr begrenzte Funktionen erhält (mein erster Kauf war Delphi 6 Personal für 333 Euro - 6 Monate später war es in einer Zeitschrift für umsonst) - und das Codeexplorer-Feature vermisste ich dort schmerzlich. Zudem rentiert es sich bei mir auch kaum.

[Bernhard Geyer]

Zitat von rakekniven:

Übrigens wird nicht UTF16 sondern für alles UTF8 verwendet. Man kann durch explizite Vorgabe aber auch UTF16 verwenden. Somit kann es Zeichen geben die ein bis sechs Byte brauchen. Ein Umstellen der Datenbank führt nicht zu einer Verdoppelung der Größe, wie vielfach erwähnt, das Unicode nicht 2 Byte pro Zeichen bedeutet.

Ich glaube du verwechselst hier was. Der Unicode-Stringtyp wird auf UTF-16 basieren. Alles andere wäre performancetechnisch eine Schrottlösung. Allein die Zeile

Zitat:

The ElementSize for an UnicodeString is: 2

von Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode bestätigt dies. Bei UTF wäre der ElementSize 1.

Es würde keinen Sinn machen einen UTF8-Basierten Stringdatentypen in 2008 neu einzuführen wenn das unterstützte Betriebssystem mit UTF-16 arbeitet. (Wie ist da eigentlich bei Win64 )

Bei vielen Datenbanken (Interbase/MySQL/Oracle) wird auf Transportebene UTF-8 verwendet und zwar aus dem einfachen Grund das diese Datenbanken Aufgrund der historischen Entwicklung keine andere Möglichkeit bieten da ihre Netzwerkinterfaces noch 8-Bit-characterbasiert sind. Allein MS SQL Server (mehr SQL Server kenn ich nicht die das so machen) und diverse Desktopdatenbanken (TurboDB, Accuracer, ...) können auf ihrer Programmierschnittstelle direkt mit UTF-16/UCS2 umgehen.

Zitat von blackdrake:

Schade finde ich, dass in Delphi immer alles verspätet kommt.

Oft hatte das Vorteile (Einfachheit der COM-Implementierung gegenüber z.B. C++). Jedoch hat man mit dem Kylix-Ausflug ca. 2 Jahre verloren und der .NET-Port ist ja ziemlich zurechtgestutzt worden.

Zitat von blackdrake:

Unicode gibts ja bereits seit Windows 95 (Widestrings in den EXE Dateien) und hätte in Delphi schon viel früher implementiert werden sollen.

Der Unicode-Support unter Win9x/ME ist marginal. Ca 12 Funktionen sind Unicode-Enabled (reicht aber um mit ElPack Unicode unter Win9x/ME ohne Installlation anbieten zu können). Viele Widestring-Win32-API-Funktionen existieren nur als Dummy und auch der Unicodelayer for Win9x ist 'ne Mogelpackung (interne weiterleitung der Widestring-API-Aufrufe auf die Ansi-Funktionen) und bietet genau die gleiche Funtionalität welche die TNTWare-Kompos bieten.

Auch ist Win95 erschreckend langsam bei Verwendung von Unicode (bei gleicher HW ist Win98 merklich flotter - hier auch wieder eigene App mit ElPack getestet).

[rakekniven]

Zitat von rakekniven:

Übrigens wird nicht UTF16 sondern für alles UTF8 verwendet. Man kann durch explizite Vorgabe aber auch UTF16 verwenden. Somit kann es Zeichen geben die ein bis sechs Byte brauchen. Ein Umstellen der Datenbank führt nicht zu einer Verdoppelung der Größe, wie vielfach erwähnt, das Unicode nicht 2 Byte pro Zeichen bedeutet.

Zitat von Bernhard Geyer:

Ich glaube du verwechselst hier was. Der Unicode-Stringtyp wird auf UTF-16 basieren. Alles andere wäre performancetechnisch eine Schrottlösung.

Es würde keinen Sinn machen einen UTF8-Basierten Stringdatentypen in 2008 neu einzuführen wenn das unterstützte Betriebssystem mit UTF-16 arbeitet. (Wie ist da eigentlich bei Win64 )

Heute wurde sehr viel über UTF-8 (und die intelligente Kodierung dahinter), UTF-16, BOM, TEncoding, Preambles usw. erzählt.
Falls ich da etwas unklar wiedergegeben habe, so entschuldige.
Freue mich auf jeden Fall auf D2009 und werde gleich unser Translate-Tool (MySQL) und einige GUIs auf Unicode umstellen.

Gruß

P.S. Ich bin privat seit ewigen Zeiten reiner Linux-User und schätze schon seit einigen Jahren, das Quanta, Php, KDevelop, Kate und andere Tools (KDE insgesamt) Unicode sind. Da kann ich auch mal in den Malayischen Übersetzungen ein paar Formatierungskorrekturen vornehmen, ohne mir Sorgen zu machen, dass danach die Darstellung nicht mehr in Ordnung ist.

[xaromz]

Hallo,

Zitat von rakekniven:

Php...

Kleine Anmerkung: PHP wird erst mit der kommenden Version 6 Unicode unterstützen.

Gruß
xaromz

[rakekniven]

Stimmt nicht ganz. z.B. sind alle Webseiten vom KDE-Projekt schon UTF-8-Dateien und auch die Stringfunktionen arbeiten damit klaglos.

Gruß