yEnc es un esquema de codificación de binario a texto para transferir archivos binarios en mensajes en Usenet o por correo electrónico . Reduce la sobrecarga sobre los métodos de codificación basados en US-ASCII anteriores al usar un método de codificación de 8 bits . La sobrecarga de yEnc es a menudo (si cada valor de byte aparece aproximadamente con la misma frecuencia en promedio) tan solo un 1-2%, [1] en comparación con la sobrecarga del 33-40% para los métodos de codificación de 6 bits como uuencode y Base64 . yEnc fue desarrollado inicialmente por Jürgen Helbing, y su primer lanzamiento fue a principios de 2001. En 2003 yEnc se convirtió en el sistema de codificación estándar de facto para archivos binarios en Usenet. [2] El nombre yEncode es un juego de palabras con "¿Por qué codificar?" , ya que la idea es codificar caracteres solo si es absolutamente necesario para cumplir con el estándar de formato de mensaje. [3]
Los cuerpos de los mensajes de Usenet y de correo electrónico estaban pensados para contener únicamente caracteres ASCII ( RFC 822 o RFC 2822). La mayoría de las codificaciones de la competencia representan archivos binarios convirtiéndolos en caracteres ASCII imprimibles, porque la mayoría de los sistemas operativos admiten el rango de caracteres ASCII imprimibles. Sin embargo, dado que esto reduce considerablemente el conjunto de caracteres disponibles, hay una sobrecarga significativa (desperdicio de ancho de banda) en redes de 8 bits. Por ejemplo, en uuencode y Base64, tres bytes de datos se codifican en cuatro caracteres ASCII imprimibles, lo que equivale a cuatro bytes, una sobrecarga del 33% (sin incluir la sobrecarga de los encabezados). yEnc utiliza un carácter (un byte) para representar un byte del archivo, con unas pocas excepciones.
yEnc asume que los datos binarios pueden transmitirse principalmente a través de Usenet y correo electrónico. Por lo tanto, 252 de los 256 bytes posibles se pasan sin codificar como un solo byte, ya sea que el resultado sea un carácter ASCII imprimible o no. Solo NUL , LF , CR y = se escapan . LF y CR se escapan porque las RFC que definen los mensajes de Internet aún requieren que los retornos de carro y los saltos de línea tengan un significado especial en un mensaje de correo. = es el carácter de escape, por lo que se escapa. NUL también se escapa debido a problemas al manejar caracteres nulos en código común, aunque como optimización yEnc agrega 42 a cada byte de origen para que, lo que no es poco común, los tramos largos de bytes cero no requieran mucho escape.
No existe ningún RFC u otro documento de estándares que describa yEnc. [4] La página de inicio de yEnc contiene un borrador informal [ cita requerida ] de especificación y una gramática (que contradicen RFC 2822 y RFC 2045), [ cita requerida ] aunque ninguno ha sido enviado al Grupo de Trabajo de Ingeniería de Internet . [ cita requerida ]
Al igual que con uuencoding, a pesar de sus defectos, yEnc sigue [ ¿cuándo? ] activo y efectivo en Usenet. [ cita requerida ] La página de inicio de yEnc afirma que " todos los principales lectores de noticias han sido ampliados para admitir yEnc ". Outlook Express de Microsoft , Windows Mail y Windows Live Mail no ofrecen compatibilidad con yEnc ni para noticias ni para correo, pero hay complementos disponibles. Mozilla Thunderbird decodificará archivos yEnc de una sola parte, pero no puede combinar binarios de varias partes. [5]
Muchos programadores y administradores de noticias han señalado las debilidades de yEnc. [6] [7] [8] [9] Padece muchos de los mismos defectos que uuencode, varios de los cuales ya habían sido solucionados años antes por MIME (que abordó los mismos defectos en uuencode). Por ejemplo, yEnc requiere que las cadenas "=ybegin" y "=yend" se coloquen alrededor del archivo codificado en el cuerpo del mensaje. [3] Aunque esto es una mejora con respecto a "begin" y "end" de uuencode, que aparecen con más frecuencia en el texto normal, los lectores de mensajes aún pueden encontrar las cadenas fuera de los archivos adjuntos (con mayor frecuencia en discusiones sobre yEnc en sí). yEnc y uuencode [ cita requerida ] también intentan volver a ensamblar archivos divididos en múltiples mensajes utilizando la línea de asunto, lo cual no es confiable. [ ¿según quién? ]
El borrador de propuesta de yEncode se publicó el 31 de julio de 2001. [10] En noviembre de ese año se incluyó un codificador y decodificador de referencia en la versión gratuita MyNews 1.9. [11] El 14 de noviembre de 2001 se publicó yDec, un decodificador gratuito para Win32. El 21 de marzo de 2002, Agent dio soporte a yEnc con la versión 1.91. [12] [13] Debido a los comentarios de Juergen Helbing, el lanzamiento se pospuso una semana. [14] [15] Un par de días después del lanzamiento, Jürgen Helbing escribió que Forté implementó yEnc de la mejor manera imaginable . [16]
Stuffit Deluxe agregó soporte para yEnc con la versión 8.0 en 2003. [17] [18] PowerArchiver 9.2 agregó soporte para yEnc en mayo de 2005. [19]
no existen estándares oficiales para yEnc, se usa ampliamente para publicar archivos binarios en grupos de noticias.
Agent 1.91 ofrece soporte completo para yEnc, un nuevo algoritmo de codificación de Usenet para binarios.
La versión 1.92 del lector de noticias Usenet de Forté agrega una carpeta de basura, mejora algunas funciones existentes y se ocupa de varios errores; pero más importante que las correcciones y mejoras es el soporte adicional de la aplicación para el algoritmo de codificación binaria YEnc.