La présente version de l'outil Chroniques de langue a été archivée et ne sera plus mise à jour jusqu'à son retrait définitif.
Veuillez consulter la version remaniée de l'outil Chroniques de langue pour obtenir notre contenu le plus à jour, et n'oubliez pas de modifier vos favoris!
J’ai connu mes premiers soucis relatifs aux jeux de caractères en 1984 ou 1985, à commencer par la définition de ce qu’est un jeu de caractères, du point de vue de l’informatique en particulier.
L’anglais et le français s’écrivent avec 26 lettres et 10 chiffres et un certain nombre d’accents et de signes de ponctuation. L’informatique a d’abord utilisé des jeux de caractères limités aux lettres majuscules, aux chiffres et à certains signes de ponctuation.
Ainsi, en 1972, j’ai travaillé pour la compagnie de télécommunications CNCP et constaté que les télégrammes utilisaient un jeu de caractères qui ne comprenait ni lettres accentuées ni majuscules. Le jeu de caractères était celui des téléscripteurs, fondé sur le code Baudot1.
Un jeu de caractères est en fait une convention ou une norme reconnue par un certain nombre d’utilisateurs. Au fil des ans, des jeux de caractères plus ou moins complets ont vu le jour. L’un des plus connus fut le code ASCII, qui comportait 128 caractères2 comprenant les lettres majuscules et minuscules, mais pas les accents ni les ligatures comme le œ dans œuf.
Dans un ordinateur, un code est assigné à chaque caractère pour représenter ces valeurs abstraites de symboles.
Un caractère peut être représenté de diverses façons par diverses polices de caractères et divers attributs (gras, italique, etc.) de la police. Il arrive que certaines polices ne contiennent pas tous les caractères d’un jeu donné.
Permettez-moi un raccourci peu orthodoxe pour vous dire que l’ordinateur stocke des valeurs numériques qui représentent les divers caractères qu’il manipule3.
Par exemple, en ASCII, le caractère « A » est représenté par le code 65, « B » par 66, etc.
Cependant, chaque nouvelle plate-forme (combinaison système d’exploitation et matériel) a plus ou moins connu son propre codage, généralement limité à 256 caractères4. En passant, pour un ordinateur, « A » et « a » sont des caractères différents.
Dans les années 80, j’ai utilisé le PC (IBM), l’Apple II et le Mac (Apple), l’Amiga (Amiga), le Vic 20 et le C64 (Commodore) et j’ai vu fonctionner d’autres ordinateurs moins courants. La plupart utilisaient le code ASCII et lui avaient ajouté d’autres caractères, qu’il s’agisse de lettres accentuées ou de symboles graphiques pour les dessins.
Évidemment, les codes attribués aux lettres accentuées n’étaient pas les mêmes d’un fabricant à l’autre; il n’y avait pas de norme. Par exemple, sur un PC, le code 130 donnait un caractère « é », tandis qu’il donnait un « Ç » sur un Mac.
Non seulement chaque fabricant d’ordinateurs avait sa propre extension de l’ASCII, mais il en était de même pour chaque fabricant d’imprimante. Histoire de faire travailler un peu plus les neurones des utilisateurs, les concepteurs d’imprimantes avaient même prévu des variantes qu’on obtenait en configurant de minuscules commutateurs binaires. Il fallait d’abord trouver les commutateurs généralement dissimulés sous la tête d’impression ou dans un autre endroit aussi difficile d’accès. La documentation était tout aussi géniale…
En 1987-1988, peu après mon entrée au Bureau de la traduction, j’ai vu arriver les premiers Ogivar (des micro-ordinateurs). Le pauvre technicien chargé de configurer les imprimantes, un certain Roger Racine5, m’avait demandé un coup de main.
À cette époque, un PC coûtait beaucoup moins cher qu’un Mac, mais n’offrait pas encore de majuscules accentuées d’emblée. Il fallait donc modifier la police de caractères. Un logiciel faisait le travail pour l’affichage, mais pour l’imprimante, c’est M. Racine qui a écrit le code. La rumeur veut qu’un barbu lui ait refilé un coup de main.
Nous avions donc détourné les codes assignés à des caractères graphiques ou grecs pour nos caractères accentués.
Je suis persuadé que Roger Racine a gardé un souvenir fabuleux de cette expérience. Pour dessiner un caractère, il fallait connaître le nombre de lignes de points par caractères d’une imprimante (8 à 24 selon la qualité de l’imprimante).
Pour représenter la forme d’un caractère à l’imprimante, l’ordinateur utilisait la valeur de quelques octets superposés6. Un caractère était représenté dans un octet composé de 8 bits (valeurs de 0 ou de 1) et pouvait contenir une valeur comprise entre 0 et 255.
En mode binaire, zéro s’écrit 00000000, et 255 s’écrit 11111111. Pour l’affichage, chaque 0 ou 1 représente un point (pixel) qui sera imprimé quand c’est un 1.
Afin de mieux visualiser la chose, voici une illustration d’un chiffre agrandi et de sa représentation à l’aide d’une douzaine d’octets. Les zéros seraient transparents à l’impression.
0 0 0 0 1 1 1 1
0 0 0 1 1 1 1 1
0 0 0 1 0 0 0 0
0 0 0 1 1 0 0 0
0 0 1 1 1 1 1 0
0 0 0 0 0 1 1 1
0 0 0 0 0 0 1 1
0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 1
0 0 0 0 0 0 0 1
0 1 1 0 0 0 1 0
0 1 1 1 1 1 0 0
1 1 1 1
1 1 1 1 1
1
1 1
1 1 1 1 1
1 1 1
1 1
1
1
1
1 1 1
1 1 1 1 1
Dans le deuxième cas, j’ai remplacé les zéros par des espaces.
Pour créer une majuscule accentuée, on réduisait sa taille d’au moins deux lignes, qu’on réservait au dessin de l’accent voulu :
Accent aigu | Accent grave | Accent circonflexe | Tréma |
---|---|---|---|
00001000 00010000 | 00010000 00001000 | 00001000 00010100 | 00100100 00000000 |
Ensuite, il ne restait qu’à télécharger notre nouvelle police de caractères dans l’imprimante.
On serait porté à croire que les problèmes de caractères accentués n’affectent que les lecteurs francophones, mais le langagier qui doit traduire un texte dont tous les caractères accentués sont déformés ou effacés est mal pris lui aussi.
Croyez-le ou non, il existe encore des parties d’Internet où les seuls caractères reconnus sont ceux de l’ASCII (128 caractères). Voyez un peu à quoi ressemblait l’appel dans un courriel que j’ai reçu d’une organisation qui traite notamment de localisation :
Dear Andr,
[…]
Imaginez un peu une demande de traduction à partir d’un courriel où tous les mots accentués sont ainsi tronqués… Le fameux « Être ou ne pas être » devient « tre ou ne pas tre », « têtu » devient « ttu », « été » devient « t », etc.
Quand ça arrive, suggérez au client de copier le tout dans un fichier Word ou WordPerfect. Contrairement au texte, les pièces jointes n’ont pas à être interprétées par les passerelles d’Internet; elles arrivent généralement saines et sauves. Par contre, une page Web ou un fichier texte pourraient subir les horreurs du 128 bits.
Un autre problème fréquent lié aux jeux de caractères et aux polices pourrait vous tomber dessus même si vous n’avez pas à traduire ou à lire en français : quand une personne vous envoie un texte écrit avec une police qui n’existe pas sur votre ordinateur, la substitution automatique choisit parfois une police du genre (Wingdings).
Si vous arrivez à lire le message… vous êtes un mutant.
Ça m’arrive tout le temps quand quelqu’un m’envoie un message en WordPerfect (qui n’est plus sur mon ordinateur à la maison). Je peux ouvrir le document avec Word, mais s’il a choisi une police WordPerfect plutôt qu’une police Windows (Arial, Times, etc.), ça donne à peu près ceci :
Si ça vous arrive, pas de panique. Il suffit de sélectionner le texte, puis d’appliquer une autre police de caractères.
256 codes, pour l’anglais et le français, c’est bien. Par contre, pour les langues qui utilisent des milliers de symboles, c’est un peu limité. On a donc vu apparaître des codages sur plus d’un octet. Un codage sur deux octets (16 bits) permet plus de 60 000 codes. Certains jeux de caractères à deux octets (DBCS = double byte character set) ont été conçus pour les langues qui utilisent des milliers de symboles.
Afin de n’avoir qu’un code permettant de représenter tous les caractères de toutes les langues humaines (et même artificielles), des chercheurs ont élaboré Unicode.
Unicode simplifie la vie des programmeurs et des utilisateurs. On assiste de plus en plus à une mouvance vers Unicode, qui est la valeur par défaut pour le HTML, qui s’intègre parfaitement au XML, etc.
Cependant, la transition vers Unicode nous joue parfois de vilains tours. Il arrive que des documents comportent à la fois des caractères Unicode et des caractères Windows (dits ANSI) et parfois des caractères provenant du soi-disant ASCII étendu. Quand on a omis de préciser, dans les pages HTML, quel jeu de caractères a été utilisé, le navigateur prend la valeur par défaut (Unicode UTF-8), une des moutures de Unicode7.
Vous pouvez aussi avoir un problème avec les caractères faisant partie de polices qui ne se trouvent pas sur votre ordinateur, notamment pour le chinois ou le japonais (que vous possédez si vous pouvez lire ces langues, bien entendu).
Si les caractères sont accentués, le texte devient illisible. Quand cela arrive, vous pouvez facilement corriger la situation. Il suffit d’aller au menu Affichage et de choisir un codage différent :
Les appellations varient quelque peu selon les navigateurs, comme vous pouvez le constater.
Si Unicode est sélectionné, on passera à 8859-1(ISO) ou Windows. Si l’un des deux premiers est sélectionné, on passera à Unicode et 99 % du temps, on obtiendra un affichage correct.
En passant, si la sélection (ou détection) automatique est activée, le problème est moins fréquent. Je vous suggère donc d’activer cette option si ce n’est déjà fait.
Comme je l’indiquais plus haut, il peut aussi arriver que des fichiers contiennent plus d’un jeu de caractères. L’an dernier, j’ai eu le plaisir de voir un fichier qui contenait à la fois des caractères en UTF-8 (Unicode) ET des caractères provenant de l’ASCII étendu.
Un fichier texte enregistré en UTF-8 comporte de l’information qui précise sa nature. L’ouverture à partir du Bloc-notes donne donc une interprétation qui dissimule les caractères accentués provenant de l’ASCII étendu.
Par contre, si le même fichier est ouvert à partir de Word, ces caractères s’affichent… mais sont interprétés selon le jeu Windows (différent de l’ASCII étendu).
L’ennui, voyez-vous, c’est que dans ce fichier identifié UTF-8, un processus ou une personne avait introduit des caractères de type ASCII étendu.
Quand j’ouvrais à partir du Bloc-notes de Windows, j’obtenais quelque chose qui ressemble à ceci :
La ligne de caractères accentués sous ASCII étendu disparaît complètement…
Voici ce que le même texte donne en DOS avec l’éditeur Edit.
Cette fois, c’est le UTF-8 qui en prend un coup.
Voici ce qu’on voit à partir de Word :
J’avoue que je n’ai pas beaucoup ri quand je cherchais la solution, pourtant toute simple.
Puisque je pouvais voir en DOS les caractères de l’ASCII étendu, et que je pouvais voir les autres caractères à partir du Bloc-notes, il suffisait de quelques remplacements globaux. Non pas caractère pour caractère – ç’aurait été trop simple –, mais balise pour balise.
En DOS :
É sera remplacé par Emajaigu, é par eaigu.
È sera remplacé par Egrave, è par egrave, et ainsi de suite.
J’ai procédé de la sorte pour tous les caractères qui passent mal, essentiellement les caractères accentués, les guillemets et un ou deux autres.
Dans le Bloc-notes, j’ai fait l’opération inverse. Le tour était joué.
Honnêtement, j’espère que ça ne vous arrivera jamais. Si cela se produisait, vous vous souviendrez peut-être de cette chronique…
Je sais que ça arrivera un jour, et ce jour-là, vous saurez que je n’ai pas expliqué cette histoire juste pour le plaisir. Si ça vous arrive et que votre client est un technicien, envoyez-moi sa photo pour que je voie l’expression sur son visage quand vous arriverez avec la solution.
© Services publics et Approvisionnement Canada, 2024
TERMIUM Plus®, la banque de données terminologiques et linguistiques du gouvernement du Canada
Outils d'aide à la rédaction – Chroniques de langue
Un produit du Bureau de la traduction