Résumé

  • La RFC 1489 a enregistré le nom MIME koi8-r pour une pratique déjà largement adoptée dans les environnements Unix et réseau de l’ancienne Union soviétique ; elle ne l’a proclamée ni norme Internet ni norme internationale.
  • La disposition des lettres russes permet un effet calculable : effacer le bit 7 produit des correspondances latines approximatives, avec une casse inversée. La RFC publie la table, pas le récit d’un incident historique précis.
  • Cette lisibilité résiduelle aide un humain à formuler une hypothèse. Elle ne restitue pas les octets perdus et ne distingue pas toujours un caractère ASCII d’origine d’une lettre cyrillique endommagée.

Lire une archive n’est pas l’authentifier

L’écran affiche kOD OBMENA INFORMACIEJ. L’expression paraît maladroite, les majuscules sont à l’envers, mais un russophone peut reconnaître « Код обмена информацией », code d’échange d’information. Pour un projet d’archives, le soulagement est immédiat : le document n’est peut-être pas muet.

Le diagnostic doit néanmoins rester au conditionnel. La chaîne visible est composée d’octets ASCII. Elle pourrait provenir d’un texte KOI8-R dont le bit de poids fort a été effacé ; elle pourrait aussi avoir été saisie ainsi, produite par une translittération différente ou transformée plusieurs fois. La compréhension du lecteur réduit l’incertitude linguistique. Elle n’établit pas la généalogie binaire du fichier.

La propriété se reproduit à partir de la table de la RFC 1489. La phrase russe encodée en KOI8-R donne une suite d’octets hauts ; après application d’un masque à sept bits, elle devient la chaîne latine ci-dessus. C’est une conséquence vérifiable de la table, non la preuve qu’un courrier historique particulier a subi cette opération.

L’enregistrement est arrivé après l’usage

Le dossier RFC Editor date le texte de juillet 1993, l’attribue à Andrew A. Chernov, alors au sein de RELCOM Development Team, et le classe aujourd’hui Informational dans le flux Legacy. Le document lui-même refuse le prestige qu’on pourrait lui prêter : il ne spécifie pas de norme Internet.

Il décrit KOI8-R comme un codage sans statut de norme internationale, construit sur plusieurs références publiées mais dont la spécification propre n’avait pas été publiée. En revanche, une très vaste communauté l’utilisait déjà, notamment RELCOM. Dans les applications Unix et de réseau mondial de l’ancienne Union soviétique, le codage fonctionnait comme un standard de fait. La Society of Unix User Groups demandait donc un nom enregistré pour une réalité opérationnelle existante.

Cette chronologie rejoint la primauté du code en fonctionnement décrite par Heng Lu. Le texte commun est venu stabiliser une convention pratiquée ; il n’a pas fabriqué l’adoption. L’autorité de la RFC porte sur une désignation et une correspondance de codes, non sur la légitimité de tous les acteurs, l’exactitude de tous les fichiers ou la supériorité du choix technique.

Deux moitiés, plusieurs réalités

La moitié basse de KOI8-R coïncide avec ASCII. La moitié haute ne contient pas seulement l’alphabet russe : elle réserve aussi des positions aux traits de cadres, blocs, symboles mathématiques, signes typographiques et lettres cyrilliques. Le fichier de correspondance du Consortium Unicode rend aujourd’hui cette structure exploitable par une machine et précise qu’il suit la RFC 1489.

La paire la plus simple explique l’effet. L’octet C1 représente le petit а cyrillique. Sans son bit 7, il devient 41, le A latin majuscule. L’octet E1 représente le А cyrillique majuscule ; amputé du même bit, il devient 61, le a latin minuscule. La casse inversée est inscrite dans les positions.

De nombreuses lettres suivent une proximité sonore : les positions associées à R, S ou T permettent de deviner les lettres russes correspondantes. D’autres utilisent des approximations moins naturelles. Les signes dur et mou, certaines consonnes et les éléments graphiques ne deviennent pas une translittération académique. Un cadre tracé sur un ancien terminal peut se transformer en commande de contrôle ou en ponctuation dépourvue de rapport visuel.

Il faut donc parler de dégradation gracieuse pour une partie des lettres, pas de conservation générale. L’œil récupère parfois un chemin vers le mot ; le support a perdu un bit par octet concerné.

Le survivant ne révèle pas son parent

Une transformation avec perte peut faire converger deux origines. L’octet ASCII 41 représentait peut-être déjà A. Il peut aussi être le reste de C1, le petit а cyrillique KOI8-R. Après l’effacement du bit, les deux histoires ont exactement le même octet final.

Dans un paragraphe entièrement russe, la grammaire fournit des indices. Dans un message mêlant commandes, adresses de fichiers, noms de logiciels, mots anglais et prose russe, elle ne suffit plus. Remettre le bit haut à toutes les lettres latines détruirait l’ASCII authentique. Ne rien modifier abandonnerait les lettres russes amputées. Un dictionnaire peut classer les reconstructions les plus vraisemblables ; il ne recrée pas la preuve absente.

Les traitements ultérieurs peuvent encore réduire les indices. Une indexation insensible à la casse efface l’inversion révélatrice. Un export UTF-8 encode proprement le mauvais choix. Une police rend une hypothèse convaincante. Un copier-coller détache le texte de son en-tête MIME. Chaque amélioration d’usage peut rendre l’histoire matérielle plus difficile à retrouver.

Le registre donne un nom, pas un verdict

Le registre IANA des jeux de caractères conserve KOI8-R sous le numéro MIBenum 2084 et l’alias csKOI8R, avec la RFC 1489 comme référence. Cette continuité permet à un logiciel de relier le nom à une table précise.

La RFC 2046 explique le rôle du paramètre MIME charset : il indique comment l’expéditeur entend faire interpréter les octets d’un corps texte. Elle rappelle aussi qu’un contenu huit bits peut nécessiter un encodage de transfert sur certains chemins de courrier. Le dossier de la RFC 2046 documente son statut, pas la conformité d’un message donné.

Un en-tête charset=koi8-r correctement orthographié reste une assertion. Il peut accompagner des octets Windows-1251, un fichier déjà mutilé ou un assemblage hétérogène. Inversement, l’absence de l’en-tête ne transforme pas le premier résultat d’un détecteur en fait certain.

La RFC 2978 a plus tard formulé la limite institutionnelle : l’enregistrement associe des noms à une conversion définie et indique l’usage possible dans MIME ; l’applicabilité à une application particulière relève du protocole concerné. Son dossier RFC Editor la classe comme Best Current Practice. Cette règle ultérieure éclaire la distinction sans devenir artificiellement la procédure exacte de 1993.

Le registre, l’en-tête, les octets, le décodeur, les points de code, la police et la lecture sont des couches de réalité différentes. Aucun voyant vert sur l’une ne valide automatiquement les autres.

Une extension locale a conservé le socle russe

La RFC 2319 a décrit KOI8-U en 1998. Le codage gardait toutes les lettres russes aux positions de KOI8-R et ajoutait quatre lettres ukrainiennes dans d’autres cases de la moitié haute. Son dossier le classe lui aussi Informational.

Le document attribue une première adoption à une conférence de postmasters de fournisseurs Internet ukrainiens en 1992, puis une complétion ultérieure. L’histoire ne ressemble pas à un centre unique distribuant la langue. Une communauté locale a étendu une surface compatible afin de combler ses propres manques.

C’est une illustration de la spécification minimale et de la décision future localisée. La compatibilité sur les lettres russes réduisait le coût de coexistence. Elle ne permettait pas de présenter KOI8-R et KOI8-U comme synonymes : un décodeur KOI8-R ne pouvait pas inventer les lettres ajoutées.

UTF-8 n’a pas réécrit les archives

La RFC 3629 définit UTF-8 sur le répertoire Unicode. ASCII y conserve ses valeurs d’octets, tandis que les autres caractères utilisent des séquences de longueur variable. Le dossier RFC Editor atteste cette normalisation ultérieure.

La destination commune est devenue plus vaste, mais l’entrée d’une conversion reste historique. Pour produire le bon Unicode à partir d’un objet KOI8-R, il faut connaître les octets et leur codage. Le fichier Unicode prévient même qu’il ne certifie pas l’identité de toutes les variantes vendues sous le nom Code Page 878.

Une migration sérieuse conserve l’objet source et son empreinte, puis enregistre la table, le convertisseur, les exceptions et l’empreinte de la représentation Unicode. Si elle remplace le fichier parce que le résultat « se lit bien », elle détruit le moyen de vérifier sa propre décision.

La RFC 1489 n’enseigne donc pas qu’un texte peut miraculeusement survivre à la perte. Elle montre qu’un dessin de code peut ménager une trace utile au lecteur. La trace n’est ni l’octet d’origine, ni l’autorité de le reconstituer.

Sources