LCL Unicode Support/de
│
Deutsch (de) │
English (en) │
español (es) │
français (fr) │
日本語 (ja) │
한국어 (ko) │
русский (ru) │
中文（中国大陆） (zh_CN) │
中文（台灣） (zh_TW) │
Einleitung
Die Lazarus Unterstützung des Unicode Standards benötigt einen weiteren Ausbau, mostly in regard to the Windows platform. Here are some basic information for those who would like to further develop the Lazarus Unicode support. Bitte korrigieren, erweitern und updaten sie diese Seite.
Es ist hilfreich, wenn sie bereit vom Unicode Standard gehört haben und vielleicht erste Erfahrungen mit WideStrings unter Delphi gemacht haben. Previous use of non-(western)Latin scripts and their various character sets will help too.
Anmerkung: Die Implementierungsdetails befinden sich in Diskussion, daher kann sich der Inhalt dieser Seite noch ändern.
Implementierungsrichtlinien
Ein großes Problem für die Implementierung der Unicode-Unterstützung in Lazarus ist die Abwärtskompatibilität für bestehende Lazarus Programme. The core of Lazarus development today (pre-1.0 era) is concentrated into stabilizing win32 and gtk interfaces, both of which are not unicode capable. When people develop software for non-fully working widgetsets like Gtk 2, Qt, WinCE (and futurely Win32U), they use the IDE compiled for more stable widgetsets, like Gtk and win32. This means that if we break compatibility for old software now, there will be a period of time (and a possibly large one) when Lazarus doesn´t work for ISO group and doesn´t work for Unicode, until we have interfaces stable enougth for the IDE to fully support Unicode.
To avoid this problem a smooth transition is the best way to go. And one that keeps old software running. This can be done by dividing the widgetsets into 2 groups. One for ANSI supporting widgetsets and another for Unicode supporting widgetsets.
The ANSI group will consist of: win32 and gtk (1) interfaces.
The UNICODE group will consist of most other interfaces: win32, gtk2, qt, carbon, wince, fpGUI
It is also possible to add Unicode support for the gtk 1 interface in the future.
Notice that win32 is on both groups, because a define will be used to select which subset to compile. After the transition is finished, win32 will be set to unicode mode by default.
In this division, existing software will work, if recompiled for win32 or gtk interfaces. And new software, using UTF-8 will work when recompiled for any of the widgetsets on the Unicode group. This will satisfy both new and old users.
One very important note is that you must use the IDE compiled for the same group you are targeting. This is because the IDE uses the encoding of the widgetset it was compiled to, and not the one of the target widgetset to write LFM and LRS files.
Roadmap
Jetzt da wir die Richtlinien haben, ist es Zeit, um eine Roadmap zu erstellen und put it into practice. Dafür wurde der folgende Plan erstellt. Unser Plan unterteilt die Aufgaben in 2 Gruppen, eine für primäre Aufgaben und die andere für sekundäre Aufgaben.
Alle primären Aufgaben müssen vollständig implementiert sein before we can say Lazarus is Unicode enabled, and as such will be the main attention of our effort.
Sekundäre Aufgaben sind erstrebenswert, werden aber nicht implementiert, bis sich Freiwillige dafür finden oder ein 'Kopfgeld' dafür ausgesetzt wird.
Primäre Aufgaben
Make Win32 Widgetset support UTF-8
Anmerkungen: On this step we will target all 32-bits Windows versions at the same time. All code produced on this effort will be isolated from the current win32 interface by IFDEFs, to avoid introducing bugs on this primary interface. After the transition time, the IFDEFs will be removed and only the Unicode code will remain.
Details about how to support unicode on Win9x are being debated.
Status: Nicht implementiert
Update der GTK 2 Keyboard Funktionen zum Funktionieren mit UTF-8
Anmerkungen:
Status: Nicht implementiert
Make sure the Lazarus IDE runs correctly with Win32U widgetset and support UTF-8
Anmerkungen:
Status: Nicht implementiert
Make sure the Lazarus IDE runs correctly with GTK 2 widgetset and support UTF-8
Anmerkungen:
Status: Nicht implementiert
Sekundäre Aufgaben
Update des Windows CE widgetset, so daß es UTF-8 verwendet
Anmerkungen: Stringkonvertierungsroutinen sind in der winceproc.pp Datei konzentriert. Viele Tests sind notwendig.
Status: Nicht implementiert
Unterstützung für Windows 9x im Win32 Unicode widgetset implementieren
Anmerkungen: TNT Komponenten für Delphi nutzen einige Tricks, die Win 9x Unterstützung erlauben. Wir mögen die selben Tricks verwenden, aber ein Freiwilliger wird benötigt, um sie zu implementieren.
Status: Nicht implementiert
Update der GTK 1 Keyboard Funktionen zum Funktionieren mit UTF-8
Anmerkungen:
Status: Nicht implementiert
Unicode essentials
Unicode standard maps integers from 0 to 10FFFF(h) to characters. Each such mapping is called a code point. In other words, Unicode characters are in principle defined for code points from U+000000 to U+10FFFF (0 to 1 114 111).
There are three schemes for representing Unicode code points as unique byte sequences. Diese Schemas werden Unicode Transformation Formate genannt: UTF-8, UTF-16 und UTF-32. Die Konvertierung zwischen allen von ihnen ist möglich. Hier sind ihre Haupteigenschaften:
UTF-8 UTF-16 UTF-32 Smallest code point [hex] 000000 000000 000000 Largest code point [hex] 10FFFF 10FFFF 10FFFF Code unit size [bits] 8 16 32 Minimal bytes/character 1 2 4 Maximal bytes/character 4 4 4
UTF-8 has several important and useful properties: It is interpreted as a sequence of bytes, so that the concept of lo- and hi-order byte does not exist. Unicode characters U+0000 to U+007F (ASCII) are encoded simply as bytes 00h to 7Fh (ASCII compatibility). This means that files and strings which contain only 7-bit ASCII characters have the same encoding under both ASCII and UTF-8. All characters >U+007F are encoded as a sequence of several bytes, each of which has the two most significant bits set. No byte sequence of one character is contained within a longer byte sequence of another character. This allows easy search for substrings. The first byte of a multibyte sequence that represents a non-ASCII character is always in the range C0h to FDh and it indicates how many bytes follow for this character. All further bytes in a multibyte sequence are in the range 80h to BFh. This allows easy resynchronization and robustness.
UTF-16 has the following most important properties: It uses a single 16-bit word to encode characters from U+0000 to U+d7ff, and a pair of 16-bit words to encode any of the remaining Unicode characters.
Finally, any Unicode character can be represented as a single 32-bit unit in UTF-32.
Für mehr siehe:
Unicode FAQ - grundlegende Fragen
Unicode FAQ - UTF-8, UTF-16, UTF-32 & BOM
Lazarus Component Library Architekturbestandteile
Die LCL besteht aus zwei Teilen:
- einem Zielplattform-unabhängigen Teil, welcher eine Klassenhierarchie analog zur Delphi VCL implementiert,
- "Interfaces" - dem Teil, der die Schnittstelle zu den APIs jeder Zielplattform implementiert.
Die Kommunikation zwischen den beiden Teilen wird erledigt von der abstrakten Klasse TWidgetset. Jedes widgetset wird durch seine eigene von TWidgetset abgeleitete Klasse implementiert.
Das GTK 1 widgetset ist das älteste. In diesem widgetset wird die String Kodierung durch die LANG Umgebungsvariable bestimmt, welche is usually a iso The ISO-8859-n group of single byte encodings. Recently (as of Mandriva 2007, for example), many distributions have being shipping Gtk 1 configured for UTF-8. Our Gtk 1 interface lacks proper support for UTF-8 on the keyboard handling routines, so this is a big problem, that increases the need for Lazarus to implement cross-platform Unicode support.
Das GTK2 widgetset funktioniert nur mit UTF-8 Kodierung, aber der Keyboard Code der Schnittstelle basiert noch auf dem alten GTK 1 Code, so daß es UTF-8 nicht komplett unterstützt.
Die win32 Schnittstelle ist mit ANSI widgets eingerichtet, so daß es gegenwärtig nicht möglich ist, Unicode mit win32 zu verwenden.
Die Qt Schnittstelle ist auf UTF-8 vorbereitet. Qt selbst verwendet UCS-2 als native Kodierung, aber die Lazarus Schnittstelle für Qt konvertiert von UTF-8 nach UCS-2.
Windows CE only support UCS-2 as character encoding, but our interface for it currently converts strings from ISO to UCS-2 before calling the Windows API. This is very easy to fix, as all conversion code is concentrated on a few routines on the winceproc.pp file.
Für mehr siehe: Internals of the LCL
Unicode-enabling the win32 interface
Anforderungen
The spirit of Lazarus is: "Write once, compile everywhere." This means that, ideally, an Unicode enabled application should have only one Unicode supporting source code version, without any conditional defines in respect to various target platforms.
The "interface" part of the LCL should support Unicode for the target platforms which support it themselves, concealing at the same time all peculiarities from the application programmer.
Windows platforms <=Win9x are based on ISO code page standards and do not support Unicode. Windows platforms starting with WinNT support Unicode. In doing that, these platforms offer two parallel sets of API functions: the old ANSII enabled *A and the new, Unicode enabled *W. *W functions accept wide strings, i.e. UTF-16 encoded strings, as parameters.
What concerns Lazarus, the internal string communication at the boundaries "Application code <--> LCL", as well as "LCL <--> Widgetsets" is based on the classical (byte oriented) strings. Logically, their contents should be encoded according to the UTF-8.
It is sound to assume that the existing WinXX application base internally does not use UTF-8 encoded strings, but the ISO code page based ones. Any Unicode enabling changes to LCL and widget sets for win32 must not break the existing application base. At the same time they should support applications which are internally based on the Unicode UTF-8 encoded strings, both on older Win9x platforms, as well as on Unicode based >=WinNT platforms.
