tuteurs.ens.fr/theorie/encodages.tml
2004-02-23 12:23:30 +00:00

294 lines
11 KiB
XML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html
PUBLIC "-//ENS/Tuteurs//DTD TML 1//EN"
"tuteurs://DTD/tml.dtd">
<html>
<head>
<title>Encodages</title>
</head>
<body>
<h1>L'enfer des langues</h1>
<div class="resume">
<p>
Dans cette page, nous allons voir quels problèmes se posent quand on veut
taper différentes langues avec un ordinateur, et comment on s'y prend pour
les résoudre de manière plus ou moins propre.
</p>
</div>
<h2>L'énoncé du problème</h2>
<h3>Caractères</h3>
<p>
Un texte dans une langue quelconque peut se décomposer en une suite de
<em>caractères</em>. La notion n'est pas parfaitement définie, mais peu
importe en fait, en général il n'y a pas de problème. En français, les
caractères sont les lettres, les chiffres, la ponctuation, les espaces. Le
O-E-dans-l'O est un caractère à part entière, parce qu'il a une existence
propre dans l'orthographe de la langue. De même, les majuscules et le
minuscules sont des caractères distincts. En revanche, le gras et l'italique
ne constituent pas une distinction sur les caractères.
</p>
<p>
Lorsqu'on s'adresse à un ordinateur pour taper du texte, ce sont
essentiellement des caractères qu'on lui communique. Selon le logiciel
employé, il pourra se glisser ou pas dans cette suite de caractères des
informations de mise en page. Dans le cas le plus simple, la seule mise en
forme qui intervient est le retour à la ligne. Dans ce cas particulier, il y
a un « caractère » spécial retour à la ligne. Ce caractère existe parce
qu'il est très utile pour les fichiers qui ne peuvent contenir que des
caractères, et aucune autre mise en forme. Il n'existe en général pas de
caractère dédié à d'autres mises en forme, comme le gras et l'italique, tout
dépend du logiciel utilisé.
</p>
<p>
En bref, un texte est une suite de caractères.
</p>
<h3>Fichiers, octets</h3>
<p>
Depuis le temps, vous savez probablement déjà qu'un fichier sur un
ordinateur n'est ni plus ni moins qu'une suite d'<em>octets</em>, c'est à
dire en quelque sorte des nombres entre 0 et 255. À vrai dire, on pourrait
aussi bien les penser comme 256 parfums possibles pour des glaces, ou 256
couleurs possibles : il y a 256 valeurs possibles, on peut les voir comme
des nombres si on veut (et dans ce cas il y a une manière naturelle de le
faire), ou comme autre chose si on préfère.
</p>
<p>
Toute la difficulté réside dans le fait de représenter une suite de
caractères par une suite d'octets. Nous allons voir que ce n'est pas si
simple.
</p>
<h2>Les premières solutions</h2>
<h3>Les informaticiens sont joueurs</h3>
<p>
Une des occupations favorites des informaticiens, c'est de mettre dans leurs
programmes des limites arbitraires qui vont plus tard poser des problèmes
sans fin. Une telle imprévoyance a défrayé la chronique il y a peu : le
fameux bug de l'an 2000 (sauf que ça a fait un flop monumental, les
journalistes n'ayant pas compris que 2000 n'est pas du tout un nombre rond
pour un ordinateur). Le problème de la représentation de textes est
probablement le domaine où elle se fait le plus cruellement sentir, et le
problème n'est pas encore près d'être complètement résolu.
</p>
<p>
Tout commence par une constatation très simple : les premiers
informaticiens parlaient anglais. Et l'anglais s'écrit avec pas grand
chose : deux fois 26 lettres, 10 chiffres, une trentaine de signes de
ponctuation, de signes mathématiques, sans oublier le symbole dollar : avec
95 caractères au total on peut se débrouiller.
</p>
<p>
À l'époque dont je parle, on ne pouvait utiliser que la moitié des octets,
soit 128 valeurs. On en a pris 33 comme caractères de « contrôle » (dont
le retour à la ligne, plus des trucs plus exotiques, comme faire sonner la
machine, ou des codes bizarres pour déplacer le curseur), plus les 95 dont
on avait besoin pour écrire l'anglais. On a numéroté tout ça, ça a donné le
code <abbr lang="en_US" title="American Standard Code for Information Interchange">ASCII</abbr> :
une correspondance entre les octets de 0 à 127 avec des codes de contrôle et
les 95 caractères utiles pour taper de l'anglais.
</p>
<p>
La solution était donc toute simple : un octet par caractère, un caractère
par octet, pourquoi se fatiguer ?
</p>
<h3>Les Européens veulent jouer aussi</h3>
<p>
Bien sûr, au bout d'un moment, il y a des gens qui ont eu envie de pouvoir
taper du français ou de l'allemand sur leur ordinateur. Heureusement, entre
temps, il était devenu possible d'utiliser les valeurs laissées de côté par
l'ASCII. Dans cette place, il a été possible de caser les caractères
accentués et divers autres symboles utilisés par les langues d'europe de
l'ouest.
</p>
<p>
Dans le même temps, les informaticiens russes ont profité de ces 128
valeurs pour y caser l'alphabet cyrillique. Les Grecs y ont aussi mis leur
propre alphabet.
</p>
<p>
Dans ces 128 valeurs, il n'y a hélas pas la place de caser les caractères
pour les langues occidentales <em>et</em> l'alphabet cyrillique <em>et</em>
l'alphabet grec <em>et</em> l'alphabet hébreu. Mais ce n'est pas grave. En
France, on tape du français, pas du grec ; en Grèce on tape du grec, pas du
Cyrillique ; en Russie on tape du cyrillique, pas du français. Les
ordinateurs étaient configurés pour que le clavier envoie certains codes,
que l'écran affiche certains caractères, et que tout marche bien comme ça.
Bien sûr ça ne marche plus du tout si on franchit la frontière, ou si on va
chez le voisin qui a un ordinateur d'une marque différente, mais ce n'est
pas grave.
</p>
<h3>Les encodages</h3>
<p>
Non, bien sûr, tout ceci ne pouvait pas durer. Pour le problème de pouvoir
taper plusieurs langues sur un même ordinateur, la solution est simple : il
suffit d'étiqueter chaque fichier, celui-ci est en français, celui-ci en
grec.
</p>
<p>
Mais il fallait aussi que les ordinateurs puissent communiquer entre eux
même en étant de marques différentes. Donc au lieu que chaque fabricant
invente sa propre correspondance entre octets et caractères, des organismes
de standardisation s'y sont mis. Ça a donné des tables de correspondance,
comme l'ISO-8859-1, qui propose un jeu de caractères pour les langues
occidentales, l'ISO-8859-5 qui offre du cyrillique, l'ISO-8859-7, qui
propose du grec, etc.
</p>
<p>
Tous les problèmes n'étaient pas résolus, mais au moins il suffit d'indiquer
au début d'un texte le nom de l'encodage qu'il utilise, et pour peu qu'on
ait les bonnes polices de caractères, on peut le lire sans problème.
</p>
<h3>Et les langues orientales dans tout ça ?</h3>
<p>
Bon, tout ça c'est très bien, mais même en tassant très fort, on n'arrivera
pas à faire rentrer les 1945 idéogrammes du japonais officiel dans un octet
(sans compter ceux qui servent pour les noms propres, ni l'alphabet
syllabique). Ni les 11&thsp;172 syllables coréennes, ni les dizaines de
milliers d'idéogrammes chinois qu'on arrive à recenser.
</p>
<p>
Les informaticiens orientaux ont donc dû inventer leurs propres méthodes,
des codages qui abandonnaient la correspondance un octet = un caractère.
Bien sûr, si vous croyez que les informaticiens japonais ont fait un code
qui permet de faire aussi du chinois, ou le contraire, vous êtes un
indécrotable idéaliste qui n'a rien compris à l'informatique.
</p>
<h3>État des lieux</h3>
<p>
Tout ceci nous amène presque à l'état actuel de l'informatique :
</p>
<ul>
<li>Pour les langues « simples », un codage standard avec un octet par
caractère est utilisé.</li>
<li>Les textes sont éventuellement étiquetés par l'encodage qu'ils
utilisent.</li>
<li>Les logiciels occidentaux sont profondément liés à la correspondance un
octet = un caractère.</li>
<li>Les logiciels orientaux utilisent de manière très figée un système
spécifique à une langue.</li>
</ul>
<p>
Ce qui manque à tout ça, c'est la possibilité qu'un même texte (et dans
certains cas un même logiciel) contienne simultanément plusieurs langues
couvertes par des encodages différents. Militons pour le droit des
universitaires russes de faire des thèses sur les traductions de la Bible de
l'hébreu au grec !
</p>
<h2>Unicode</h2>
<h3>Le but du projet</h3>
<p>
Pour résoudre <em>durablement</em> tous ces problèmes de langues, il s'est
formé un consortium, qui regroupe de grands noms de l'informatique et de la
linguistique : le consortium Unicode. Sa tâche : recenser et numéroter
tous les caractères existant dans toutes les langues du monde. Au moment où
j'écris ces lignes, le standard publié comporte presque 60&thsp;000
caractères.
</p>
<p>
Avec Unicode, un texte dans n'importe quelle langue, ou n'importe
quelle<em>s</em> langue<em>s</em> peut se représenter comme une suite de
nombres. Quelle simplification !
</p>
<h3>Les nouveaux codages</h3>
<p>
Il est possible d'utiliser directement Unicode pour stoquer les textes
informatiques, en utilisant plusieurs octets pour codes les caractères : on
appelle ce code UCS-4 parce qu'il utilise 4 octets par caractères, le
consortium Unicode ayant prévu que deux milliards de caractères ne seraient
pas atteints dans l'immédiat.
</p>
<p>
Il existe cependant un autre code largement utilisé avec Unicode. Il
s'appelle UTF-8. Il est un peu plus complexe, il utilise un nombre variable
d'octets par caractères, mais présente certains avantages : il est
compatible avec l'ASCII, de sorte que les parties écrites avec l'alphabet
latin de base d'un texte codé en UTF-8 seront à peu près lisibles même avec
un logiciel qui ne comprend pas ce codage.
</p>
<h3>Comment marchent les bons logiciels</h3>
<p>
Un bon logiciel est maintenant un logiciel qui permet de travailler avec
Unicode. Enfin, là, je parle des logiciels qui ont à gérer du texte, hein,
un Démineur peut très bien continuer à déminer sans se soucier d'Unicode.
Un bon logiciel, disais-je, va travailler autant que possible en Unicode. En
interne, ses données seront probablement codées uniquement en UCS-4 ou UTF-8
selon ce qu'il en fait, mais ça n'a pas besoin d'être visible. L'important
est qu'il saura jongler entre les différents encodages pour communiquer avec
d'autres composants.
</p>
<p>
Prenons l'exemple d'un logiciel de courrier électronique. Les courrier reçus
comportent une indication de leur codage : hop, le logiciel se débrouille
pour en faire de l'Unicode. Il les affiche en convertissant dans le bon
codage pour le système graphique ou le terminal dans lequel il tourne. Quand
on veut répondre, il prépare la citation dans le bon encodage pour
l'éditeur, puis récupère le texte ainsi édité et le reconvertit. À l'envoi,
il va choisir le meilleur encodage, en tenant compte des nécessités (les
caractères utilisés dans le courrier), et du fait que le destinataire n'a
pas forcément un logiciel qui comprend unicode (et donc il vaut mieux
utiliser un encodage plus ancien et simple si possible).
</p>
<p>
Tout ceci est un peu compliqué, parce que le logiciel est à l'interface
entre le réseau, l'utilisateur et l'éditeur de texte, qui peuvent chacun
utiliser un encodage différent. À terme, ce sera probablement de l'UTF-8 de
tous les côtés, et ce sera plus simple.
</p>
<h2>En pratique</h2>
<ul>
<li><a href="&url.tuteurs;unix/editeurs/unicode.html">Taper de l'Unicode
avec Vim ou Emacs (ou dans un terminal)</a></li>
<li><a href="&url.tuteurs;internet/courrier/international.html">Gérer son
courrier électronique en Unicode avec Mutt</a></li>
<li>Taper du LaTeX en Unicode : pour bientôt.</li>
</ul>
<div class="metainformation">
Auteur : Nicolas George. Dernière modification le <date value="$Date: 2004-02-23 12:23:30 $." />.
</div>
</body>
</html>