yEnc

yEnc est un algorithme de conversion (en) de format de données, depuis du binaire vers du texte. Il est généralement utilisé sur Usenet pour le transfert de fichiers. Il a pour but de remplacer les codages historiques que sont uuencode et base64, grâce à sa meilleure efficacité.

En effet, il diminue le surcoût des codages précédents (uuencode et base64, sur six bits) via l’utilisation de l’« ASCII étendu » (sur huit bits). Le surcoût de ce codage est souvent de l’ordre d’un à deux pour cent, alors que celui des codages sur six bits est de 33 à 40 %[1]. En conséquence, le corps du message (contenant la pièce jointe) est plus petit et peut être transmis plus rapidement.

Un autre avantage du codage yEnc est l’ajout d’une somme de contrôle de type CRC, qui permet de vérifier l’intégrité du fichier joint.

Le codage yEnc a été créé et placé dans le domaine public par Jürgen Helbing en 2001. Il n’est décrit que de façon informelle, il ne dispose pas de normalisation (RFC).

Problèmes

Le codage yEnc présente plusieurs inconvénients[2],[3],[4],[5] déjà présents dans le codage uuencode, et résolus entretemps par MIME.

  • Il se base sur la recherche de lignes spéciales commençant par =ybegin et =yend pour délimiter les portions encodées. Cette technique n’est pas complètement fiable puisque rien n’empêche le contenu d’un message — en particulier si celui-ci parle de yEnc — de contenir ces chaînes.
  • Il se base sur le sujet du message (l’en-tête Subject:) pour réassembler les fichiers découpés, ce qui encore une fois n’est pas robuste.

De plus, yEnc introduit des faiblesses supplémentaires.

  • Il prétend donner à certains champs d’en-tête une structure particulière, alors qu’il est impossible de forcer les autres clients à respecter ces contraintes lors d’usages autres que le codage yEnc — même les clients yEnc ne respectent pas toujours cette convention, comme le dénonce la page d’accueil de yEnc[6]. En particulier, le sujet du message devrait contenir la chaîne yEnc, le nom du fichier et le numéro de partie. MIME résout cet aspect en renseignant ces informations dans des en-têtes dédiés.
  • Là ou uuencode respectait la forme usuelle d’un message Internet, à savoir celle d’un flux textuel, l’encodage yEnc produit un flux arbitraire d’octets. En particulier, un décodeur yEnc doit connaître à l’avance la taille des données à décoder pour savoir quand s’arrêter. Cette information est incluse dans la ligne délimitrice de début, et rappelée dans la ligne délimitrice de fin pour vérification.
  • L’emploi de valeurs sur huit bits cause des problèmes de compatibilité. Certains canaux de transmission peuvent ne pas supporter de telles valeurs. En outre, subsiste le risque que des systèmes interprètent comme du texte le flux d’octets produits par yEnc — qui devrait être considéré comme un flux binaire — et l’altèrent en conséquence, par exemple en effectuant des conversions entre encodages textuels. Par ailleurs, dans un souci de conformité avec les normes d’Internet, certains systèmes pourraient décider de réencoder le flux yEnc avec uuencode ou base64, annulant ainsi tout l’intérêt de yEnc.

Enfin, l’absence de normalisation peut être considérée comme un problème.

À l’exception du faible surcoût de l’encodage lui-même, la norme MIME offre déjà, dans un cadre normalisé, toutes les fonctionnalités de yEnc — transmission de données binaires, découpage en plusieurs parties, lignes délimitrices, contrôle d’intégrité (via MD5, là où yEnc utilise CRC-32). Pour cette raison, intégrer le codage yEnc dans la norme MIME, auprès de base64 et quoted-printable, résoudrait la majorité de ces problèmes. Toutefois, bien que cela ait été suggéré[7],[5], aucune spécification formelle ou non n’a été produite.

Notes et références
(en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « yEnc » (voir la liste des auteurs).
  1. (en) Jürgen Helbing, « yEncode — A quick and dirty encoding for binaries » [archive du ], sur yenc.org, . « Existing mechanisms for transmission of binary information by electronic mail and newsgroups make use of only 7-bit ASCII text. The resulting encoded data are up to 40% larger than the original binary information. […] The overhead of yEncoded binary data can be as little as 1-2%. »
  2. (en) Jürgen Helbing, « Opponents to yEnc » [archive du ], sur yenc.org,
  3. (en) Jeremy Nixon, « Why yEnc is bad for Usenet » [archive du ],
  4. (en) Curt Welch, « What's wrong with yEnc? » [archive du ],
  5. (en) Claus Färber, « yEnc considered harmful »(Archive • Wikiwix • Archive.is • Google • Que faire ?),
  6. (en) Jürgen Helbing, « Homepage » [archive du ], sur yenc.org, . « 30. March 2003: Newsflash: Some neticens began to post yEncoded messages without the mandatory keyword: yEnc in the subject line. Some tools are permitting to post without the quotes around the filename. Both tendencies are not compliant to the yEnc spec. Programmers are honestly to fulfill the spec. »
  7. (en) Jeremy Nixon, « A better way to post binaries on Usenet » [archive du ],

Liens externes
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.