UTF-7 - UTF-7

UTF-7
Langue(s) International
Standard RFC  2152
Classification Format de transformation Unicode , armure ASCII , codage à largeur variable , codage avec état
Transforme / Encode Unicode
Précédé par HZ-GB-2312
succédé par UTF-8 sur 8BITMIME

UTF-7 ( format de transformation Unicode 7 bits ) est un codage de caractères de longueur variable obsolète permettant de représenter du texte Unicode à l' aide d'un flux de caractères ASCII . Il était à l'origine destiné à fournir un moyen d'encoder du texte Unicode à utiliser dans les messages électroniques Internet qui était plus efficace que la combinaison de UTF-8 avec quoted-printable .

UTF-7 (selon sa RFC) n'est pas un " format de transformation Unicode ", car la définition ne peut encoder que des points de code dans le BMP (les 65536 premiers points de code Unicode, qui n'incluent pas les emojis et de nombreux autres caractères). Cependant, si un traducteur UTF-7 est vers/depuis UTF-16, il peut (et le fait probablement) encoder chaque moitié de substitution comme s'il s'agissait d'un point de code 16 bits, et peut donc encoder tous les points de code. Il n'est pas clair si d'autres logiciels UTF-7 (tels que les traducteurs vers UTF-32 ou UTF-8) prennent en charge cela.

UTF-7 n'a jamais été un standard officiel du Consortium Unicode . Il est connu pour avoir des problèmes de sécurité, c'est pourquoi le logiciel a été modifié pour désactiver son utilisation. C'est interdit en HTML 5 .

Motivation

MIME , la norme moderne de format de courrier électronique, interdit l'encodage des en- têtes utilisant des valeurs d'octets supérieures à la plage ASCII. Bien que MIME permette d'encoder le corps du message dans divers jeux de caractères (plus large que l'ASCII), l'infrastructure de transmission sous-jacente ( SMTP , la principale norme de transfert de courrier électronique) n'est toujours pas garantie d'être propre sur 8 bits . Par conséquent, un codage de transfert de contenu non trivial doit être appliqué en cas de doute. Malheureusement, base64 a l'inconvénient de rendre même les caractères US-ASCII illisibles dans les clients non-MIME. D'autre part, UTF-8 combiné avec quoted-printable produit un format très peu efficace en termes de taille nécessitant 6 à 9 octets pour les caractères non ASCII du BMP et 12 octets pour les caractères en dehors du BMP.

À condition que certaines règles soient respectées lors de l'encodage, UTF-7 peut être envoyé par courrier électronique sans utiliser d' encodage de transfert MIME sous-jacent , mais doit toujours être explicitement identifié comme le jeu de caractères du texte. De plus, s'il est utilisé dans des en-têtes de courrier électronique tels que « Sujet : », UTF-7 doit être contenu dans des mots codés MIME identifiant le jeu de caractères. Étant donné que les mots codés forcent l'utilisation de quoted-printable ou de base64 , UTF-7 a été conçu pour éviter d'utiliser le signe = comme caractère d'échappement afin d'éviter une double échappement lorsqu'il est combiné avec quoted-printable (ou sa variante, la RFC 2047/1522 ?Q?-encodage des en-têtes).

UTF-7 n'est généralement pas utilisé comme représentation native dans les applications car il est très difficile à traiter. Malgré son avantage en termes de taille par rapport à la combinaison d'UTF-8 avec une version imprimable ou une base64, le désormais défunt Internet Mail Consortium a recommandé de ne pas l'utiliser.

8BITMIME a également été introduit, ce qui réduit le besoin d'encoder les corps de message dans un format 7 bits.

Une forme modifiée d'UTF-7 (parfois appelée 'mUTF-7') est actuellement utilisée dans le protocole de récupération de courrier électronique IMAP pour les noms de boîte aux lettres.

La description

UTF-7 a été proposé pour la première fois en tant que protocole expérimental dans la RFC 1642, A Mail-Safe Transformation Format of Unicode . Cette RFC a été rendue obsolète par la RFC 2152, une RFC informationnelle qui n'est jamais devenue un standard. Comme l'indique clairement la RFC 2152, la RFC "ne spécifie aucune norme Internet d'aucune sorte". Malgré cela, la RFC 2152 est citée comme définition d'UTF-7 dans la liste des jeux de caractères de l'IANA. UTF-7 n'est pas non plus une norme Unicode. La norme Unicode 5.0 ne répertorie que UTF-8, UTF-16 et UTF-32. Il existe également une version modifiée, spécifiée dans la RFC 2060, qui est parfois identifiée comme UTF-7.

Certains caractères peuvent être représentés directement sous forme d'octets ASCII uniques. Le premier groupe est appelé "caractères directs" et contient 62 caractères alphanumériques et 9 symboles : ' ( ) , - . / : ?. Les caractères directs peuvent être inclus littéralement en toute sécurité. L'autre groupe principal, connu sous le nom de « caractères directs facultatifs », contient tous les autres caractères imprimables dans la plage U+ 0020 –U+007E à l'exception de l' ~ \ +espace (les caractères \et ~étant exclus du fait d'être redéfinis dans des « variantes d'ASCII » telles que JIS- romain ). L'utilisation des caractères directs facultatifs réduit la taille et améliore la lisibilité humaine, mais augmente également le risque de rupture par des éléments tels que des passerelles de messagerie mal conçues et peut nécessiter un échappement supplémentaire lorsqu'il est utilisé dans des mots codés pour les champs d'en-tête.

L'espace, la tabulation, le retour chariot et le saut de ligne peuvent également être représentés directement sous forme d'octets ASCII uniques. Cependant, si le texte codé doit être utilisé dans un courrier électronique, il faut veiller à ce que ces caractères soient utilisés de manière à ne pas nécessiter un codage de transfert de contenu supplémentaire pour être adaptés au courrier électronique. Le signe plus ( +) peut être codé comme +-.

Les autres caractères doivent être encodés en UTF-16 (d'où U+10000 et plus seraient encodés en deux substituts), puis en Base64 modifié . Le début de ces blocs d'UTF-16 encodé en Base64 modifié est indiqué par un +signe. La fin est indiquée par n'importe quel caractère ne faisant pas partie de l'ensemble Base64 modifié. Si le caractère après le Base64 modifié est un -(ASCII tiret-moins ) alors il est consommé par le décodeur et le décodage reprend avec le caractère suivant. Sinon le décodage reprend avec le caractère après la base64.

Exemples

  • " Hello, World!" est codé comme " Hello, World+ACE-"
  • " 1 + 1 = 2" est codé comme " 1 +- 1 +AD0- 2"
  • " £1" est codé comme " +AKM-1". Le point de code Unicode pour le signe dièse est U+00A3 qui se convertit en Base64 modifiée comme dans le tableau ci-dessous. Il reste deux bits, qui sont remplis à 0.
Chiffre hexadécimal 0 0 UNE 3  
Modèle de bits 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0
Indice 0 dix 12
Encodé en Base64 UNE K M

Algorithme d'encodage et de décodage

Codage

Tout d'abord, un encodeur doit décider quels caractères représenter directement sous forme ASCII, lesquels +doivent être échappés en tant que +-, et lesquels placer dans des blocs de caractères Unicode. Un simple encodeur peut encoder tous les caractères qu'il considère comme sûrs pour un encodage direct directement. Cependant, le coût de la fin d'une séquence Unicode, de la sortie d'un seul caractère directement en ASCII puis du démarrage d'une autre séquence Unicode est de 3 à 3+2 / 3 octets. C'est plus que les 2+2 / 3 octets nécessaires pour représenter le personnagetant que partie d'une séquence Unicode. Chaque séquence Unicode doit être encodée selon la procédure suivante, puis entourée des délimiteurs appropriés.

En utilisant la séquence de caractères £† (U+00A3 U+2020) comme exemple :

  1. Exprimez les numéros Unicode du personnage (UTF-16) en binaire :
  2. Concaténez les séquences binaires :
    0000 0000 1010 0011 et 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
  3. Regroupez le binaire en groupes de six bits, en partant de la gauche :
    0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
  4. Si le dernier groupe a moins de six bits, ajoutez des zéros à droite :
    000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
  5. Remplacez chaque groupe de six bits par un code Base64 respectif :
    000000 001010 001100 100000 001000 000000 → AKMgIA

Décodage

Tout d'abord, les données codées doivent être séparées en morceaux de texte ASCII brut (y compris + es suivi d'un tiret) et en blocs Unicode non vides, comme mentionné dans la section description. Une fois cela fait, chaque bloc Unicode doit être décodé avec la procédure suivante (en utilisant le résultat de l'exemple d'encodage ci-dessus comme exemple)

  1. Exprimez chaque code Base64 comme la séquence de bits qu'il représente :
    AKMgIA → 000000 001010 001100 100000 001000 000000
  2. Regroupez le binaire en groupes de seize bits, en partant de la gauche :
    000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
  3. S'il y a un groupe incomplet à la fin ne contenant que des zéros, supprimez-le (si le groupe incomplet en contient, le code est invalide) :
    0000000010100011 0010000000100000
  4. Chaque groupe de 16 bits est le numéro Unicode (UTF-16) d'un caractère et peut être exprimé sous d'autres formes :
    0000 0000 1010 0011 0x00A3 163 10

Marque d'ordre des octets

Une marque d'ordre d'octet (BOM) est une séquence d'octets spéciale facultative au tout début d'un flux ou d'un fichier qui, sans être des données elles-mêmes, indique le codage utilisé pour les données qui suivent ; il peut être utilisé en l'absence de métadonnées indiquant l'encodage. Pour un schéma de codage donné, il s'agit de la représentation de ce schéma du point de code Unicode U+FEFF.

Bien qu'il s'agisse généralement d'une seule séquence d'octets fixe, en UTF-7, quatre variations peuvent apparaître, car les 2 derniers bits du 4e octet du codage UTF-7 U+FEFFappartiennent au caractère suivant , ce qui donne 4 modèles de bits possibles et donc 4 différents octets possibles en 4ème position. Voir l'entrée UTF-7 dans le tableau des marques d'ordre des octets Unicode .

Sécurité

UTF-7 permet plusieurs représentations de la même chaîne source. En particulier, les caractères ASCII peuvent être représentés dans le cadre de blocs Unicode. En tant que tel, si des processus d'échappement ou de validation standard basés sur ASCII sont utilisés sur des chaînes qui peuvent être interprétées plus tard comme UTF-7, les blocs Unicode peuvent être utilisés pour y glisser des chaînes malveillantes. Pour atténuer ce problème, les systèmes doivent effectuer le décodage avant la validation et doivent éviter de tenter de détecter automatiquement UTF-7.

Les anciennes versions d' Internet Explorer peuvent être amenées à interpréter la page comme UTF-7. Cela peut être utilisé pour une attaque de script inter-sites car les marques <et >peuvent être encodées au fur +ADw-et à mesure +AD4-en UTF-7, que la plupart des validateurs laissent passer sous forme de texte simple.

UTF-7 est considéré comme obsolète, du moins pour les logiciels Microsoft (.NET), avec des chemins de code qui le supportaient auparavant intentionnellement (pour éviter les problèmes de sécurité) dans .NET 5, en 2020.

Les références

Voir également