Du point de vue du support des langues, il n'y a pas grand-chose à dire sur les protocoles qui constituent vraiment la base, l'ossature de l'Internet : IP, TCP, UDP et ICMP et les divers protocoles d'aiguillage. Grosso modo, ils réalisent la fonction de base du réseau, à savoir permettre le transport d'information numérique d'un point de départ à une destination. L'aspect le plus important est qu'à ce niveau, on a prévu la transparence, c'est-à-dire que le réseau peut transporter l'information sans la modifier de quelque façon que ce soit, sous forme d'une séquence d'octets de 8 bits. IP associe à chaque machine un numéro tel que 199.84.165.125 qui sert d'adresse unique pour joindre cette machine. TCP permet d'établir des connexions entre machines (i.e. chaque machine sait qu'elle est connectée à l'autre, un peu comme lors d'un appel téléphonique) ; UDP au contraire permet la transmission sans connexion persistante, chaque paquet de données portant l'adresse de destination. ICMP assure le contrôle du réseau en codifiant (sous forme numérique) la transmission de messages de gestion.
Les problèmes commencent dès qu'apparaît la notion de texte, c'est à dire dès qu'on veut associer une signification autre que numérique aux octets transmis. À un niveau assez fondamental, considérons le DNS, qui sous-tend la plupart sinon la totalité des autres services de l'Internet. La raison d'être de ce système est de permettre l'utilisation de mots à la place des numéros que le protocole IP associe à chaque machine : ampère.alis.ca est nettement plus sympathique que 199.84.165.125. Mais il y a un os : le e accent grave d'ampère est interdit, ne faisant pas partie du pauvre répertoire ASCII. C'est donc dire que les seuls anglophones peuvent jouir du plein bénéfice mnémonique de ce système. Un francophone devra se contenter d'ampere pour honorer l'homme dont les découvertes en électricité ont à terme mené au développement d'Internet, ou encore choisir de rendre hommage à Chappe, créateur du premier réseau de communication numérique (1794). Un sinophone sera limité à un compromis encore plus défavorable.
Une autre manifestation de l'hégémonie de l'ASCII apparaît dans les noms de fichiers informatiques, souvent transmis sur l'Internet pour, par exemple, demander la transmission d'un de ces fichiers. Beaucoup de systèmes d'exploitation ne permettent pas l'utilisation de caractères autres que ceux de l'ASCII dans les noms de fichier ; ceci ne concerne pas directement l'Internet, mais s'impose quand même aux utilisateurs. D'autre part, même si certains systèmes permettent l'emploi de noms plus riches, de tels noms sont pratiquement interdits de séjour sur l'Internet pour la raison suivante : les logiciels devant traiter ces noms présupposent l'ASCII, et il n'existe pas dans les protocoles Internet de moyens de faire savoir à l'autre bout quel codage autre que l'ASCII a été utilisé. Ergo, pas question d'intituler Ampère.txt un panégyrique que l'on voudrait largement accessible sur l'Internet.
Les protocoles de messagerie sont parmi les plus anciens de l'Internet, la messagerie étant clairement une application qui s'impose dès qu'on dispose d'un réseau. L'application de base est le courrier électronique, qui permet la transmission de messages à un ou plusieurs destinataires déterminés au moment de l'expédition. Les forums de nouvelles sont une variante, où un message est plutôt affiché, avec une étiquette indiquant un domaine d'intérêt, de manière à pouvoir être lu par quiconque en a envie ; les noms Usenet et news sont aussi utilisés pour désigner cette application sur l'Internet.
Le courrier électronique Internet est fondé sur le protocole SMTP et sur un format de message standardisé connu sous le nom du document constitutif (format RFC 822). Ces deux standards Internet spécifient explicitement l'usage exclusif du jeu de caractères ASCII, ce qui ne permet strictement de transmettre que du texte simple en anglais. Toute autre transmission exige un codage particulier camouflant le message sous la forme de courtes lignes de caractères ASCII.
Une extension récente (ESMTP) permet sous certaines conditions la transmission de caractères à 8 bits, donc autre qu'ASCII ; malheureusement cette méthode ne fonctionne pas en pratique, pour plusieurs raisons. D'une part la transmission à 8 bits reste optionnelle, et n'est donc pas universelle. D'autre part, elle n'est permise qu'après négociation fructueuse entre les deux serveurs de messagerie impliqués, mais il est déjà trop tard, au moment où cette négociation peut se tenir, pour que l'agent-utilisateur de messagerie puisse décider du codage à utiliser ; l'expéditeur reste donc forcé de surcoder tout ce qui n'est pas ASCII, pour pallier le cas (le plus souvent rencontré) d'une négociation infructueuse, et ESMTP ne règle rien en pratique.
Une autre extension récente, MIME, est nettement plus porteuse d'avenir. Elle spécifie des méthodes de codage normalisées, mais surtout formalise la transmission d'information sur le codage effectivement utilisé à l'expédition, permettant au destinataire de décoder le message sans incertitude. MIME permet en principe de transmettre du texte en n'importe quel jeu de caractères, et donc en n'importe quelle langue, en plus de permettre la transmission fiable d'images, de son, de vidéo, de fichiers binaires d'applications, etc. Le problème de MIME est son manque d'universalité : tous n'ont pas les logiciels appropriés, qui sont plus complexes que les simples agents-utilisateur distribués normalement avec les systèmes Internet. L'expéditeur ne sait donc pas s'il peut compter que le destinataire pourra décoder son message autre qu'ASCII, et le courrier ordinaire reste souvent limité à ce jeu de caractères trop pauvre.
La situation est un peu plus rose du côté des forums, mais seulement pour certaines raisons historiques que l'on pourrait qualifier d'accidentelle. En effet, les normes régissant cette application sont tout aussi restrictives que dans le cas du courrier, mais sont appliquées avec moins de rigueur. Le format d'un message Usenet est le même que celui d'un message de courrier (RFC 822), à quelques écarts près ; officiellement, seul l'ASCII est admissible. Le transport est assuré sur l'Internet par le protocole NNTP, qui lui aussi spécifie l'ASCII exclusivement. Heureusement cette stipulation est ignorée par les serveurs NNTP les plus courants, qui laissent tranquillement passer les caractères à 8 bits, ce qui permet en pratique la propagation de messages autres qu'ASCII. Il n'en reste pas moins que la survivance de serveurs imposants la norme à 7 bits, ainsi que le manque d'étiquetage du jeu de caractères utilisé, rend cette pratique moins qu'idéale et universelle.
FTP est un service qui permet de transférer des fichiers d'une machine à une autre, presque sans égard au contenu. On distingue toutefois deux types de fichier : les fichiers texte, et les autres (binaires). Un fichier texte est formé de séquences de caractères ASCII (des lignes), séparées par des marqueurs de fin de ligne qui varient selon le système. Lors d'un transfert en mode texte, ces marqueurs sont convertis de façon à ce que le système récipiendaire obtienne un fichier texte correct pour lui. En mode binaire, cette conversion n'a pas lieu et le transfert est complètement transparent, ce qui est approprié pour des images, des programmes, des nombres au format binaire, données où la notion de ligne texte ne joue pas.
Qu'arrive-t-il si on transmet un texte contenant des caractères non-ASCII ? En mode binaire, le récipiendaire obtiendra un fichier incorrect si sa convention de fin de ligne diffère de celle de l'expéditeur (PC à Macintosh, par exemple). En mode texte, le résultat varie selon l'implémentation : certains logiciels FTP stricts tronquent le huitième bit et le texte est corrompu ; d'autres le laisse passer, avec un résultat correct tant du point de vue des caractères non-ASCII que des marqueurs de fin de ligne. En résumé, il n'y a pas de garantie de résultat avec du texte non-ASCII.
Alors que FTP ne permet que la récupération brute de fichiers, Archie est l'outil permettant de trouver les fichiers intéressants. Un serveur Archie parcourt les serveurs FTP disponibles sur l'Internet et collige dans une base de données les adresses et les noms de tous les fichiers qu'il trouve. On peut ensuite l'interroger avec une spécification partielle (par exemple sendmail), et il répondra par tout ce qui semble correspondre dans la base de données (sendmail8.6.10.tar.gz, à telle ou telle adresse). Bien qu'Archie lui-même ne soit pas vraiment limitatif du point de vue de la langue, c'est ici que la restriction des noms de fichier à l'ASCII prend toute sa signification, puisqu'aucune information de jeu de caractère n'est échangée.
Telnet est le terminal à distance de l'Internet. Il permet d'accéder à n'importe quel ordinateur de la même manière qu'avec un terminal branché directement. Un client Telnet n'est donc autre chose qu'un émulateur de terminal utilisant le protocole Telnet comme méthode de communication. Le lien est 8 bits, ce qui rend l'utilisation de n'importe quel codage raisonnable possible, mais quelque peu difficile à cause de l'absence d'un bon procédé de négociation de ce codage. À l'intérieur de ces contraintes, le multilinguisme existe déjà sur Telnet ; Alis Technologies, par exemple, commercialise des émulateurs de terminal multilingues gérant le protocole Telnet.
Hytelnet est une base de données de services accessibles par Telnet (bibliothèques, bases de données, Freenets, etc.). Hytelnet elle-même est accessible par Telnet, Gopher, W3 et par des clients propres à Hytelnet. Un parcours rapide semble montrer que la base de données est entièrement en ASCII, bien qu'elle couvre des dizaines de pays.
Finger est un service mineur qui permet d'interroger un ordinateur, connaissant son nom et accessoirement le nom d'un usager de cet ordinateur, et de recevoir en retour une petite quantité d'information déterminée soit par l'administrateur de la machine, soit par l'usager en question. Sa fonction primitive était de permettre de savoir si tel usager était présent, en ligne, mais on l'utilise aussi pour des services plus généraux comme par exemple diffuser la météo, en utilisant un nom d'usager fictif (par exemple, finger meteo@alis.ca pourrait retourner la météo locale). Restrictions linguistiques : la requête, composée d'un nom d'usager et d'une adresse Internet, doit être tout en ASCII. La réponse peut en principe être quelconque, mais comme il n'y a pas d'annonce du jeu de caractère utilisé, elle doit en pratique être limitée à ce que le terminal du requérant peut interpréter, donnée inconnue du serveur. En conséquence seul l'ASCII offre l'assurance d'un résultat correct.
On peut voir Gopher comme une immense hiérarchie distribuée de menus, avec au bout des branches des documents. Un serveur Gopher présente d'abord au client un menu. Chaque élément du menu pointe soit à un autre menu, soit à un document qui est récupéré et affiché lorsqu'on le sélectionne. Le protocole Gopher demande une transmission à 8 bits mais impose l'ASCII comme codage, avec les conséquences que l'on connaît.
Veronica, le service de recherche par mots-clés des serveurs Gopher, se plie à la norme et ne permet que l'ASCII.
Le World Wide Web (alias WWW, alias W3, alias le Web) est le plus récent des services de l'Internet, le plus populaire après la messagerie, le plus convivial et celui qui croît le plus vite. Inventé au CERN, en Suisse, il a comme bases le protocole HTTP, la notion d'URL et le langage HTML. Le premier décrit la gymnastique à laquelle doivent se plier clients et serveurs pour communiquer ; le second normalise l'adressage, l'identification des documents ou autres ressources à transmettre, alors que le dernier formalise le contenu de l'information transmise : de l'hyper-texte, c'est à dire du texte enrichi parsemé de références (les hyper-liens) à d'autres données, textuelles ou non, que l'interface-utilisateur (le fureteur) permet de récupérer et afficher d'un simple clic de souris. De surcroît, les fureteurs modernes gèrent aussi les protocoles Gopher et FTP, ainsi qu'un certain accès à Telnet et à WAIS, ce qui en fait des outils polyvalents. Ajoutons qu'HTML permet l'enchâssement d'images et de sons à même le texte, et la grande popularité du W3 s'explique : polyvalence, navigation facile par hyper-liens et richesse de présentation des données.
HTTP est un protocole de la couche Application, au même titre que SMTP, NNTP, Gopher ou FTP. Il s'appuie sur le protocole TCP, qui fournit l'équivalent d'une ligne téléphonique numérique pour le transport de l'information. HTTP admet les notions de client et de serveur : le client émet des requêtes, auxquelles le serveur répond. Une des caractéristiques du protocole (en contraste avec FTP p. ex.) est que le serveur ne conserve pas d'état entre les requêtes. Les requêtes sont donc toutes indépendantes, et chacune doit être complète. La version 1.0 du protocole, dont l'adoption par l'IETF est imminente, prévoit la transmission avec requêtes et réponses d'en-têtes semblables à celles de MIME, servant à préciser la requête ou à renseigner le client sur le contenu de la réponse.
Un URL est l'adresse complète d'une ressource Internet, de la forme suivante :
méthode://machine.domaine[:port]/chemin1/2/.../cheminN
Méthode spécifie le protocole qui doit être utilisé pour récupérer cette ressource. Ce peut être http, gopher, ftp, finger ou mailto. Machine.domaine donne l'adresse Internet du serveur à contacter ; port est un nombre spécifié seulement si le serveur reçoit les requêtes sur un port différent du port standard pour le protocole en question (p. ex. 80 pour HTTP). Le reste de l'URL contient l'information qu'il faut au serveur pour distinguer la ressource voulue de toutes les autres qu'il possède. En pratique, un URL est un peu l'équivalent d'un nom de fichier, et tout comme avec ces derniers, l'utilisation de jeux de caractères autres qu'ASCII ne peut manquer de poser des problèmes de compatibilité.
HTML est le langage par défaut des documents transmis par HTTP. C'est une application de la norme SGML, qui permet d'enrichir le texte de balises qui soit affectent la présentation (<H1> par exemple indique un titre de premier niveau), soit réalisent des formulaires avec champs de saisie par l'utilisateur, soit forment des hyper-liens permettant d'accéder commodément à d'autre documents, ou d'autres parties du même document. Les hyper-liens ont la forme suivante :
<A HREF=“URL”>Partie visible</A>
Seule la partie visible apparaît à l'écran, généralement mise en évidence d'une quelconque façon (en bleu par plusieurs fureteurs). Lorsque l'utilisateur active le lien - en cliquant sur la partie visible par exemple - l'URL est utilisé pour récupérer un nouveau document qui va généralement remplacer celui qui est présentement affiché. Voici ce qui se passe dans le cas d'une requête HTTP :
Illustration 2-1 : une conversation HTTP
Le fureteur extrait de l'URL l'adresse Internet du serveur et établit avec ce dernier une connexion TCP en s'adressant soit au port 80, soit au port spécifié dans l'URL. Il transmet ensuite sa requête, sous la forme d'une ligne de requête principale, suivie d'un nombre variable de lignes d'en-tête qui précisent la requête. La ligne principale a la forme suivante :
GET URL HTTP/1.0
On demande ainsi la transmission de la ressource spécifiée par l'URL. Les lignes d'en-tête qui suivent peuvent indiquer une date, une source, une autorisation, ou le type de document acceptable pour le fureteur. On peut ainsi utiliser une ou plusieurs des en-têtes Accept, Accept-Charset, Accept-Encoding ou Accept-Language pour indiquer des préférences ou des exigences quant au type de document (HTML, texte simple, image, son, etc.), à son codage ou à sa langue. Les en-têtes Accept sont nouvelles dans le protocole, qui n'a pas encore le statut de standard ; les fureteurs courants ne les emploient pas, et les serveurs courants ne les comprennent pas.
La réponse du serveur est constituée d'une ligne d'état, qui indique en particulier si l'opération a pu être mené à bien, d'un nombre variable de lignes d'en-tête, dont plusieurs au format MIME, qui ajoutent des précisions sur la réponse, et finalement des données elles-mêmes ; à la fin de la transmission, le serveur coupe la ligne (ferme la connexion TCP). Les lignes d'en-tête Content-Type (avec ou sans charset), Content-Encoding, Content-Transfer-Encoding et Content-Language (nouvellement introduites et pratiquement inusitées) sont d'intérêt pour le W3 multilingue. Sur réception de la réponse, il ne reste plus au fureteur qu'à analyser l'en-tête et à interpréter et afficher les données en conséquence.
Le W3 est-il polyglotte ? Un peu. En effet, peut-être à cause de son origine européenne, le jeu de caractères officiel du W3 est non pas l'ASCII mais l'ISO Latin-1, jeu assez riche pour représenter toutes les langues d'Europe occidentale. Le protocole HTTP impose un transport 8 bits, et cet aspect est respecté en pratique (ne serait-ce que pour permettre le transport correct et efficace des images). Notons toutefois que les mots-clés du protocole lui-même sont restreint à l'ASCII. HTML adopte aussi officiellement l'ISO Latin-1, permettant la présence de lettres accentuées directement dans le texte ; à quelques accrocs près, ce voeu est respecté.
Les valeurs admissibles du paramètre charset associé à l'en-tête Content-Type, et donc les jeux de caractères permis, sont déterminés non pas par le protocole de transmission HTTP mais par le langage HTML. Or la dernière version de la norme proposée pour ce langage, influencée par les interventions d'Alis Technologies sur les listes de diffusion idoines, a ouvert grand la porte à tous les jeux de caractères admis dans MIME. Or cette liste faisait 16 pages lors de sa dernière mise à jour... De plus, il semble acquis que le jeu de caractères de référence du langage HTML deviendra sous peu Unicode, un jeu de caractères universel codé à 16 bits qui permet de représenter pratiquement toutes les langues du monde.
L'en-tête Accept-Language, et son pendant Content-Language, permettent une négociation fort utile du document à transmettre. Par ce biais, un utilisateur peut spécifier ses préférences linguistiques et récupérer ainsi des documents dans la langue de son choix. Sur réception d'un en-tête Accept-Language, qui contient une liste de code de langue, un serveur conforme choisira la version linguistique la plus appropriée du document correspondant à l'URL demandé. Ce mécanisme léger facilite l'entretien de serveurs multilingues, et évite à l'utilisateur d'avoir à faire un détour pour obtenir la version de son choix ; il n'a malheureusement pas encore été réalisé dans un serveur HTTP existant.
WAIS signifie Wide Area Information System. Ce système se compose de trois partie : un indexeur, qui construit à partir d'une base de données un index, lui-même utilisé par un serveur pour identifier les données demandées par un client. Le client et le serveur communiquent via le protocole ANSI Z39.50. L'utilisateur formule une requête composée de mots-clés, le client la transmet au serveur qui retourne une liste de documents qui semblent répondre aux critères de recherche, triée par ordre de pertinence. Le protocole permet aussi de transmettre les documents eux-mêmes.
Illustration 2-2 : les éléments du système WAIS
WAIS est fondé sur l'ASCII, mais une version récente, freeWAIS-sf de l'université de Dortmund, permet l'utilisation de caractères 8 bits. Lesquels ? Mais ceux de la machine sur laquelle on l'installe bien sûr ! Ceci ouvre en principe la porte à l'utilisation de n'importe quel jeu de caractères à 8 bits, et peut-être même à 16 bits avec un peu d'effort, mais il y a un problème de taille : puisque WAIS est une application Internet, le client et le serveur ne tournent généralement pas sur la même machine, et risquent donc de ne pas utiliser le même jeu de caractères (même dans la même langue). Ceci créera une confusion qui rendra le système inutilisable si client et serveur n'arrive pas à s'entendre sur un jeu commun. Or WAIS n'inclut aucun mécanisme d'annonce ou de négociation de jeux de caractères, et de toute façon même freeWAIS-sf ne sait pas faire les conversions qui seraient nécessaires s'il y avait entente. À l'heure actuelle ni le protocole ni les implémentations existantes ne peuvent résoudre ce problème.
D'autre problème, un peu plus subtils que la 'simple' incompatibilité des jeux de caractères, se trouve dans l'indexation et la recherche. Même avec un logiciel 8 bits comme freeWAIS-sf, les caractères accentués peuvent poser problème. Par souci de flexibilité, WAIS considère les lettres majuscules et minuscules comme équivalentes ; ainsi une recherche du mot Cote trouvera tout aussi bien COTE et cote. Par contre, on ne trouvera ni côte, ni coté, ce qui peut paraître correct en principe, mais posera des problèmes à un utilisateur qui ne dispose pas d'un clavier approprié (par exemple un Français qui cherche un mot allemand). Le même phénomène se reproduit dans l'autre sens, c'est à dire qu'une recherche de côte ne trouvera pas cote, ce qui est un problème lorsqu'on a affaire a des textes qui, pour toutes sortes de mauvaises raisons, ont été rédigés sans accents.
Dans le même ordre d'idée, des lettres comme ÿ et ß mènent à des comportements étranges : la version majuscule de ÿ n'existe pas dans l'ISO Latin-1, ce qui empêche bien sûr sa reconnaissance ; la version majuscule de ß est SS, et même freeWAIS-sf, de conception allemande, ne sait pas s'accommoder de cette situation. Une recherche de straße ne trouvera donc pas STRASSE, mais trouvera STRAßE !
Pour rendre la recherche efficace et limiter la taille des fichiers d'index, l'indexeur doit tenir compte d'une liste de mots vides (articles, prépositions, conjonctions, etc.) qui ne sont pas considérés pertinents. Cette liste dépend bien sûr de la langue, mais il n'y a pas de mécanisme dans WAIS pour en tenir compte, ni même en général de marqueurs de langue dans les textes. Au mieux, cette information pourrait provenir de sources hors-bande (le nom du fichier, où sa situation dans la hiérarchie), mais encore faudrait-il que l'indexeur sache l'utiliser.
En résumé, même freeWAIS-sf doit être localisé, et une fois localisé est restreint aux documents de la même LOCALE (plus l'ASCII). Un client français sur Macintosh aura des problèmes à faire des recherches sur un serveur Unix en Allemagne, et une quasi-impossibilité avec un serveur russe.
