<!doctype linuxdoc system>

<article>

<title> HOWTO Unicode
<author>Bruno Haible,<htmlurl url="mailto:haible@clisp.cons.org"
name="&lt;haible@clisp.cons.org&gt;">, traduction~: Samuel Tribehou, 
<htmlurl url="mailto:samuel-tribehou@mail.cpod.fr"
name="&lt;samuel-tribehou@mail.cpod.fr&gt;">
<newline>
<date>v 0.12, 19 Octobre 1999

<abstract>
Ce document explique comment configurer votre système Linux pour qu'il utilise l'encodage de texte UTF-8.
Ce document est en cours d'élaboration. Toutes les astuces, suggestions,
patchs, URLs sont les bienvenus.

NDT~: Il a été convenu avec l'auteur que seule la présente version de
ce document serait traduite dans un premier temps, le contenu
changeant pour l'instant trop souvent pour qu'une traduction suivie
puisse être réalisée. Reportez vous au site du LDP pour obtenir la
dernière version.
</abstract>

<toc>

<sect>Introduction
<p>

<sect1>Pourquoi Unicode~?
<p>
Les gens de différents pays utilisent différents caractères pour représenter 
les mots de leur langue natale. De nos jours la plupart des applications,
y compris les logiciels de courrier électronique  et les navigateurs,
traitent correctement les caractères 8-bits.
Ils peuvent donc traiter et afficher du texte correctement à condition qu'il
soit représenté dans un jeu de caractères 8-bits, comme ISO-8859-1.

Il y a bien plus de 256 caractères dans le monde - pensez au cyrillique,
à l'hébreu, à l'arabe, au chinois, au japonais au coréen et au thaï -, et de temps 
à autres, de nouveaux caractères sont inventés. Les problèmes que cela induit 
pour les utilisateurs sont les suivants ~: 

<itemize>

<item>

Il est impossible de stocker du texte avec des jeux de caractères différents 
dans le même document. Par exemple, je peux citer des journaux russes dans 
une publication allemande ou française si j'utilise TeX, xdvi et Postscript, mais 
je ne peux pas le faire avec du texte pur.

<item>
Tant que chaque document a son propre jeu de caractères, et que la
reconnaissance des jeux de caractères n'est pas automatique, l'intervention
manuelle de l'utilisateur est inévitable. Par exemple, pour voir la
page d'accueil de la distribution Linux XTeamLinux
<htmlurl url="http://www.xteamlinux.com.cn/"
            name="http://www.xteamlinux.com.cn/">,
je dois dire à Netscape que la page web est codée en GB2312.

<item>
De nouveaux symboles comme l'Euro sont inventés. ISO a publié un
nouveau standard ISO-8859-15 qui est en gros identique à
ISO-8859-1, excepté qu'il supprime des caractères rarement utilisés, 
comme le vieux symbole monétaire, remplacé par le signe Euro.
Si les utilisateurs acceptent ce standard, ils auront des documents dans
différents jeux de caractères sur leur disque, et cela deviendra une
préoccupation quotidienne. Mais les ordinateurs devraient simplifier
le choses, pas les compliquer.
</itemize>

La solution à ce problème est l'adoption d'un jeu de caractères
universel. Ce jeu de caractères est Unicode
<htmlurl url="http://www.unicode.org/"
        name="http://www.unicode.org/">.
Pour plus d'informations sur Unicode, faites <tt>man 7 unicode</tt>
(page de man contenue dans le package lpdman-1.20).

<sect1>Les encodages d'Unicode
<p>
Cela réduit le problème de l'utilisateur (devoir jongler entre
différents jeux de caractères) à un problème technique~: comment
transporter les caractères Unicode en utilisant des octets de 8 bits~?
L'unité de 8 bits est la plus petite unité adressable de la plupart
des ordinateurs et c'est aussi l'unité utilisée par les connexions
réseau TCP/IP.
Cependant, l'utilisation d'un octet pour la représentation d'un
caractère est un accident de l'histoire dû au fait que le
développement de l'ordinateur commença en Europe et aux États-Unis,
où l'on pensait que 96 caractères seraient suffisants pour longtemps.

Il y a fondamentalement quatre façons d'encoder des caractères
Unicode dans des octets~:

<descrip>
<tag>UTF-8</tag>
128 caractères sont encodés en utilisant 1 octet~: les caractères
ASCII.<newline>
1920 caractères sont encodé en utilisant deux octets~: le
latin, le grec, le cyrillique, le copte, l'arménien, l'hébreu, les
caractères arabes.<newline>
63488 caractères sont encodés en utilisant 3 octets, le chinois et le
japonais entre autres. <newline>
Les 2147418112 caractères restant (non encore
assignés) peuvent être encodés en utilisant 4, 5 ou 6 caractères.
Pour plus d'informations sur UTF-8, faites <tt>man 7 utf-8</tt> (cette
page est contenue dans le package ldpman-1.20).

<tag>UCS-2</tag>
Chaque caractère est représenté par deux octets. Cet encodage peut
représenter seulement les  65536 premiers caractères d'Unicode.

<tag>UTF-16</tag>
C'est une extension d'UTF-2 qui peut représenter 11144112 caractères
Unicode. Les 65536 premiers caractères sont représentés par deux
octets, les autres par quatre.

<tag>UCS-4</tag>
Chaque caractère est représenté par 4 octets.
</descrip>

L'espace nécessaire pour encoder un texte, comparativement aux encodages
actuellement en usage (8 bits par caractères pour les langues
européennes, plus pour le chinois/japonais/coréen), est le suivant~:
(Cela a une influence sur l'espace disque, et la vitesse des
communications réseau.

<descrip>
<tag>UTF-8</tag>
Pas de changement pour l'ASCII américain, juste quelques pourcents
supplémentaires  pour ISO-8859-1, 50 % de plus pour le
chinois/japonais/coréen, 100 % de plus pour le grec et le
cyrillique.

<tag>UCS-2 et UTF-16</tag>
Pas de changement pour le chinois/japonais/coréen, augmentation de 100
% pour l'US ASCII et ISO-8859-1, le grec et le cyrillique.

<tag>UCS-4</tag>
Augmentation de 100% pour le chinois/japonais/coréen. De 300% pour l'US
ASCII et ISO-8859-1, le grec et le cyrillique.
</descrip>

Étant donné la pénalité pour les documents américains et européens,
causée par UCS-2, UTF-8 et UCS-4, il semble peu probable que ces
encodages aient un potentiel pour une utilisation à grande échelle.
L'API Win32 Microsoft supporte l'encodage UCS-2 depuis 1995 (au
moins), cependant cet encodage n'a pas été largement adopté pour les
documents -SJIS demeure prédominant au Japon.

D'un autre côté UTF-8 a le potentiel pour une utilisation à large
échelle, puisqu'il ne pénalise pas les utilisateurs américains et
européens, et que beaucoup de logiciels de "traitement de texte" (NDT~:
au sens large) n'ont pas besoin d'être changés pour supporter UTF-8.
<newline>
Nous allons maintenant expliquer comment configurer votre système Linux
pour qu'il utilise UTF-8 comme encodage de texte.

<sect2>Notes pour les développeurs C/C++
<p>
L'approche de Microsoft Win32 rend facile pour les développeurs la
production de versions Unicode de leurs programmes~: 
Vous définissez Unicode ("#define UNICODE") au début de votre
programme, et changez alors un grand nombre d'occurrences de
<tt>char</tt> en <tt>TCHAR</tt> jusqu'à ce que votre programme compile
sans Warnings.
Le problèmes est que vous avez au final deux versions de votre
programme~: une qui comprend le texte UCS-2 mais pas les encodages
8-bit, et une autre qui ne comprend que les vieux encodages 8-bit.

En plus, il y a une complication qui affecte UCS-2 et UCS-4~: l'ordre
de la représentation interne des nombre 
(``the endianness''). Le registre de systèmes de codage de caractères de la IANA
dit à l'égard de ISO-10646-UCS-2~: "il faut spécifier l'ordre de la représentation
interne des nombres à l'intérieur du réseau,
le standard ne le spécifie pas". Cette représentation est "big endian"
en contexte réseau, alors que
Microsoft recommande dans ses outils de développement C/C++
d'utiliser une représention dépendante de la machine (c.a.d. "little endian"
sur les processeurs ix86), et d'ajouter une marque de polarité (BOM) au
début du document, ou d'utiliser des heuristiques basées sur la statistique.

D'un autre côté l'approche de UTF-8 garde <tt>char*</tt> comme type
standard pour le stockage des chaînes en C. Il en résulte que votre
programme supportera l'US ASCII, indépendamment de toute variable
d'environnement, et supportera les textes encodés en ISO-8859-1 et
UTF-8 à condition que la variable d'environnement LANG soit
positionnée en conséquence.

<sect1>Liens
<p>
La liste de ressources de Markus Kuhn (mise à jour très
régulièrement)~:
<itemize>
<item>
<htmlurl url="http://www.cl.cam.ac.uk/~mgk25/unicode.html"
        name="http://www.cl.cam.ac.uk/~mgk25/unicode.html">
<item>
<htmlurl url="http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html"
        name="http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html">
</itemize>

Un survol d'Unicode, UTF-8 et des programmes fonctionnant avec UTF-8
de Roman Czyborra~:<newline>
<htmlurl url="http://czyborra.com/utf/#UTF-8"
        name="http://czyborra.com/utf/#UTF-8">

Des exemples de fichiers UTF-8~:
<itemize>
<item>
Les fichiers <tt>quickbrown.txt</tt>, <tt>utf-8-test.txt</tt>,
<tt>utf-8-demo.txt</tt> dans le répertoire <tt>examples</tt> dans le
package ucs-fonts de Markus Kuhn
<newline>
<htmlurl url="http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz"
        name="http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz">
<item>
<htmlurl url="ftp://ftp.cs.su.oz.au/gary/x-utf8.html"
        name="ftp://ftp.cs.su.oz.au/gary/x-utf8.html">
<item>
Le fichier <tt>iso10646</tt> dans le package trans-1.1.1 de Kosta Kosti
<newline>
<htmlurl url="ftp://ftp.nid.ru/pub/os/unix/misc/trans111.tar.gz"
        name="ftp://ftp.nid.ru/pub/os/unix/misc/trans111.tar.gz">
<item>
<htmlurl url="ftp://ftp.dante.de/pub/tex/info/lwc/apc/utf8.html"
        name="ftp://ftp.dante.de/pub/tex/info/lwc/apc/utf8.html">
<item>
<htmlurl url="http://www.cogsci.ed.ac.uk/~richard/unicode-sample.html"
        name="http://www.cogsci.ed.ac.uk/~richard/unicode-sample.html">
</itemize>


<sect>Configuration de l'affichage
<p>
Nous supposons que vous avez déjà adapté votre console Linux et la
configuration de X11 à votre clavier et avez positionné correctement la
variable de localisation LANG.
Ceci est expliqué dans le Danish/International HOWTO, et dans les
autres HOWTOS nationaux~: Finish, French, German, Italian, Polish,
Slovenian, Spanish, Cyrillic, Hebrew, Chinese, Thai, Esperanto.
Mais, s'il vous plaît, ne suivez pas le conseil  donné dans le
Thai-HOWTO vous disant de faire croire que vous utilisez des
caractères ISO-8859-1 (U0000..U00FF) alors que vous tapez des
caractères Thai (U0E01..U0E5B). Faire cela ne vous causera que des
problèmes lorsque vous passerez à Unicode.

<sect1>La console Linux
<p>
Je ne parle pas tellement de la console ici, parce que je ne l'utilise
que pour rentrer mon login, password, et taper <tt>xinit</tt> sur les
machines dépourvues de xdm.

Mais revenons à nos moutons~: le package kbd-0.99 
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/kbd-0.99.tar.gz"
        name="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/kbd-0.99.tar.gz">,
et une version largement étendue, le package console-tools-0.2.2 <newline> 
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-tools-0.2.2.tar.gz"
        name="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-tools-0.2.2.tar.gz">,
contiennent dans le répertoire kbd-0.99/src/ (ou
console-tools-0.22/screenfonttools/) deux programmes~: «unicode_start»
et «unicode_stop». Quand vous appelez «unicode_start», la sortie de la
console est interprétée comme de l'UTF-8. De plus, le clavier est mis en
mode Unicode (voir "man kbd_mode"). Dans ce mode, les caractères
Unicode tapés par Alt-x1...Alt-xn (où x1...xn sont les chiffres de
pavé numérique) seront émis en UTF-8. Si votre clavier, ou plus
précisément, votre keymap a des touches  correspondant à des
caractères non ASCII(comme le Umlaute allemand), que vous souhaiteriez
pouvoir «CapsLocker», vous devez appliquer au kernel le patch 
<htmlurl url="linux-2.2.9-keyboard.diff"
        name="linux-2.2.9-keyboard.diff"> ou
<htmlurl url="linux-2.3.12-keyboard.diff"
        name="linux-2.3.12-keyboard.diff">.

Vous voudrez probablement afficher des caractères de différents
alphabets sur le même écran. Pour cela, vous aurez besoin d'une fonte
Unicode pour la console. <newline>
Le package 
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-data-1999.08.29.tar.gz"
        name="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/console-data-1999.08.29.tar.gz">
contient une fonte (LatArCyrHeb-{08,14,16,19}.psf), qui couvre les
lettres pour le  latin, le cyrillique, l'hébreu, et l'arabe. Il
supporte les parties 1, 2, 3, 4, 5, 6, 8, 9, 10 d'ISO-8859 à lui tout
seul.
Pour l'installer, copiez le dans /usr/lib/kbd/consolefonts/, et
exécutez <newline> 
<tt>/usr/bin/setfont /usr/lib/kbd/consolefonts/LatArCyrHeb-14.psf</tt>.

Si vous voulez que le copier-coller marche avec les consoles UTF-8, vous
aurez besoin du patch 
<htmlurl url="linux-2.3.12-console.diff"
        name="linux-2.3.12-console.diff">
 d'Edmund Thomas, Grimley Evans et Stanislav Voronyi.

<sect1>Fontes étrangères pour X11
<p>
N'hésitez pas à installer des fontes cyrilliques, chinoises,
japonaises, etc. Même si ce ne sont pas des fontes Unicodes, elles
aideront à afficher des documents Unicode~: au moins Netscape
Communicator 4 et Java feront usage des fontes étrangères si elles
sont disponibles.

Les programmes suivants sont utiles pour installer des fontes~: 
<itemize>
<item>
"mkfontdir répertoire" prépare un répertoire de fontes utilisables par
le serveur X. Il doit être exécuté après avoir installé les fontes
dans un répertoire.

<item>
"xset fp+ répertoire" ajoute un répertoire au chemin de fontes actuel du
serveur X. Pour que ce soit permanent, ajoutez une ligne "FontPath" à
votre fichier /etc/XF86Config, dans la section "Files".

<item>
"xset fp rehash" doit être exécuté après avoir appelé mkfontdir sur un
répertoire qui est déjà contenu dans le chemin de fontes actuel du
serveur X.

<item>
"xfontsel" vous permet de parcourir les fontes installées en
filtrant selon les diverses propriétés des fontes.

<item>
"xlsfonts -fn motif-de-recherche" liste toutes les fontes qui
correspondent à un motif de recherche. Il affiche aussi diverses
propriétés des fontes. En particulier, "xlsfonts -ll -fn fonte" liste
les propriétés de la fonte CHARSET_REGISTRY et  CHARSET_ENCODING, qui
ensemble déterminent l'encodage de la fonte.

<item>
"xfd -fn fonte" affiche une fonte page par page.
</itemize>

Les fontes suivantes sont disponibles gratuitement (liste non exhaustive)~:

<itemize>
<item>
Celle contenues dans XFree86, quelquefois contenues dans un package
séparé. Par exemple, la SuSE a seulement les fontes 75 dpi normales
dans le package "xf86" de base. Les autres fontes sont dans les packages
"xfnt100", "xfntbig", "xfntcyr", "xfntscl".

<item>
Les fontes internationales pour Emacs,~
    <htmlurl url="ftp://ftp.gnu.org/pub/gnu/intlfonts/intlfonts-1.1.tar.gz"
            name="ftp://ftp.gnu.org/pub/gnu/intlfonts/intlfonts-1.1.tar.gz">.
Comme il a été mentionné précédemment, elles sont utiles même si vous
préférez XEmacs à GNU Emacs,  ou même si vous n'utilisez pas Emacs du
tout.
</itemize>

<sect1>Les fontes Unicode pour X11
<p>
Les applications qui souhaitent pouvoir afficher du texte utilisant
différentes alphabets (comme le cyrillique et le grec) en même
temps, peuvent le faire en utilisant les différentes fontes X pour
chaque partie de texte.
C'est ce que font Netscape Communicator et Java. Cependant, cette
approche est plus compliquée, parce que au lieu de travailler avec
"Font" et "XFontStruct", le programmeur devra utiliser "XFonSet", et
aussi parce que toutes les fontes dans le jeu de fontes doivent avoir
les mêmes dimensions.

<itemize>
<item>
Markus Kuhn a assemblé des fontes à largeur fixe (fixed width) de
75 dpi avec Unicode couvrant le latin, le grec, le cyrillique,
l'arménien, le géorgien, l'hébreu, et les écritures symboliques.
Elles couvrent les parties 1 à 10 et 13 à 15 de
ISO-8859 en un seul jeu de fontes.
Cette fonte est nécessaire pour utiliser un xterm en mode UTF-8.
  <htmlurl url="http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz"
          name="http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz">

<item>
Roman Czyborra a assemblé une fonte 8x16/16x16  75 dpi avec l'encodage
Unicode couvrant une partie énorme d'Unicode. Teléchargez
unifont.hex.gz et hex2bdf depuis
  <htmlurl url="http://czyborra.com/unifont/"
          name="http://czyborra.com/unifont/">
Elle n'est pas à largeur fixe~: 8 pixels de large pour les caractères
européens, 16 pour les caractères chinois. Instructions
d'installation~:
<tscreen><verb>
$ gunzip unifont.hex.gz
$ hex2bdf < unifont.hex > unifont.bdf
$ bdftopcf -o unifont.pcf unifont.bdf
$ gzip -9 unifont.pcf
$ cp unifont.pcf.gz /usr/X11R6/lib/X11/fonts/misc
$ cd usr/X11R6/lib/X11/fonts/misc
$ mkfontdir
$ xset fp rehash
</verb></tscreen>

<item>
Primoz Peterlin a assemblé un famille de fontes ETL couvrant le
latin, le grec, le cyrillique, l'arménien, le géorgien, et l'hébreu.
  <htmlurl url="ftp://ftp.x.org/contrib/fonts/etl-unicode.tar.gz"
          name="ftp://ftp.x.org/contrib/fonts/etl-unicode.tar.gz">.
Utilisez le programme "bdftopcf" pour l'installer.
</itemize>

<sect1>Unicode xterm
<p>
xterm fait partie de X11R6 et XFree86,  mais il est maintenu
séparément par Tom Dickey.<newline>
<htmlurl url="http://www.clark.net/pub/dickey/xterm/xterm.html"
        name="http://www.clark.net/pub/dickey/xterm/xterm.html">.
Les nouvelles versions (patch niveau 109 et plus) supportent la
conversion des touches (keystrokes) en UTF-8 avant de les envoyer à 
l'application qui tourne dans le xterm, et l'affichage des caractères
Unicode que l'application renvoie comme une séquence d'octets UTF-8.

Pour obtenir un xterm UTF-8 fonctionnel, vous devez~:

<itemize>
Rapatrier
  <htmlurl url="http://www.clark.net/pub/dickey/xterm/xterm.tar.gz"
          name="http://www.clark.net/pub/dickey/xterm/xterm.tar.gz">.

<item>
Le configurer en exécutant "./configure -enable-wide-chars...", puis
le compiler et l'installer.

<item>
Avoir une fonte Unicode à largeur fixe installée. ucs-fonts.tar.gz de
Markus Kuhn (voir ci-dessus) est fait pour ça.

<item>
Lancer "xterm -u8 -fn fixed". L'option "-u8" enclenche le support
d'Unicode et d'UTF-8. La fonte "fixed" est celle de Markus Khun.

<item>
Jeter un oeil aux fichiers-exemples contenus dans le package ucs-fonts
de Markus Khun~:~

<tscreen><verb>
$ cd .../ucs-fonts
$ cat quickbrown.txt
$ cat utf-8-demo.txt
</verb></tscreen>

Vous devriez voir (entre autre) des caractères grecs et cyrilliques.

<item>
Pour configurer xterm pour qu'il utilise le support UTF-8 dès le
lancement, ajoutez la ligne "XTerm*utf8:1" à votre
$HOME/.Xdefaults (pour vous seul). Je ne recommande pas de changer 
directement /usr/X11R6/lib/X11/app-defauts/XTerm, parce que vos
changements seront effacés lorsque vous installerez une nouvelle
version de XFree86.

<item>
Si vous avez aussi changé le nom de la fonte, vous aurez besoin d'une
ligne "*VT100*font: votre-fonte" dans votre fichier $HOME/.Xdefaults.
Pour les fontes "fixes" ce n'est pas nécessaire, puisque "fixed" est 
la valeur par défaut de toute façon.
</itemize>

<sect1>Divers
<p>
Un petit programme qui teste si une console Linux est en mode UTF-8
peut être trouvé dans le package
<htmlurl url="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/x-lt-1.18.tar.gz"
        name="ftp://sunsite.unc.edu/pub/Linux/system/keyboards/x-lt-1.18.tar.gz">
de Ricardas Cepas. Ce sont les fichiers testUTF-8.c et testUTF8.c.

<sect>Configuration des locales
<p>

<sect1>Les fichiers et le kernel
<p>
Vous pouvez maintenant utiliser n'importe quel caractère Unicode dans
les noms de fichiers. Ni le kernel ni aucun utilitaire système
ne nécessite de modifications.
Ceci parce que les noms de fichiers dans le kernel peuvent être
n'importe quoi qui ne contient ni octet nul, ni '/' (utilisé
pour délimiter les sous-répertoires).
Quand ils sont encodés en utilisant UTF-8, les caractères non-ASCII ne
seront jamais encodés en utilisant un octet nul ou un slash.
La seule conséquence est que les noms de fichiers et de répertoires
occupent plus d'octets qu'ils ne contiennent de caractères.
Par exemple, un nom de fichier contenant cinq caractères grecs
apparaîtra pour le kernel comme un nom de fichier de 10 octets.
Le kernel ne sait pas (et n'a pas besoin de savoir) que ces octets sont
affichés en grec.

C'est une théorie générale, qui est vraie tant que vos fichiers restent
sur un système Linux.
Sur les systèmes de fichiers utilisés depuis d'autres
systèmes d'exploitation,  <tt>mount</tt> possède des options pour contrôler la
conversion des noms de fichiers de/vers UTF-8~:

<itemize>
<item>
Les systèmes de fichiers "vfat" ont  une option "utf8".<newline>
Voir le fichier
 <htmlurl url="file:/usr/src/linux/Documentation/filesystems/vfat.txt"
                name="file:/usr/src/linux/Documentation/filesystems/vfat.txt">.
Quand vous donnez à mount une option "iocharset" différente de celle
utilisée par défaut (qui est "iso8859-1"), les résultats avec et sans
l'option "utf8" ne sont pas cohérents. Par conséquent, je ne conseille
pas d'utiliser l'option "iocharset" de mount.

<item>
Les systèmes de fichiers "msdos", "umsdos" ont la même option de
montage, mais il semble qu'elle n'ait pas d'effet.

<item>
Le système de fichiers "iso9660" a une option de montage "utf8".<newline>
Voir
 <htmlurl url="file:/usr/src/linux/Documentation/filesystems/isofs.txt"
                name="file:/usr/src/linux/Documentation/filesystems/isofs.txt">

<item>
À partir des kernels Linux 2.2.x, le système de fichier "ntfs" a une
option de montage"utf8". <newline>
Voir
    <htmlurl url="file:/usr/src/linux/Documentation/filesystems/ntfs.txt"
            name="file:/usr/src/linux/Documentation/filesystems/ntfs.txt">
</itemize>

Les autres systèmes de fichiers (nfs, smbfs, ncpfs, hpfs, etc.) ne
convertissent pas les noms de fichiers. Par conséquent ils
accepteront les noms de fichier Unicode encodés en UTF-8 seulement si
l'autre système d'exploitation les supporte.
Rappelez vous que pour qu'une option de montage soit appliquée aux
prochains montages,  vous devez l'ajouter à la quatrième colonne de la
ligne correspondante dans /etc/fstab.

<sect1>Le kernel et les ttys
<p>
Les ttys sont en quelque sorte des tubes bidirectionnels entre deux
programmes, autorisant des choses comme la répétition (echoing) ou
l'édition de la ligne de commande.
Quand dans un xterm, vous exécutez la commande "cat" sans arguments, 
vous pouvez entrer et éditer autant de lignes que vous voulez, elles
seront répétées en retour ligne par ligne.
Les actions d'édition du kernel ne sont pas correctes, en particulier les
touche Backspace et Tab ne seront pas traitées correctement.

Pour résoudre ce problème, vous devez~:

<itemize>
<item>
Appliquer le patch 
  <htmlurl url="linux-2.0.35-tty.diff"
          name="linux-2.0.35-tty.diff">
ou
  <htmlurl url="linux-2.2.9-tty.diff"
          name="linux-2.2.9-tty.diff">
ou
  <htmlurl url="linux-2.3.12-tty.diff"
          name="linux-2.3.12-tty.diff">
et recompiler votre kernel.

<item>
Si vous utilisez la glibc2, appliquer le patch 
  <htmlurl url="glibc211-tty.diff"
          name="glibc211-tty.diff">
et recompiler votre libc. Si vous n'êtes pas aussi aventureux, 
il suffit de patcher une version déjà installée avec le
fichier inclus~:
  <htmlurl url="glibc-tty.diff"
          name="glibc-tty.diff">

<item>
Appliquer le patch <htmlurl url="stty.diff"
                          name="stty.diff">
à GNU sh-utils-1.16b, et recompiler le programme <tt>stty</tt>. Testez le
ensuite en utilisant <tt>stty -a</tt> et <tt>stty iutf8</tt>.

<item>
Ajouter la commande <tt>stty iutf8</tt> au script unicode_start, et la
commande <tt>stty -iutf8</tt> au script unicode_stop.

<item>
Appliquer le patch <htmlurl url="xterm.diff"
                          name="xterm.diff">
à xterm-109, et recompiler "xterm", puis le tester en lançant 
<tt>xterm -u8</tt> / <tt>xterm +u8</tt> et en lançant <tt>stty -a</tt>
et un <tt>cat</tt> interactif à l'intérieur.
</itemize>

Pour que ce changement soit persistant même à travers rlogin et
telnet, vous devrez aussi~:

<itemize>
<item>
Définir des nouvelles valeurs pour la variable d'environnement TERM,
"linux-utf8" comme alias pour "linux", et "xterm-utf8" comme alias
pour "xterm". Si vous avez la bibliothèque ncurses sur votre système et
la base de données /usr/lib/terminfo (ou /usr/share/terminfo), faites
cela en éxecutant
<tscreen><verb>
$ tic linux-utf8 . terminfo
$ tic xterm-utfu . terminfo
</verb></tscreen>
sur un compte utilisateur (cela créera les entrées terminfo dans votre
repertoir $HOME/.terminfo).
Voilà 
  <htmlurl url="linux-utf8.terminfo" name="linux-utf8.terminfo"> et
  <htmlurl url="xterm-utf8.terminfo" name="xterm-utf8.terminfo">.     
<newline>
Je ne recommande pas de lancer ces commandes en tant que root, parce
que cela créera les entrées terminfo dans /urs/lib/terminfo, où, elles
seront probablement effacées lors de la prochaine mise à jour de votre
système.
Si votre système possède un fichier /etc/termcap, vous devriez aussi
éditer ce fichier~: copiez les entrées linux et xterm, et donnez leur
les nouveaux noms "linux-utf8" et "xterm-utf8".
Le fichier~
  <htmlurl url="termcap.diff"
          name="termcap.diff">
contient un exemple.

<item>
À chaque fois que vous appelez "unicode_start" et "unicode_stop"
depuis la console, exécutez aussi "export TERM =linux-utf8", ou 
"export TERM=linux", respectivement.

<item>
Appliquer le patch <htmlurl url="xterm2.diff"
                          name="xterm2.diff">
à xterm-0.9, recompiler "xterm", et et enlever toutes les lignes
"XTerm*termName" des fichiers /usr/X11R6/lib/X11/app-defaults/XTerm 
et $HOME/.Xdefaults. Maintenant xterm donne à TERM la valeur
"xterm-utf8" plutôt que "xterm".

<item>
Appliquer les patches 
  <htmlurl url="netkit.diff"
          name="netkit.diff">,
  <htmlurl url="netkitb.diff"
          name="netkitb.diff">et
  <htmlurl url="telnet.diff"
          name="telnet.diff">
puis recompiler "rlogind" et "telnetd". Maintenant rlogin et telnet
mettent tty en mode d'édition UTF-8 à chaque fois que la variable
d'environnement TERM est "linux-ut8" ou "xterm-utf8".
</itemize>

<sect1>Conversion de données générales
<p>
Vous aurez besoin d'un programme pour convertir vos fichiers texte
locaux (probablement ISO-8859-1) en UTF-8.
L'alternative serait de continuer à utiliser des textes qui utilisent
différents encodages sur la même machine, mais ce n'est pas une bonne
solution sur le long terme.
Un de ces programmes est "iconv", qui est livré avec la
glibc-2.1. Tapez simplement 
<tscreen><verb>
icon --from-code=ISO-8859-1 --to-code=UTF-8 < vieux_fichier > nouveau_fichier
</verb></tscreen>

Voici deux scripts shell très pratiques, appelés~
"i2u" <htmlurl url="i2u.sh" name="i2u.sh"> (pour conversion de ISO à UTF) et~
"u2i" <htmlurl url="u2i.sh" name="u2i.sh"> (pour conversion de UTF à ISO).
[skip adapt..]

Si vous n'avez pas la glibc-2.1 et iconv installés, vous pouvez
utiliser GNU recode 3.5 à la place.
"i2u" <htmlurl url="i2u_recode.sh" name="i2u_recode.sh"> est
"recode ISO-8859-1..UTF-8"
"u2i" <htmlurl url="u2i_recode.sh" name="u2i_recode.sh"> est
"recode UTF-8..ISO-8859-1".
<newline>
<htmlurl url="ftp://ftp.iro.umontreal.ca/pub/recode/recode-3.5.tar.gz"
        name="ftp://ftp.iro.umontreal.ca/pub/recode/recode-3.5.tar.gz">
<newline>
<htmlurl url="ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz"
        name="ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz">
<newline>
Notes~: vous devez utiliser GNU recode 3.5 ou plus. Pour compiler GNU
recode sur des plateformes sans glibc-2 (c'est à dire sur toutes les
plateformes sauf les systèmes Linux récents), vous devez le
configurer avec "--disable-nls", autrement l'édition des liens
échouera.

Sinon, vous pouvez aussi utiliser CLISP à la place.
Voici "i2u" et "u2i" en version lisp~: <htmlurl url="i2u.lsp" name="i2u.lsp"> et
<htmlurl url="u2i.lsp" name="u2i.lsp">.
<newline>
Note~: Vous devez avoir une version de CLISP qui date au plus de juillet 1999.
<newline>
<htmlurl url="ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz"
        name="ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz">
<newline>
D'autres programmes de conversion de données existent, mais ils sont
moins puissants que GNU recode. Ce sont 
<itemize>

<item>"trans"
<newline>
<htmlurl url="ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/trans113.tar.gz"
        name="ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/trans113.tar.gz">

<item>
"tcs" qui vient du système d'exploitation Plan9~:
<newline>
<htmlurl url="ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/tcs.tar.gz"
        name="ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/charsets/tcs.tar.gz">

<item>
et "utrans/uhtrans/hutrans" par G.Adam Stanislav~
<htmlurl url="mailto:adam@whizkidtech.net"
           name="&lt;adam@whizkidtech.net&gt;">
<newline>
<htmlurl url="ftp://ftp.cdrom.com/pub/FreeBSD/distfiles/i18ntools-1.0.tar.gz"
        name="ftp://ftp.cdrom.com/pub/FreeBSD/distfiles/i18ntools-1.0.tar.gz">
</itemize>

<sect1>Les variables d'environnement locales
<p>
Vous pouvez avoir les variables d'environnement suivantes
positionnées, contenant les noms de locales~: 

<descrip>
<tag>LANGUAGE</tag>
Remplacement pour LC_MESSAGES. Seulement utilisé par GNU gettext.

<tag>LC_ALL</tag>
Remplacement pour toute les autres variables LC_*~:~

<tag>LC_CTYPE, LC_MESSAGES, LC_COLLATE, LC_NUMERIC, LC_MONETARY, LC_TIME</tag>

Ce sont des variables individuelles pour~: le type des caractères et
leur encodage, les messages en langue maternelle, les règles de
classement, le format des nombres, le format des montants monétaires,
l'affichage de la date et de l'heure.

<tag>LANG</tag>
Valeur par défaut pour toutes les variables LC_*
</descrip>
(Voir `<tt>man 7 locale</tt>' pour une description détaillée.)

Chacune des variables LC_* et LANG peuvent contenir un nom de locale
de la forme suivante~:
<quote>
language[_territory[.codeset]][@modifier]
</quote>

Où <em>language</em> est un code de langue <htmlurl url="ISO_639" name="ISO 639"> 
(en minuscules), <em>territory</em> est un code de pays <htmlurl url="ISO_3166"
name="ISO 3166">
(en majuscules), <em>codeset</em> désigne une table de caractères, et <em>modifier</em>
d'autres attributs particuliers (par pour exemple indiquer un dialecte
particulier d'une langue, ou une orthographe non standard).

LANGUAGE peut contenir plusieurs noms de locale, séparés  par deux
points (:).

Pour dire à votre système et à toutes les applications que vous
utilisez UTF-8, vous devez ajouter un suffixe d'UTF-8 à vos noms de
locales. Par exemple, si vous utilisiez
<tscreen><verb>
LANGUAGE=de:fr:en
LC_CTYPE=de_DE
</verb></tscreen>

vous le changeriez en
<tscreen><verb>
LANGUAGE=de.UTF-8:fr.UTF-8:en.UTF-8
LC_CTYPE=de_DE.UTF-8
</verb></tscreen>

<sect1>Créer les fichiers pour le support des locales
<p>
Si vous avez la glibc-2.1 ou glibc-2.1.1 ou glibc-2.1.2 installée,
vérifiez d'abord en utilisant "localedef -help" que le répertoire
système pour le tables de caractères est /usr/share/i18n/charmaps.
Puis appliquez au fichier /usr/share/i18n/charmaps/UTF8 le patch
<htmlurl url="glibc21.diff" name="glibc21.diff">
ou <htmlurl url="glibc211.diff" name="glibc211.diff">
ou <htmlurl url="glibc212.diff" name="glibc212.diff">, respectivement.
Puis créez les fichiers de support pour toute les locales UTF-8 que
vous voulez utiliser, par exemple~: 

<tscreen><verb>
$ localedef -v -c -i de_DE -f UTF8 /usr/share/locale/de_DE.UTF-8
</verb></tscreen>

Généralement vous n'avez pas besoin de créer des variables appelées
"de" ou "fr" sans suffixe pour le code du pays, parce que ces
locales sont normalement utilisées seulement par la variable LANGUAGE,
et pas par les variables LC_*. De plus LANGUAGE est seulement utilisé
en remplacement de LC_MESSAGES.

<sect1>Ajouter le support pour la bibliothèque C
<p>
La glibc-2.2 supportera les locales multi-octets (de plusieurs
octets), en particulier les
locales UTF-8 créées plus haut. Mais les glibc-2.1 et 2.1.1 ne la
supportent pas réellement. Par conséquent le seul effet réel de la
création des fichiers /usr/local/share/de_DE.UTF-8/* ci dessus est que
<tt>setlocale(LC_ALL,"")</tt> retournera "de_DE.UTF-8", conformément à vos
variables d'environnement, au lieu d'enlever le suffixe "UTF-8".

Pour ajouter le support pour la locale UTF-8, vous devriez compiler et
installer la bibliothèque 'libutf8_plug.so', depuis
<htmlurl url="libutf8-0.5.2.tar.gz"
        name="libutf8-0.5.2.tar.gz">.
Puis vous pouvez positionner la variable d'environnement LD_PRELOAD
pour qu'elle pointe sur la bibliothèque installée~:
<tscreen><verb>
export LD_PRELOAD=/usr/local/lib/libutf8_plug.so
</verb></tscreen>
Alors, dans chaque programme lancé avec cette variable d'environnement
positionnée, les fonctions de libutf8_plug.so seront appelées à la
place des originales dans /lib/libc.so.6. Pour plus d'informations sur
LS_PRELOAD, voyez "man 8 ld.so".

Tout cela ne sera plus nécessaire quand la glibc-2.2 sortira.

<sect1>Conversion des catalogues de messages
<p>
Maintenant ajoutons un contenu à ces nouvelles locales. Les commandes
/bin/sh suivantes convertiront vos catalogues de messages au format
UTF-8. Elles doivent être lancées en tant que root, et nécessitent les
programmes 'msgfmt' et 'msgunfmt' de GNU gettext-0.10.35
<htmlurl url="convert-msgcat.sh"
        name="convert-msgcat.sh">. <newline>
Ceci non plus ne sera plus nécessaire une fois que la glibc-2.2 sera
sortie, parce qu'alors la fonction gettext convertira les chaînes de
caractères de façon appropriée depuis la table de caractères du
traducteur vers la table de caractères de l'utilisateur, en
utilisant soit iconv soit librecode.

<sect>Applications spécifiques.
<p>

<sect1>Le réseau
<p>

<sect2>rlogin
<p>
Marche bien avec les patches mentionnés précédemment.

<sect2>telnet
<p>
Telnet n'est pas ne traite pas les caractères 8-bits (il n'est
pas"8-bit-clean") par défaut. Pour pouvoir envoyer des
codes de touches Unicode à un hôte distant, vous devez mettre telnet
en mode "outbinary". Il y a deux façons de faire cela~:~

<tscreen><verb>
$ telnet -L <hote>
</verb></tscreen>

et

<tscreen><verb>
$telnet
telnet> set outbinary
telnet> open <hote>
</verb></tscreen>

en outre, utilisez les patches mentionnés précédemment.

<sect1>Les navigateurs
<p>

<sect2>Netscape
<p>
Netscape 4.05 ou plus peut afficher des documents HTML en encodage
UTF-8. Tout ce qu'un document nécessite est la ligne suivante, située
entre les tags &lt;head&gt; et &lt;/head&gt;
<tscreen><verb>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</verb></tscreen>
Netscape 4.05 ou plus peut aussi afficher du HTML et du texte en
encodage UCS-2 avec le [byte-order mark].
<htmlurl url="http://www.netscape.com/computing/download/"
        name="http://www.netscape.com/computing/download/">

<sect2>Lynx
<p>
Lynx 2.8 a un écran d'options (touche 'O') qui permet de sélectionner
la table de caractères utilisée à l'affichage. Quand il, tourne dans
un xterm ou depuis une "Linux console" en mode UTF-8, sélectionnez
"UNICODE UTF-8".

Maintenant, encore une fois, tout ce qu'un document nécessite est la
ligne suivante, entre les tags &lt;head&gt; et &lt;/head&gt;~:
<tscreen><verb>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</verb></tscreen>

Quand vous visualisez des fichiers texte encodés en UTF-8, vous devez
aussi passer à la ligne de commande  l'option~
"-assume_local_charset=UTF-8" (affecte seulement les URLs de type
file:/...) ou "-assume_charset=UTF-8" (affecte toute les
URLs). Sinon, 
dans Lynx-2.2.8, vous pouvez, dans l'écran d'options,  changer le jeu de
caractères supposé par défaut ("assumed document character set") en "utf-8".

Il y a aussi, dans l'écran d'options, une option permettant de
choisir le jeu de caractères par défaut ("preferred document character
set"),  mais cela n'a pas d'effet, au moins avec les URLs
file:/... et http://... servies par apache-1.3.0.

Cependant, il y a un problème concernant les espaces et les fins de
lignes : regardez à la section russe de x-utf-8.html, ou utf-8-demo.txt.

Notez aussi que dans Lynx-2.8.2, configuré avec l'option
-enable-prettysrc, les jolies combinaisons de couleurs ne marchent plus
correctement quand le jeu de caractères pour l'affichage à été
positionné à "UNICODE-UTF-8". Ce problème est résolu par le patch 
<htmlurl url="lynx282.diff" name="lynx282.diff">.

D'après les développeurs de lynx~: "Pour une utilisation sérieuse de
l'affichage UTF-8 avec Lynx, il est toujours recommandé de compiler avec la
bibliothèque slang et -DSLANG_MBCS_HACK."
<newline>
<htmlurl url="ftp://ftp.gnu.org/pub/gnu/lynx/lynx-2.8.2.tar.gz"
        name="ftp://ftp.gnu.org/pub/gnu/lynx/lynx-2.8.2.tar.gz">
<newline>
<htmlurl url="http://lynx.browser.org/"
        name="http://lynx.browser.org/">
<newline>
<htmlurl url="http://www.slcc.edu/lynx/"
        name="http://www.slcc.edu/lynx/">
<newline>
<htmlurl url="ftp://lynx.isc.org/"
        name="ftp://lynx.isc.org/">

<sect2>Pages de test
<p>
Des pages de test pour les navigateurs peuvent être trouvées sur les
pages d'Alan Wood et James Kass ~:<newline>
<htmlurl url="http://www.hclrss.demon.co.uk/unicode/#links"
        name="http://www.hclrss.demon.co.uk/unicode/#links">,
<htmlurl url="http://home.att.net/~jameskass/"
        name="http://home.att.net/~jameskass/">


<sect1>Les éditeurs
<p>

<sect2>yudit
<p>
Le programme <tt>yudit</tt> de Gáspár Sinai
<htmlurl url="http://czyborra.com/yudit/"
        name="http://czyborra.com/yudit/">
est un éditeur de texte unicode de premier ordre pour le système X
Window.
Il supporte le traitement simultané de beaucoup de langages, méthodes
d'entrée, conversions de caractères locaux standards.
Il est équipé pour supporter l'entrée de texte dans tous les langages
avec seulement un clavier anglais, en utilisant des tables de
configuration du clavier.

Il peut être compilé en 3 versions~: interface graphique Xlib , KDE, ou
Motif.

Il peut être personnalisé très facilement. Typiquement, vous voudrez
modifier votre fonte. Depuis le menu font je choisis "Unicode". Puis,
puisque la commande "xlsfonts '*_*-iso10646-1" donnait toujours un
affichage ambigu, je choisis un taille de fonte de 13 (pour correspondre à
la fonte fixe de 13 pixels de Markhus Kuhn).

Ensuite, vous personnaliserez votre méthode d'entrée. Les méthodes
"Straight", "Unicode" et "SGML" sont les plus intéressantes. Pour
avoir des détails sur les autres méthodes d'entrées incorporées,
regardez dans "/usr/local/share/yudit/data/".

Pour qu'un changement devienne un réglage par défaut pour les
prochaines sessions, éditez votre fichier $HOME/.yuditrc.

Les fonctionnalités générales de l'éditeur sont limitées à l'édition,
le copier-coller, et le "chercher-remplacer" (search&amp;replace).
Pas de fonction d'annulation (undo).

<sect2>mined98
<p>
<tt>mined98</tt> est un petit éditeur de texte de Michiel Huisjes, Achim Müller
et Thomas Wolff :
<htmlurl url="http://www.inf.fu-berlin.de/~wolff/mined.html"
        name="http://www.inf.fu-berlin.de/~wolff/mined.html">.
Il vous permet d'éditer des fichier encodés en UTF-8 ou 8 bits, dans un
xterm UTF-8 ou 8-bits.
Il dispose aussi de puissantes fonctionnalités pour entrer les
caractères Unicode.

Quand mined est lancé  dans un xterm ou une console Linux en mode
UTF-8, vous devriez positionner la variable d'environnement
<tt>utf8_term</tt>, ou appeler mined avec l'option <tt>-U</tt>.

mined vous permet d'éditer des fichiers encodés aussi bien en UTF-8
qu'en 8-bits. Par défaut il utilise un heuristique d'auto-détection.
Si vous ne voulez pas vous reposer sur des heuristiques, passez
l'option <tt>-u</tt> à la ligne de commande lorsque vous éditez un fichier
UTF-8, ou <tt>+u</tt> lorsque vous éditez un fichier encodé en 8 bits.
Vous pouvez changer l'interprétation à n'importe quel moment depuis
l'éditeur~: il affiche l'encodage ("L:h" pour du 8-bits, "U:h" pour de
l'UTF-8) dans la ligne de menu. Vous pouvez cliquer sur le premier de
ces caractères pour le changer.

Quelques bémols~: 
<itemize>
<item>
Le binaire Linux dans la distribution est dépassé et ne supporte pas
UTF-8. Vous devrez recompiler un binaire à partir des
sources. Installez ensuite src/mined dans /usr/local/bin/mined et
doc/mined.help dans /usr/local/man/cat1/mined.1, de façon à ce que
<tt>ESC h</tt> le trouve.

<item>
mined ignore votre réglage "stty erase". Quand votre touche backspace
renvoie un code ASCII 127, et que vous avez positionné "stty erase
^?" - ce qui est finalement le réglage le plus sûr - vous devez
appeler mined avec l'option <tt>-B</tt> de façon à ce que la touche
backspace efface le caractère à gauche du curseur.

<item>
Les touches "Home", "End", "Delete" ne marchent pas.

</itemize>

<sect2>vim
<p>
<tt>vim</tt> (depuis la version 5.4m) supporte les locales multi-octets, mais
seulement si la bibliothèque X a le même support, et seulement pour
les encodages avec au moins deux octets par caractères, i.e les encodages
ISO-2022. Il ne supporte pas l'UTF-8.

<sect2>emacs
<p>
Avant tout, vous devriez lire la section "International Character Set
Support" (noeud "International") dans le manuel d'Emacs. En
particulier, notez que vous devez démarrer Emacs avec la commande
<tscreen><verb>
$ emacs -fn fontset-standard
</verb></tscreen>
pour qu'il utilise un jeu de fontes comprenant beaucoup de caractères
internationaux.

À court terme, le package emacs-utf 
<htmlurl url="http://www.cs.ust.hk/faculty/otfried/Mule/"
        name="http://www.cs.ust.hk/faculty/otfried/Mule/">
d'Otfried Cheong procure un "unicode-utf-8" pour Emacs. Après avoir
compilé le programme "utf2mule" et l'avoir installé quelque part dans
votre $PATH, installez aussi unicode.el, muleuni-1.el, unicode_char.el
quelque part, et ajoutez les lignes 
<tscreen><verb>
     (setq load-path (cons "/home/user/somewhere/emacs" load-path))
     (if (not (string-match "XEmacs" emacs-version))
       (progn
         (require 'unicode)
         (if (eq window-system 'x)
           (progn
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-12-*-*-*-*-*-fontset-standard")
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-13-*-*-*-*-*-fontset-standard")
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-14-*-*-*-*-*-fontset-standard")
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-15-*-*-*-*-*-fontset-standard")
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard")
             (create-fontset-from-fontset-spec
               "-misc-fixed-medium-r-normal-*-18-*-*-*-*-*-fontset-standard")))))
</verb></tscreen>

à votre $HOME/.emacs. Pour activer un des jeux de fontes, utilisez
l'item "Set Font/FonSet" du menu mule, ou Shift-down-mouse-1.
Pour l'instant les jeux de fontes avec des hauteurs de 15 et 13 ont le
meilleur support Unicode, grâce aux fontes 9x15 et 6x13 de Markus
Kuhn. Pour ouvrir un fichier encodé en UTF-8, vous pouvez taper
<tscreen><verb>
M-x universal-coding-system-argument unicode-utf8 RET
M-x find-file filename RET
</verb></tscreen>
ou
<tscreen><verb>
C-x RET c unicode-utf8 RET
C-x C-f filename RET
</verb></tscreen>

Notez que cela marche avec Emacs seulement en mode fenêtre, pas en
mode terminal.

Richard Stallman prévoit à long terme d'ajouter un support d'UTF-8
intégré à Emacs.

<sect2>Xemacs
<p>

(Cette section est écrite par Gilbert Baumann.)

Voici comment apprendre à XEmacs (20.4 configuré avec MULE) l'encodage
UTF-8. Malheureusement vous aurez besoin des sources pour pouvoir le patcher.

D'abord vous aurez besoin de ces fichiers fournis par Tomohiko
Morioka~: 

<htmlurl url="http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-21.0-b55-emc-b55-ucs.diff"
        name="http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-21.0-b55-emc-b55-ucs.diff">

<htmlurl url="http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-ucs-conv-0.1.tar.gz"
        name="http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/xemacs-ucs-conv-0.1.tar.gz">

Le .diff est un diff pour les sources C. Le tarball contient du code
elisp, qui fournit beaucoup de tables de code qui permettent la
conversion depuis et vers Unicode. Comme le nom du diff le suggère,
il est prévu pour XEmacs-21. J'ai eu besoin d'aider un peu 'patch'.
La différence la plus notable avec mes sources XEmacs-20.4 est que
file-coding.[ch] était appelé mule-coding.[ch]

Pour ceux qui connaissent peu XEmacs-MULE (comme moi) voici un guide
rapide~: 

Ce que nous appelons un encodage est appelé par MULE "coding
system". Les commandes les plus importantes sont~: 

<tscreen><verb>
M-x set-file-coding-system
M-x set-buffer-process-coding-system [comint buffer]
</verb></tscreen>

et la variable 'file-coding-system-alist', qui guide 'find-file' pour
qu'il trouve l'encodage utilisé. Une fois que tout marchait, la
première chose que j'ai faite fut 
<url url="gb-hacks.el" name="ceci">.

Ce code cherche une ligne de mode spéciale commençant par _*_ quelque
part dans les 600 premiers octets du fichier qui va être ouvert. Si
cette ligne contient un champ "Encoding: xyz;" et que l'encodage xyz
("coding system" dans le langage d'Emacs) existe, il le sélectionne.
Donc maintenant vous pouvez utiliser~: 

<tscreen><verb>
;;;  _*_ Mode: Lisp; Syntax: Common-Lisp; Package: CLEX; Encoding:
utf-8; _*_
</verb></tscreen>

et Emacs entrera en mode utf-8 à partir de là.

Une fois que tout marchait, j'ai défini une macro pour \u03BB (lambda
grec) comme ceci~:~

<tscreen><verb>
(defmacro \u03BB (x) '(lambda .,x))
</verb></tscreen>

<sect2>nedit
<p>

<sect2>xedit
<p>
En théorie, <tt>xedit</tt> devrait être capable d'éditer des fichiers UTF-8 si
vos locales sont configurées en conséquence (voir au dessus), et que
vous ajoutez la ligne "Xedit*international: true" à votre fichier
$HOME/.Xdefaults.~
En pratique, il reconnaîtra les encodages UTF-8 des caractères non
ASCII, mais il les affichera comme des séquences de caractères "@".

<sect2>axe
<p>
En théorie, <tt>axe</tt> devrait être capable d'éditer des fichiers UTF-8 si
vos locales sont configurées en conséquence (voir au dessus), et que 
vous ajoutez la ligne "Axe*International: true" à votre fichier
$HOME/.Xdefaults.
En pratique, il vous laissera simplement un joli fichier core.

<sect2>pico
<p>

<sect2>TeX
<p>
Les distributions de teTex 0.9 (et supérieures) contiennent  une
adaptation Unicode de TeX, appelée Omega
(<htmlurl url="http://www.gutenberg.eu.org/omega/"
         name="http://www.gutenberg.eu.org/omega/">
<htmlurl url="ftp://ftp.ens.fr/pub/tex/yannis/omega"
        name="ftp://ftp.ens.fr/pub/tex/yannis/omega">), 
mais est-ce que quelqu'un connaîtrait un tutorial sur ce système~?

Autres liens peut-être en rapport~:<newline>
<htmlurl url="http://www.dante.de/projekte/nts/NTS-FAQ.html"
        name="http://www.dante.de/projekte/nts/NTS-FAQ.html">,<newline>
<htmlurl url="ftp://ftp.dante.de/pub/tex/language/chinese/CJK/"
        name="ftp://ftp.dante.de/pub/tex/language/chinese/CJK/">

<sect1>Les logiciels de courrier électronique
<p>
MIME~: RFC 2279 définit les jeux de caractères UTF-8 et MIME, qui peuvent être
convertis en encodage 8-bits, quoted-printable ou base64. L'ancienne
norme MIME UTF-7 (RFC 2152) est considérée comme étant obsolète ("deprecated")
et ne devrait plus être utilisée.

Les clients mail sortis après le 1er janvier 1999 devraient être
capables d'envoyer et d'afficher des courriers encodés en UTF-8, sous peine
d'être considérés comme incomplets. Mais ces courriers doivent contenir
les étiquettes (labels) MIME~: 

<tscreen><verb>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8-bit
</verb></tscreen>

Envoyer simplement un fichier UTF-8 vers "mail" via un <em>pipe</em>
sans faire attention aux labels MIME ne fonctionnera pas.
Les gens qui implémentent des clients de courrier devraient jeter un
oeil à 
<htmlurl url="http://www.imc.org/imc-intl/"
        name="http://www.imc.org/imc-intl/">
et
<htmlurl url="http://www.imc.org/mail-i18n.html"
        name="http://www.imc.org/mail-i18n.html">

Parlons maintenant des clients mail  individuels (ou "mail user agents")~:

<sect2>pine
<p>
La situation pour une version non patchée  de pine 4.10 est la suivante.

Pine ne fait pas de conversion de jeu de caractères. Mais il vous
permet de voir des courriers UTF-8 dans une fenêtre texte UTF-8 (console
Linux ou xterm).

Normalement, Pine se plaindra du fait qu'il y a différents jeux
de caractères à chaque fois que vous visualiserez un courrier encodé
en UTF-8. Pour vous débarrasser de cet avertissement, choisissez S
(setup), puis C (config), et changez la valeur de "character set" à
UTF-8.
Cette option ne fera rien à part réduire le nombre d'avertissements,
puisque Pine ne connaît pas UTF-8 en interne.

Notez aussi que pour Pine la notion de caractères Unicode est très
limitée~: il affichera les caractères latins et grecs, mais ce sont
les seuls types de caractères Unicode qu'il connaît.

Un patch de Robert Brady 
<htmlurl url="http://www.ents.susu.soton.ac.uk/~robert/pine-utf8-0.1.diff"
        name="http://www.ents.susu.soton.ac.uk/~robert/pine-utf8-0.1.diff">
ajoute à Pine un support UTF-8. Avec ce patch, il peut décoder et
afficher les entêtes et le corps des messages correctement.
Ce patch nécessite GNOME libunicode
<htmlurl url="http://cvs.gnome.org/lxr/source/libunicode/"
        name="http://cvs.gnome.org/lxr/source/libunicode/">.

<sect2>Kmail
<p>
Kmail (comme tout KDE 1.0) ne contient absolument aucun support pour
les mails en UTF-8.

<sect2>Netscape Communicator
<p>
Le Messenger de Netscape Communicator peut envoyer et afficher des
mails encodés en UTF-8, mais cela nécessite quelques interventions
manuelles de l'utilisateur.

Pour envoyer un mail encodé en UTF-8~: après avoir ouvert la fenêtre
"Compose", mais avant de commencer à composer le message, sélectionnez
dans le menu 
"View -> Character Set ->Unicode (UTF-8)" puis composez votre message
et envoyez le.

Quand vous recevez un courrier encodé en UTF-8, Netscape
ne l'affiche malheureusement pas en UTF-8 directement, et ne donne même
pas un indice visuel montrant que le courrier a été encodé en
UTF-8. Vous devez sélectionner manuellement l'option adéquate dans
"View -> Character Set -> Unicode (UTF-8)".
Pour afficher les courriers UTF-8, Netscape utilise des fontes
différenciées.
Vous pouvez ajuster la fonte utilisée dans la boîte de dialogue
"Edit -> Preferences -> Fonts". Choisissez la catégorie de fontes "Unicode".

<sect2>Emacs (rmail, vm)
<p>

<sect1>Autres applications en mode texte
<p>

<sect2>less
<p>
Teléchargez 
<htmlurl url="ftp://ftp.gnu.org/pub/gnu/less/less-340.tar.gz"
        name="ftp://ftp.gnu.org/pub/gnu/less/less-340.tar.gz">
et appliquez le patch
<htmlurl url="less-340-utf-2.diff"
        name="less-340-utf-2.diff">
de Robert Brady
<htmlurl url="mailto:rwb197@ecs.soton.ac.uk"
           name="&lt;rwb197@ecs.soton.ac.uk&gt;">.
Puis positionnez la variable d'environnement  LESSCHARSET~: 
<tscreen><verb>
export LESSCHARSET=utf-8
</verb></tscreen>
Si vous avez positionné une variable d'environnement LESSKEY, vérifiez
aussi que le fichier vers lequel elle pointe ne définit pas
LESSCHARSET.
Si nécessaire, régénérez  ce fichier en utilisant la commande
'lesskeys', ou enlevez la variable d'environnement LESSKEYS.

<sect2>expand, wc
<p>
Procurez vous GNU textutils-2.0 et appliquez le patch
<htmlurl url="textutils-2.0.diff"
        name="textutils-2.0.diff">, 
puis lancez configure.<newline>
Ajoutez "#define HAVE_MBRTOWC 1", "#define HAVE_FPUTWC 1" à config.h.
Dans src/Makefile, modifiez CFLAGS et LDFLAGS pour qu'ils incluent les
répertoires où libutf8 est installé, puis recompilez.

<sect2>col, colcrt, colrm, column, rev, ul
<p>
Procurez vous le package util-linux-2.9y, configurez le, puis
définissez ENABLE_WIDECHAR dans defines.h , changez le "# if 0" en 
"# if 1" dans lib/widechar.h. dans text-utils/Makefile, modifiez
CFLAGS et LDFLAGS pour qu'ils incluent les répertoires où libutf8 est
installé. Puis recompilez.

<sect2>figlet
<p>
Figlet 2.2 a une option pour gérer l'entrée en UTF-8~: "figlet -C utf-8".

<sect2>kermit
<p>
Le programme de communication série C-Kermit 
<htmlurl url="http://www.columbia.edu/kermit/"
        name="http://www.columbia.edu/kermit/">,
dans les versions 7.0beta10 et supérieures, comprend les encodages de
fichier et de transfert UTF-8 et UCS-2, et l'encodage de terminal
UTF-8.
La documentation de ces caractéristiques peut être trouvée à
<htmlurl url="ftp://kermit.columbia.edu/kermit/test/text/ckermit2.txt"
        name="ftp://kermit.columbia.edu/kermit/test/text/ckermit2.txt">

<sect1>Autres applications X11
<p>
La Xlib de X11 ne peut malheureusement pas encore localiser UTF-8,
cela devrait être travaillé prochainement.

<sect>Comment faire pour que vos programmes comprennent Unicode
<p>

<sect1>C/C++
<p>
Le type C '<tt>char</tt>' 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~:~


<sect2>Pour le traitement de texte normal
<p>

Le standard ISO/ANSI C contient, dans une correction qui fut ajoutée
en 1995, un type de caractère codé sur 16 bits 
`<tt>wchar_t</tt>', un ensemble de fonctions comme celles contenues
dans <tt>&lt;string.h&gt;</tt> et  <tt>&lt;ctype.h&gt;</tt> 
(déclarées respectivement dans <tt>&lt;wchar.h&gt;</tt> et
<tt>&lt;wctype.h&gt;</tt>), et un ensemble de fonctions de conversion
entre  `<tt>char *</tt>' et `<tt>wchar_t *</tt>' (déclarées dans
<tt>&lt;stdlib.h&gt;</tt>).

Voici de bonnes réferences pour cette interface de programmation~: 

<itemize>
<item>
Le manuel de GNU libc-2.1, chapitres 4 "Characters Handling" et 6
"Character Set Handling"

<item>
Les pages de manuel 
<htmlurl url="man-mbswcs.tar.gz"
        name="man-mbswcs.tar.gz">

<item>
La référence de la bibliothèque C Dinkumware
<htmlurl url="http://www.dinkumware.com/htm_cl/"
        name="http://www.dinkumware.com/htm_cl/">

<item>
La spécification Single Unix d'OpenGroup
<htmlurl url="http://www.UNIX-systems.org/online.html"
        name="http://www.UNIX-systems.org/online.html">
</itemize>

Avantages de cette interface de programmation~:
<itemize>
<item>
C'est un standard non propriétaire.
<item>
Ces fonctions font ce qu'il faut, selon les locales de
l'utilisateur. Tout ce qu'un programme doit faire est d'appeler
 <tt>setlocale(LC_ALL,"");</tt>.
</itemize>

Inconvénients de cette interface de programmation~:
<itemize>
<item>
Certaines de ces fonctions ne sont pas "multithread-safe" parce
qu'elles conservent un état interne caché entre les appels de fonction.

<item>
Il n'y a pas de type de donnée de première classe. Par conséquent
cette API ne peut pas être utilisée raisonnablement pour tout ce qui
nécessite plus d'une locale ou d'un jeu de caractères au même moment.

<item>
La plupart des systèmes d'exploitation ont un  mauvais support de
cette interface de programmation.
</itemize>

<sect3>Notes concernant la portabilité
<p>
Une variable `<tt>wchar_t</tt>' peut être encodée en Unicode ou non.
Ceci dépend de la plateforme et quelquefois aussi des locales.
Une séquence multi-octets `<tt>wchar_t</tt>' peut être encodée en 
UTF-8 ou non selon la plateforme, et parfois selon les locales.

En détails, voici ce que la 
<url url="http://www.UNIX-systems.org/online.html"
        name="Single Unix specification">
dit à propos du type `<tt>wchar_t</tt>'~:

<em>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" </em>(i.e ASCII)<em>  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.</em>

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 <tt>L"\u201cBonjour\u201d, dit il"</tt> ou 
<tt>"\xe2\x80\x9cBonjour\xe2\x80\x9d, dit il"</tt> dans des programmes
C. Utilisez plutôt GNU gettext comme cela~: <tt> gettext ("'Bonjour',
dit il")</tt>, et créez une base de données de messages en.UTF-8.po
qui traduit "'Bonjour' dit il" en <tt>"\u201cBonjour\u201d, dit
il"</tt>.

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.

<descrip>
<tag>GNU glibc-2.0.x, glibc-2.1.x</tag>
  <itemize>
    <item>&lt;wchar.h&gt; et  &lt;wctype.h&gt; existent.
    <item>Possède les fonctions wcs/mbs, mais pas fgetwc/fputwc/wprintf.
    <item>Pas de locales UTF-8.
    <item>mbrtowc retourne EILSEQ pour les octets &gt;= 0x80.
  </itemize>
<tag>Solaris 2.7</tag>
  <itemize>
    <item>&lt;wchar.h&gt; et &lt;wctype.h&gt; existent.
    <item>Possède toutes les fonctions wcs/mbs, fgetwc/fputwc/wprintf. 
    <item>Supporte les locales UTF-8 suivantes~: en_US.UTF-8, de.UTF-8,
es.UTF-8, fr.UTF-8, it.UTF-8, sv.UTF-8.
    <item>mbrtowc retourne EILSEQ pour les octets &gt;= 0x80.
  </itemize>
<tag>OSF/1 4.0d</tag>
  <itemize>
    <item>&lt;wchar.h&gt; et &lt;wctype.h&gt; existent.
    <item>Possède toutes les fonctions wcs/mbs, fgetwc/fputwc/wprintf. 
    <item>A en plus universal.utf8@ucs4 locale, voir "man 5 unicode".
    <item>mbrtowc ne connaît pas UTF-8.
  </itemize>
<tag>Irix 6.5</tag>
  <itemize>
    <item>&lt;wchar.h&gt; et &lt;wctype.h&gt; existent.
    <item>Possède les fonctions wcs/mbs  et fgetwc/fputwc,
mais pas wprintf.
    <item>N'a pas de locales multi-octets.
    <item>A seulement un simulacre de définition pour  mbstate_t.
    <item>N'a pas mbrtowc.
  </itemize>
<tag>HP-UX 11.00</tag>
  <itemize>
    <item>&lt;wchar.h&gt; existe, mais pas &lt;wctype.h&gt;.
    <item>Possède les fonctions wcs/mbs  et fgetwc/fputwc,
mais pas wprintf.
    <item>A une locale C.utf8.
    <item>N'a pas mbstate_t.
    <item>N'a pas mbrtowc.
  </itemize>
<tag>AIX 4.2</tag>
  <itemize>
    <item>&lt;wchar.h&gt; existe, mais pas &lt;wctype.h&gt; - utilisez
à la place &lt;ctype.h&gt; et &lt;wchar.h&gt;.
    <item>Possède les fonctions wcs/mbs  et fgetwc/fputwc,
mais pas wprintf.
    <item>Possède les locales UTF-8 suivantes~: ET_EE.UTF-8,
LT_LT.UTF-8, LV_LV.UTF-8, ZH_CN.UTF-8.
    <item>N'a pas mbstate_t.
    <item>N'a pas mbrtowc.
  </itemize>
</descrip>

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 
<htmlurl url="http://www.sun.com/software/white-papers/wp-unicode/"
        name="http://www.sun.com/software/white-papers/wp-unicode/">,
section "Internationalized Applications with Unicode", est~:

<em>Pour internationaliser correctement une application utilisez les
indications suivantes~:</em>
<enum>
  <item><em>Évitez l'accès direct à Unicode. Ceci est la tâche de la
couche d'internationalisation de la plateforme.</em>
  <item><em>Utilisez le modèles POSIX pour les interfaces multi-octets
et à caractères 16 bits.</em>
  <item><em>Appelez seulement les fonctions de l'API que la couche
d'internationalisation fournit pour la langue et les opération
spécifiques à la culture.</em>
  <item><em>Restez indépendant de l'encodage.</em>
</enum>

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
<tt>is_locale_utf88()</tt>. 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 <tt>is_locale_utf8()</tt> est déclarée dans 
<htmlurl url="utf8locale.h" name="utf8locale.h">
et définie dans 
<htmlurl url="utf8locale.c" name="utf8locale.c">.

<sect3> La bibliothèque libutf8
<p>
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
<htmlurl url="libutf8-0.5.2.tar.gz"
        name="libutf8-0.5.2.tar.gz">

Avantages~:

<itemize>
<item>
Dès maintenant un support pour Unicode UTF-8 portable, même sur les
systèmes d'exploitation dont le support des caractères multi-octets ne
marche pas, ou qui n'ont pas du tout de support pour les caractères
multi-octets/larges.

<item>
Le même binaire marche pour toutes les locales 8-bit et les locales
UTF-8 supportées par le système.

<item>
Quand un système d'exploitation fournit un vrai support pour les
caractères multi-octets, vous pouvez en tirer avantage simplement en
recompilant sans l'option du compilateur -DHAVE_LIBUTF8.
</itemize>

<sect3>La méthode Plan9
<p>
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é '<tt>Rune</tt>', pas '<tt>wchar_</tt>'. Des parties ce ses
bibliothèques, écrites par  Rob Pike et Howard Trikey, sont
disponibles à
<htmlurl url="ftp://ftp.cdrom.com/pub/netlib/research/9libs/9libs-1.0.tar.gz"
        name="ftp://ftp.cdrom.com/pub/netlib/research/9libs/9libs-1.0.tar.gz">.
Une autre bibliothèque similaire, écrite par Alistair G. Crook, est à
<htmlurl url="ftp://ftp.cdrom.com/pub/NetBSD/packages/distfiles/libutf-2.10.tar.gz"
        name="ftp://ftp.cdrom.com/pub/NetBSD/packages/distfiles/libutf-2.10.tar.gz">. <newline>
En particulier, chacune de ces bibliothèques contient un moteur
d'expressions rationnelles qui comprend l'UTF-8.

Désavantages de cette API~:

<itemize>
<item>
UTF-8 est compilé  dans la bibliothèque, pas optionnel. Les
programmes compilés dans cet univers  perdent le
support des encodages 8-bits qui sont toujours utilisés fréquemment en
Europe.

</itemize>

<sect2>Pour les interfaces utilisateur graphiques
<p>
La bibliothèque QT-2.0 
<htmlurl url="http://www.troll.no/"
        name="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.

<sect2>Pour la manipulation de texte avancée
<p>
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.

<descrip>
<tag>ucdata-1.9</tag>
La bibliothèque ucdata de Mark Leisher
<htmlurl url="http://crl.nmsu.edu/~mleisher/ucdata.html"
        name="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.

<tag>ICU</tag>
Ce  sont les classes IBM pour Unicode. 
<htmlurl url="http://www.alphaworks.ibm.com/tech/icu/"
        name="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.

<tag>libunicode</tag>
La librairie Unicode de GNOME 
<htmlurl url="http://cvs.gnome.org/lxr/source/libunicode/"
        name="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.
</descrip>

<sect2>Pour la conversion
<p>
Deux bibliothèques de conversion qui supportent UTF-8 et un grand
nombre de de jeux de caractères 8-bits, sont disponibles~:

<sect3>L'implémentation iconv d'Ulrich Drepper, contenue dans la GNU glibc-2.2.1
<p> 
<htmlurl url="ftp://ftp.gnu.org/pub/gnu/glibc/glibc-2.1.1.tar.gz"
        name="ftp://ftp.gnu.org/pub/gnu/glibc/glibc-2.1.1.tar.gz">.

Avantages~:
<p>
<itemize>
<item>
iconv est conforme au standard POSIX, les programmes qui l'utilisent
pour la conversion depuis/vers UTF-8 tourneront aussi sous
Solaris. Cependant le nom des jeux de caractères diffère entre les
plateformes. Par exemple, "EUC-JP" sous glibc devient "eucJP" sous
HP-UX. (Le nom INIA officiel pour ce jeu de caractères est
"EUC-JP". Il s'agit donc clairement d'une déficience de HP-UX.)

<item>
Aucune bibliothèque supplémentaire n'est nécessaire.
</itemize>

<sect3>librecode par François Pinard
<p>
<htmlurl url="ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz"
        name="ftp://ftp.gnu.org/pub/gnu/recode/recode-3.5.tar.gz">.

Avantages~:
<p>
<itemize>
<item>
Support pour la translittération, i.e conversion de caractères non-ASCII
en séquences de caractères ASCII de façon à préserver la lisibilité
pour les humains, même lorsqu'une transformation sans pertes est
impossible.
</itemize>

Problèmes~: 

<itemize>
<item>
Cette API est non standard.
</itemize>

<sect2>Les autre approches
<p>
<descrip>
<tag>libutf-8</tag>
libutf-8, de G.Adam.Stanislav 
<htmlurl url="mailto:adam@whizkidtech.net"
           name="&lt;adam@whizkidtech.net&gt;">
contient quelques fonctions pour la conversion depuis/vers des flux
"FILE*".
<htmlurl url="http://www.whizkidtech.net/i18n/libutf-8-1.0.tar.gz"
        name="http://www.whizkidtech.net/i18n/libutf-8-1.0.tar.gz">
<newline>
Avantages~:

<itemize>
<item>
Très petit.
</itemize>

Problèmes~:

<itemize>
<item>
API non standard~;

<item>
UTF-8 est compilé  dans la bibliothèque, pas optionnel. Les
programmes compilés dans cet univers  perdent le
support des encodages 8-bits qui sont toujours utilisés fréquemment en
Europe~;

<item>
L'installation n'est pas évidente~: le Makefile doit être modifié. Pas d'auto-configuration.
</itemize>
</descrip>

<sect1>Java
<p>
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

<enum>
<item>
vous positionniez la propriété système "user.language" de façon
appropriée.
<item>
Les définitions de jeux de fontes 
/usr/lib/java/lib/font.properties.<it>language</it>
soient appropriées, et
<item> 
Le fontes spécifiées dans ce fichier soient installées.
</enum>
Par exemple, pour afficher du texte contenant des caractères japonais,
vous devriez installer des fontes japonaise, et lancer "java
-Duser.language=ja ...". Vous pouvez combiner les jeux de fontes~: pour
pouvoir afficher des caractères d'Europe de l'ouest, grecs et
japonais simultanément, vous devriez créer une combinaison des
fichiers "font.properties" (couvre ISO-8859-1), "font.properties.el"
(couvre ISO-8859-7) et "font.properties.ja" dans un seul fichier.
??Ceci n'a pas été testé??

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 &lt;string.h&gt; comme strlen() et strcpy() peuvent être
utilisées pour les manipuler.

<sect1>Lisp
<p>
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
<htmlurl url="http://clisp.cons.org/"
        name="http://clisp.cons.org/">
supporte Unicode. Vous aurez besoin d'une version de CLISP datant de
juillet 99 ou plus récente.
<htmlurl url="ftp://clisp.cons.org/pub/lisp/clisp/source/clispsrc.tar.gz"
        name="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 
<htmlurl url="http://www.elwood.com/eclipse/eclipse.htm"
        name="http://www.elwood.com/eclipse/eclipse.htm">
supporte Unicode. Voir
<htmlurl url="http://www.elwood.com/eclipse/char.htm"
        name="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'.<newline>
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.

<sect1>Ada95
<p>
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.
</article>
