Résumé

  • RFC 1456 recensait 134 combinaisons vietnamiennes supplémentaires et décrivait VISCII : toutes les formes imprimables d’ASCII restaient en place, mais six majuscules vietnamiennes occupaient six positions C0.
  • VIQR répondait au réseau à sept bits en transformant parenthèse, accent circonflexe, signe plus et ponctuation en marques mnémotechniques ; leur sens dépendait donc du contexte et de l’échappement.
  • Le nom de charset indiquait une grammaire au destinataire, sans prouver la conformité des octets, la présence du convertisseur, la police, la réversibilité ni la lecture humaine.

Le meuble était déjà occupé

Le vietnamien pouvait sembler proche de l’anglais parce qu’il emploie un alphabet latin. Cette proximité graphique masquait le coût réel. Selon RFC 1456, il fallait ajouter 134 combinaisons de lettres et de signes diacritiques aux formes déjà disponibles en ASCII. Et ces formes n’étaient pas marginales : elles appartenaient au texte ordinaire.

Une représentation composée aurait économisé des cases en séparant la lettre de base de ses marques. Les auteurs observaient toutefois que les plates-formes de l’époque l’intégraient mal. Imposer à chaque frappe une commande spéciale de composition aurait déplacé vers l’utilisateur le prix de cette insuffisance.

VISCII choisit donc des lettres précomposées, chacune traitée comme une unité. L’avantage était immédiat pour les programmes qui comptaient, stockaient ou transmettaient des caractères sur un octet. La difficulté devenait arithmétique : il fallait répartir un répertoire plus grand dans un espace fini.

Le projet protégea la totalité des caractères graphiques ASCII. Les symboles dont dépendaient les commandes, fichiers et applications anglaises ne changèrent pas d’adresse. Six majuscules vietnamiennes jugées peu fréquentes furent alors placées dans six positions de contrôle C0 réputées les moins gênantes.

Sous ASCII, ces valeurs continuaient à désigner des fonctions de contrôle. Sous VISCII, elles devenaient des lettres. Aucun bit supplémentaire ne tranchait. Le même fichier pouvait être intact et pourtant perdre son texte dès que la table d’interprétation disparaissait.

Un compromis n’est pas une garantie

« Les moins gênantes » ne signifiait pas « inoffensives ». Un pilote de terminal ou un filtre pouvait consommer une valeur basse avant l’arrivée du décodeur VISCII. Un système pouvait garder l’octet et ne rien afficher faute de glyphe. Un convertisseur appliquant une autre table pouvait produire une lettre différente.

Cette dette était la contrepartie d’un accès aux outils existants. RFC 1456 mentionnait les environnements Unix, MS-DOS et Windows, le courrier et les nouvelles, l’impression, les bases de données et les traitements de texte. La communauté cherchait à employer l’infrastructure disponible au lieu de reconstruire tout l’écosystème autour d’elle.

Le texte rapportait aussi des logiciels déjà opérationnels et une conversion vers ISO 10646/Unicode 1.1 dans l’outil tcs de Plan 9. Ce sont des affirmations historiques bornées par le document. Elles ne mesurent ni tous les utilisateurs, ni toutes les versions, ni la fidélité de chaque conversion.

La base installée exerçait ainsi un pouvoir sans en porter le titre. ASCII ne décidait rien seul, mais les milliers de programmes qui supposaient ses positions rendaient certaines solutions déployables et d’autres théoriques. La normalisation partait de cette réalité d’exécution.

La seconde passerelle restait lisible

Un octet complet ne traversait pas tous les systèmes de courrier et de nouvelles. VIQR se plaça donc sur une autre frontière : sept bits ASCII, sans exiger de rendu vietnamien à chaque étape. RFC 1456 le qualifiait de convention de saisie, de lecture et de transfert, et non d’encodage identique à VISCII.

Les marques choisies ressemblaient visuellement aux diacritiques. Une parenthèse gauche pouvait représenter la brève, un circonflexe le circonflexe, un signe plus la corne. Apostrophe, accent grave, point d’interrogation, tilde et point notaient les tons. dd et DD représentaient le D barré.

Le lecteur d’un terminal à sept bits voyait une notation mnémotechnique. Sur une machine équipée, les mêmes frappes pouvaient produire des glyphes vietnamiens. L’égalité portait sur la séquence de saisie, pas sur l’image affichée.

La ponctuation gardait pourtant ses usages ordinaires. Le point d’interrogation après une voyelle pouvait être un ton ou la fin d’une question. Le RFC citait « How are you? » pour montrer une composition indésirable. Il signalait un mécanisme de prévention, mais renvoyait la grammaire complète d’échappement à un autre document Viet-Std.

Une apostrophe ne devenait donc pas un accent aigu par nature. Il fallait la convention VIQR, une position admissible et un état d’échappement compatible. La lisibilité humaine diminuait le besoin de rendu ; elle ne supprimait pas l’analyse syntaxique.

L’étiquette ne lisait pas le contenu

RFC 1456 indiquait les noms MIME VISCII et VIQR. Un corps employant ces formes devait porter le charset correspondant, mais un logiciel MIME n’était pas obligé de les prendre en charge.

L’étiquette déclarait l’intention du producteur. Elle ne validait pas les octets. Un message étiqueté VISCII pouvait avoir perdu des contrôles dans une passerelle. Le destinataire pouvait connaître le nom sans posséder le convertisseur. Le décodeur pouvait réussir alors que la police restait incomplète.

Les règles MIME ultérieures recommandèrent l’indication explicite du charset et attribuèrent US-ASCII au texte brut non étiqueté. Pour VISCII, l’absence de nom pouvait ramener six lettres au statut de commandes invisibles. Pour VIQR, le texte pouvait demeurer approximativement lisible tout en changeant de comportement dans la recherche ou la conversion inverse.

Le registre IANA conserve aujourd’hui VISCII et VIQR, avec les numéros MIBenum 2082 et 2083 et les alias csVISCII et csVIQR. Cette continuité atteste l’existence d’identifiants publics. Elle ne mesure ni usage actuel, ni prise en charge, ni exactitude.

UTF-8 agrandit l’espace commun

UTF-8 adopta plus tard une autre économie. Les octets ASCII restaient identiques, tandis que les autres caractères entraient dans un répertoire universel au moyen de séquences de longueur variable. Le problème n’était plus de faire tenir toutes les écritures dans 256 cases.

Ce changement ne convertit pas spontanément les archives. Un fichier VISCII doit être interprété avec sa table avant de devenir UTF-8. Un texte VIQR doit passer par sa grammaire contextuelle. Appliquer le décodeur moderne par défaut à des octets anciens ne modernise pas le document ; cela remplace une provenance par une supposition.

Unicode garde d’ailleurs ses propres frontières de représentation, notamment la normalisation. Deux chaînes visuellement semblables peuvent se comparer autrement. Une conversion qui paraît juste à l’écran peut encore modifier recherche, signature ou identité.

Une chaîne que l’interface cache

L’histoire peut être résumée par une suite de propositions :

caractère linguistique → représentation choisie → octet ou suite ASCII → charset → décodeur → points de code → glyphes → lecture

Chaque flèche change de responsable. Les locuteurs déterminent les distinctions utiles. Une convention attribue des formes. L’expéditeur produit des octets et un nom. Le transport peut les préserver ou les altérer. Le décodeur exécute une table. La police dessine. Le lecteur comprend.

Une preuve située au début ne remplace pas la fin. Un hachage peut confirmer le fichier tout en laissant le charset inconnu. Un charset valide peut pointer vers un décodeur absent. Une capture d’écran convaincante peut provenir d’une substitution irréversible. Un rendu identique ne garantit pas une chaîne de points de code identique.

Sources et limites

Le statut bibliographique vient de la fiche RFC 1456. Le décompte, VISCII, VIQR, les logiciels rapportés et la limite de sécurité viennent du texte RFC 1456. Le cadre MIME contemporain est dans RFC 1341, et ses règles ultérieures de charset dans RFC 2046. La comparaison avec le répertoire universel repose sur RFC 3629. Les noms durables sont vérifiés dans le registre IANA des jeux de caractères. La lecture par couches est explicitement inspirée de Lu Heng, Running Code Is Primary et On Reality Layers.

Ces sources ne prouvent pas une adoption universelle, une prévalence actuelle, une conversion sans perte, un incident d’archive ni une filiation causale directe vers UTF-8. RFC 1456 ne traitait pas les questions de sécurité. Un décodage réussi reste le résultat d’une interprétation, pas l’authentification de l’auteur ni la preuve de ce que le lecteur a compris.