Le type C 'char' est 8-bits et restera 8-bits parce qu'il
d�signe la plus petite unit� de donn�es adressable. Divers
am�nagements sont disponibles :
Le standard ISO/ANSI C contient, dans une correction qui fut ajout�e
en 1995, un type de caract�re cod� sur 16 bits
`wchar_t', un ensemble de fonctions comme celles contenues
dans <string.h> et <ctype.h>
(d�clar�es respectivement dans <wchar.h> et
<wctype.h>), et un ensemble de fonctions de conversion
entre `char *' et `wchar_t *' (d�clar�es dans
<stdlib.h>).
Voici de bonnes r�ferences pour cette interface de programmation :
Avantages de cette interface de programmation :
setlocale(LC_ALL,"");.Inconv�nients de cette interface de programmation :
Une variable `wchar_t' peut �tre encod�e en Unicode ou non.
Ceci d�pend de la plateforme et quelquefois aussi des locales.
Une s�quence multi-octets `wchar_t' peut �tre encod�e en
UTF-8 ou non selon la plateforme, et parfois selon les locales.
En d�tails, voici ce que la
Single Unix specification
dit � propos du type `wchar_t' :
Tous les codes de caract�res 16 bits dans un processus donn� consistent en un nombre �gal de bits. Ceci en contraste avec les caract�res, qui peuvent �tre constitu�s d'un nombre variable d'octets. L'octet ou la s�quence d'octets qui repr�sentent un caract�re peuvent aussi �tre repr�sent�s comme un code de caract�re 16 bits. Les codes de caract�res 16 bits fournissent donc une taille uniforme pour manipuler les donn�es textuelles. Un code de caract�re 16 bits ayant tous les bits � 0 est un code de caract�re 16 bits nul (null), et termine une cha�ne. La valeur des caract�res larges pour chaque membre du "Portable Character Set" (i.e ASCII) est �gale quand il est utilis� en tant que seul caract�re dans un caract�re entier (integer) constant. Les codes de caract�res 16 bits pour les autres caract�res d�pendent des locales et de l'impl�mentation. Les octets modificateurs d'�tat n'ont pas de repr�sentation en code de caract�re 16 bits.
Une cons�quence notable est que dans des programmes portables vous ne
devriez pas utiliser des caract�res non-ASCII dans des cha�nes
litt�rales.
Cela signifie que m�me si vous savez que les doubles guillemets ont
les codes U+201C et U+201D, vous ne devriez pas �crire une cha�ne
litt�rale L"\u201cBonjour\u201d, dit il" ou
"\xe2\x80\x9cBonjour\xe2\x80\x9d, dit il" dans des programmes
C. Utilisez plut�t GNU gettext comme cela : gettext ("'Bonjour',
dit il"), et cr�ez une base de donn�es de messages en.UTF-8.po
qui traduit "'Bonjour' dit il" en "\u201cBonjour\u201d, dit
il".
Voici une �tude de la portabilit� des am�nagements ISO/ANSI C sur diverses impl�mentations d'Unix. La GNU glibc-2.2 les supportera tous, mais pour l'instant nous avons le tableau suivant.
Par cons�quent je recommande l'utilisation des fonctions red�marrables et multithread-safe wcsr/mbsr. Oubliez les syst�mes qui ne les ont pas (Irix, HP-UX, Aix), et utilisez le plug-in qui permet d'utiliser des locales UTF-8, libutf8_plug.so (voir ci dessous) sur les syst�mes qui vous permettent de compiler des programmes qui utilisent ces fonctions wcrs/mbsr (Linux, Solaris, OSF/1).
Un avis similaire, donn� par Sun dans http://www.sun.com/software/white-papers/wp-unicode/, section "Internationalized Applications with Unicode", est :
Pour internationaliser correctement une application utilisez les indications suivantes :
Si, pour une raison quelconque, vous devez vraiment supposer que
'wchar_t' est Unicode dans un morceau de code (par exemple, si vous
voulez faire un traitement sp�cial de certains caract�res Unicode),
vous devriez rendre ce bout de code conditionnel selon le r�sultat de
is_locale_utf88(). Autrement vous allez mettre la pagaille
dans le comportement de votre programme sur d'autres plateformes, ou
si d'autres locales sont utilis�es.
La fonction is_locale_utf8() est d�clar�e dans
utf8locale.h
et d�finie dans
utf8locale.c.
Une impl�mentation portable de l'API ISO/ANSI C, qui supporte les locales 8-bits et les locales UTF-8, peut �tre trouv�e dans libutf8-0.5.2.tar.gz
Avantages :
Le syst�me d'exploitation Plan9, une variante d'Unix, utilise UTF-8
comme encodage dans toutes ses applications. Son type de caract�re
large est appel� 'Rune', pas 'wchar_'. Des parties ce ses
biblioth�ques, �crites par Rob Pike et Howard Trikey, sont
disponibles �
ftp://ftp.cdrom.com/pub/netlib/research/9libs/9libs-1.0.tar.gz.
Une autre biblioth�que similaire, �crite par Alistair G. Crook, est �
ftp://ftp.cdrom.com/pub/NetBSD/packages/distfiles/libutf-2.10.tar.gz.
En particulier, chacune de ces biblioth�ques contient un moteur
d'expressions rationnelles qui comprend l'UTF-8.
D�savantages de cette API :
La biblioth�que QT-2.0 http://www.troll.no/ contient la classe QString qui est totalement Unicode. Vous pouvez utiliser les fonctions membres QString::utf8 et QString::fromUtf8 pour convertir depuis/vers un texte encod� en UTF-8. Les fonctions membres QString::ascii et QString::latin1 ne devraient plus �tre utilis�es.
Les biblioth�ques mentionn�es pr�c�demment impl�mentent des versions des concepts ASCII qui comprennent Unicode. Voici des biblioth�ques qui traitent des concepts Unicode, comme titlecase (Une troisi�me casse de lettres, diff�rente des majuscules et des minuscules), la distinction entre la ponctuation et les symboles, la d�composition canonique, les classes combinables, le classement canonique et d'autres choses du m�me genre.
La biblioth�que ucdata de Mark Leisher http://crl.nmsu.edu/~mleisher/ucdata.html s'occupe des propri�t�s des caract�res, de la conversion de la casse, de la d�composition, des classes combin�es.
Ce sont les classes IBM pour Unicode. http://www.alphaworks.ibm.com/tech/icu/. Une biblioth�que tr�s d�taill�e comprenant des cha�nes de caract�res Unicode, des paquets de ressources, des formateurs de nombres, de date, d'heure et de messages, des assemblages, des assembleurs de messages et plus encore. Beaucoup de locales sont support�es. Cette biblioth�que est portable pour Unix et Win32, mais compilera sans intervention ("out of the box") seulement avec la libc6, pas la libc5.
La librairie Unicode de GNOME http://cvs.gnome.org/lxr/source/libunicode/ de Tom Tromey entre autres. Elle couvre la conversion du jeu de caract�res, les propri�t�s des caract�res, la d�composition.
Deux biblioth�ques de conversion qui supportent UTF-8 et un grand nombre de de jeux de caract�res 8-bits, sont disponibles :
ftp://ftp.gnu.org/pub/gnu/glibc/glibc-2.1.1.tar.gz.
Avantages :
ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz.
Avantages :
Probl�mes :
libutf-8, de G.Adam.Stanislav
<adam@whizkidtech.net>
contient quelques fonctions pour la conversion depuis/vers des flux
"FILE*".
http://www.whizkidtech.net/i18n/libutf-8-1.0.tar.gz
Avantages :
Probl�mes :
Java supporte Unicode en interne. Le type 'char' d�signe un caract�re Unicode, et la classe 'java.lang.String' d�signe une cha�ne de caract�res construite � partir de caract�res Unicode.
Java peut afficher n'importe quel caract�re � travers son syst�me de fen�trage AWT, � condition que
Les interfaces java.io.DataInput et java.io.DataOutput contiennent des m�thodes appel�es 'readUTF', et 'writeUTF' respectivement. Mais notez qu'elles n'utilisent pas UTF-8 ; elles utilisent un encodage UTF-8 modifi� : le caract�re NUL est encod� dans une s�quence de deux octets 0xC0 et 0x80 � la place de 0x00, et un octet 0x00 est ajout� � la fin. Encod�es de cette fa�on, les cha�nes peuvent contenir des caract�res NUL mais elles doivent n�anmoins �tre pr�fix�es par un champ de taille. Les fonctions C <string.h> comme strlen() et strcpy() peuvent �tre utilis�es pour les manipuler.
Le standard Lisp ordinaire d�termine deux types de caract�res : 'base-char' et 'character'. C'est � l 'impl�mentation d'ajouter un support Unicode ou non. Ce langage d�termine aussi un mot-clef argument ':external-format' pour 'open' comme place naturelle pour sp�cifier un jeu de caract�res ou un encodage.
Parmi les impl�mentation gratuites du lisp standard, seul CLISP http://clisp.cons.org/ supporte Unicode. Vous aurez besoin d'une version de CLISP datant de juillet 99 ou plus r�cente. ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz Les types "base-char" et "character" sont tous �quivalents au 16-bits Unicode. L'encodage utilis� pour le fichier ou l'I/O socket/pipe peut �tre sp�cifi� par l'argument ':external-format'. Les encodages utilis�s pour les op�rations d'entr�e/sortie sur des ttys et l'encodage par d�faut pour les I/O file/socket d�pendent des locales.
Parmi les impl�mentations commerciales du Lisp standard, seule Eclipse
http://www.elwood.com/eclipse/eclipse.htm
supporte Unicode. Voir
http://www.elwood.com/eclipse/char.htm
Le type 'base-char' est �quivalent � ISO-8859-1, et le type
'character' contient tous les caract�res Unicode.
L'encodage utilis� pour les entr�es/sorties sur un fichier peut �tre
d�fini � travers une combinaison des arguments de 'open'
':element-type' et :'external.format'.
Limitations : les fonctions
d'attributs de caract�res sont d�pendantes des locales. Les sources
et les fichiers de sources compil�s ne peuvent pas contenir des cha�nes
Unicode litt�rales.
L'impl�mentation commerciale du Lisp standard Allegro CL ne contient
pas encore de support Unicode, mais Erik Naggum y travaille.
Ada95 a �t� con�u pour supporter Unicode, et la biblioth�que standard Ada95 contient les types de donn�es sp�ciaux ISO 10646-1 Wide_Character et Wide_String, ainsi que de nombreuses proc�dures et fonctions associ�es. Le compilateur Ada95 GNU (gnat-3.11 ou plus) supporte UTF-8 comme encodage externe des caract�res 16 bits. Cela vous autorise � utiliser UTF-8 � la fois dans le code source et dans les entr�es/sorties de l'application. Pour l'activer dans l'application, utilisez "WCEM=8" dans la cha�ne FORM quand vous ouvrez un fichier, et utilisez l'option du compilateur "-gnatW8" si le code source est UTF-8. Pour plus de d�tails, voyez les manuels de r�f�rence GNAT et Ada95.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:25