# YEnc

yEnc est un algorithme de conversion 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 %. 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$^,$$^,$$^,$ 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. 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é$^,$, aucune spécification formelle ou non n’a été produite.