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.
Un texte dans une langue quelconque peut se décomposer en une suite de caractères. 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.
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é.
En bref, un texte est une suite de caractères.
Depuis le temps, vous savez probablement déjà qu'un fichier sur un ordinateur n'est ni plus ni moins qu'une suite d'octets, 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.
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.
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.
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.
À 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 ASCII : 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.
La solution était donc toute simple : un octet par caractère, un caractère par octet, pourquoi se fatiguer ?
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.
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.
Dans ces 128 valeurs, il n'y a hélas pas la place de caser les caractères pour les langues occidentales et l'alphabet cyrillique et l'alphabet grec et 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.
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.
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.
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.
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. Ni les 11&thsp;172 syllables coréennes, ni les dizaines de milliers d'idéogrammes chinois qu'on arrive à recenser.
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.
Tout ceci nous amène presque à l'état actuel de l'informatique :
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 !
Pour résoudre durablement 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.
Avec Unicode, un texte dans n'importe quelle langue, ou n'importe quelles langues peut se représenter comme une suite de nombres. Quelle simplification !
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.
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.
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.
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).
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.