Résumé

  • La RFC 2152 réservait + pour ouvrir une séquence Modified Base64 sans =, construite sur des unités Unicode de 16 bits en ordre gros-boutiste ; la séquence se fermait avant tout caractère hors alphabet et ne pouvait franchir une fin de ligne.
  • Plusieurs formes légales pouvaient produire le même texte. Les caractères du Set O étaient directement transmissibles au choix, malgré un risque de passerelle, tandis que toute séquence Unicode pouvait être décalée : le décodage n’était pas la preuve de la représentation originale.

Une opération de reprise d’archives peut sembler réussie bien avant de l’être. Les objets de courrier s’ouvrent, les mots latins restent visibles, les fragments UTF-7 se décodent. Pourtant, si les messages sources ont été remplacés par leur projection Unicode, il n’est plus possible de savoir quelle ponctuation était directe, où un relais a refait les lignes ni quels octets avaient été signés.

La RFC 2152, publiée en mai 1997 par David Goldsmith et Mark Davis, traitait précisément un problème de transport. Ce document Informational, qui remplaçait la RFC 1642, ne définissait aucune norme Internet. Le courrier de l’époque reposait encore sur US-ASCII à sept bits. UTF-8 aurait dû recevoir une seconde transformation MIME pour traverser certains chemins, avec une forte expansion des textes non ASCII. UTF-7 ne produisait que des octets ASCII et laissait lisible le cas limite d’un document essentiellement ASCII.

Deux surfaces dans un seul message

Le Set D regroupait lettres, chiffres et neuf signes destinés au passage direct ; + et = en étaient exclus. Le Set O ajoutait des signes pouvant rester directs, mais la RFC avertissait que plusieurs étaient illégaux dans des champs d’en-tête ou mal transmis par certaines passerelles. Barre oblique inverse et tilde étaient écartés parce que des variantes d’ASCII les redéfinissaient souvent.

L’annexe A montrait alors deux versions d’un même extrait chinois. La première employait des caractères facultatifs du Set O et risquait de ne pas franchir certaines passerelles ; la seconde les encodait autrement. La lisibilité était un avantage local, non une garantie de transit.

Le signe plus ouvrait l’autre surface. Les caractères suivants étaient interprétés dans l’alphabet Base64 de la RFC 2045, privé du remplissage =. Un caractère extérieur à cet alphabet terminait la séquence. S’il s’agissait de , il était absorbé ; +- représentait un plus littéral. Un plus immédiatement suivi d’un caractère qui n’était ni membre du Set B ni tiret rendait la séquence mal formée.

Avant Base64, les quantités Unicode de 16 bits devenaient un flux d’octets, octet fort d’abord. Les deux moitiés d’une paire de surrogates étaient traitées séparément. Un nombre impair d’octets était invalide. Les bits ajoutés pour atteindre une frontière Base64 pouvaient être jetés au décodage, mais devaient tous être nuls.

La ligne fermait l’état

Une séquence décalée se terminait toujours à la fin d’une ligne et ne pouvait la traverser. Il fallait donc couper les lignes avant l’encodage UTF-7, ou effectuer les deux opérations ensemble. Une ligne devenue trop longue appelait un content-transfer encoding MIME approprié, non une coupure improvisée au milieu du bloc.

La RFC recommandait aussi des lignes courtes terminées par CRLF SMTP et la conversion des séparateurs Unicode U+2028 et U+2029 en sauts de ligne de courrier pour améliorer la lecture sur des systèmes anciens. Cette préparation pouvait être correcte pour l’interopérabilité et néanmoins modifier la séquence source. Inversement, un repli au mauvais endroit pouvait rendre la syntaxe invalide tout en laissant les mots ASCII voisins intacts.

Le décodage efface une partie de la preuve

La règle 2 autorisait toute séquence Unicode à entrer dans le mode décalé, alors que les règles 1 et 3 permettaient à certains caractères de rester directs. Deux flux UTF-7 distincts pouvaient donc aboutir aux mêmes caractères. C’est une inférence directe de la grammaire, pas une accusation contre un produit.

Il faut ainsi choisir la bonne quittance. Pour traiter du texte, conserver le résultat Unicode et l’état strict du décodeur peut suffire. Pour prouver ce que l’expéditeur a soumis, ce qu’une signature couvrait ou ce qu’un relais a transformé, il faut préserver l’objet brut, les fins de ligne et les empreintes de chaque frontière. La chaîne doit séparer égalité des octets, égalité des unités de code et égalité d’affichage.

L’IANA conserve UTF-7, MIBenum 1012 et l’alias csUTF7. Cette inscription atteste un nom, pas un déploiement ni un résultat. UTF-7-IMAP constitue un encodage voisin mais distinct, réservé aux noms de boîtes IMAP et explicitement déconseillé hors de ce contexte. Les deux ne partagent pas une quittance.

La section Sécurité de la RFC 2152 ne discute aucun problème. Les travaux Unicode ultérieurs ont décrit les risques de comparaisons et transformations divergentes, tout en signalant aujourd’hui que l’UTR 36 est stabilisé et que certaines recommandations ont été remplacées. L’histoire exacte ne transforme donc ni l’omission de 1997 en assurance, ni un avertissement ultérieur en mesure de tous les produits.

Deux errata sont vérifiés : le caractère de valeur 96 doit être l’accent grave, et un mot manquant est rétabli dans la phrase sur la fin de ligne. Un troisième erratum a été rejeté. Leur statut fait partie de la preuve.

La « spécification minimale » de Heng Lu éclaire la réussite étroite de UTF-7 : partager une grammaire déterministe, sans lui attribuer les décisions de conservation, d’identité ou de sens. La primauté du code exécuté exige d’observer le relais réel ; les couches de réalité empêchent de confondre le libellé charset=UTF-7 avec le résultat qu’il annonce.

Sources