yEnc

yEnc es un algoritmo de conversión  (in) de formato de datos , de binario a texto. Normalmente se utiliza en Usenet para la transferencia de archivos. Tiene como objetivo reemplazar las codificaciones históricas uuencode y base64 , gracias a su mejor eficiencia.

De hecho, reduce la sobrecarga de las codificaciones anteriores (uuencode y base64, en seis bits) mediante el uso de “  ASCII extendido  ” (en ocho bits). El costo adicional de esta codificación es a menudo del orden del uno al dos por ciento, mientras que el de las codificaciones de seis bits es del 33 al 40%. Como resultado, el cuerpo del mensaje (que contiene el archivo adjunto ) es más pequeño y se puede entregar más rápido.

Otra ventaja de la codificación yEnc es agregar un tipo de suma de comprobación de CRC , que verifica la integridad del archivo adjunto.

La codificación yEnc fue creada y colocada en el dominio público por Jürgen Helbing en 2001 . Solo se describe de manera informal, no tiene ninguna estandarización ( RFC ).

Problemas

La codificación yEnc tiene varios inconvenientes ya presentes en la codificación uuencode, y que mientras tanto han sido resueltos por MIME .

• Se basa en la búsqueda de líneas especiales a partir de =ybeginy =yendpara delimitar las porciones codificadas. Esta técnica no es completamente confiable ya que nada impide que el contenido de un mensaje, especialmente si habla de yEnc, contenga estas cadenas.

• Se basa en el asunto del mensaje (el encabezado Subject:) para volver a ensamblar los archivos divididos, lo que nuevamente no es robusto.

Además, yEnc presenta debilidades adicionales.

• Afirma dar a ciertos campos de encabezado una estructura particular, mientras que es imposible obligar a otros clientes a respetar estas restricciones para usos distintos a la codificación yEnc; incluso los clientes yEnc no siempre respetan esta convención, como se denuncia en la página de inicio de yEnc. En particular, el asunto del mensaje debe contener la cadena yEnc, el nombre del archivo y el número de pieza. MIME resuelve este aspecto al completar esta información en encabezados dedicados.

• Donde uuencode respetó la forma habitual de un mensaje de Internet, es decir, la de un flujo textual, la codificación yEnc produce un flujo arbitrario de bytes. En particular, un decodificador yEnc debe conocer de antemano el tamaño de los datos a decodificar para saber cuándo detenerse. Esta información se incluye en la línea de salida delimitadora y se recuerda en la línea final de delimitación para su verificación.

• El uso de valores de ocho bits provoca problemas de compatibilidad. Es posible que algunos canales de transmisión no admitan dichos valores. Además, todavía existe el riesgo de que los sistemas interpreten el flujo de bytes producido por yEnc, que debe considerarse un flujo binario, como texto y lo modifiquen en consecuencia, por ejemplo, convirtiendo entre codificaciones de texto . Además, en aras de la conformidad con los estándares de Internet, algunos sistemas podrían decidir volver a codificar el flujo de yEnc con uuencode o base64, cancelando así todo el interés de yEnc.

Finalmente, la falta de estandarización puede verse como un problema.

Con la excepción de la pequeña sobrecarga de la codificación en sí, el estándar MIME ya ofrece, dentro de un marco estandarizado, todas las funcionalidades de yEnc: transmisión de datos binarios, división en varias partes, líneas delimitadoras, verificación de integridad (a través de MD5 , donde yEnc utiliza CRC-32 ). Por esta razón, incorporar la codificación yEnc en el estándar MIME, junto con base64 y quoted-printable, resolvería la mayoría de estos problemas. Sin embargo, aunque se ha sugerido esto, no se ha producido ninguna especificación formal o informal.

Notas y referencias

1. (en) Jürgen Helbing , "  yencode - Una codificación rápida y sucia para binarios  " [ archivo28 de agosto de 2013] , en yenc.org ,5 de marzo de 2002. “  Los mecanismos existentes para la transmisión de información binaria por correo electrónico y grupos de noticias utilizan únicamente texto ASCII de 7 bits. Los datos codificados resultantes son hasta un 40% más grandes que la información binaria original. […] La sobrecarga de datos binarios codificados en y puede ser tan pequeña como 1-2%.  "
2. (en) Jürgen Helbing , "  Opponents to yEnc  " [ archivo28 de agosto de 2013] , en yenc.org ,10 de junio de 2002
3. (en) Jeremy Nixon , "  Why is bad for Usenet yEnc  " [ archivo 29 de agosto de 2013] ,17 de marzo de 2002
4. (en) Curt Welch , "  ¿Qué pasa con yEnc?  " [ Archivo de 11 de agosto de 2013] ,19 de septiembre de 2002
5. (en) Noel Farber , “  yEnc considera perjudicial  ” ( Archivo • Wikiwix • Archive.is • Google • ¿Qué hacer? ) ,4 de marzo de 2002
6. (en) Jürgen Helbing , "  Página de inicio  " [ archivo28 de agosto de 2013] , en yenc.org ,30 de marzo de 2003. "  30. Marzo de 2003: Noticia de última hora: Algunas neticens comenzaron a publicar mensajes yEncoded sin la palabra clave obligatoria: yEnc en la línea de asunto. Algunas herramientas permiten publicar sin las comillas alrededor del nombre del archivo. Ambas tendencias no cumplen con la especificación yEnc. Los programadores deben cumplir honestamente las especificaciones.  "
7. (en) Jeremy Nixon , "  Una mejor manera de publicar binarios de Usenet es  " [ archive11 de agosto de 2013] ,16 de agosto de 2002

enlaces externos

• (es) Web oficial de yEnc
• (en) Texto de especificación de yEnc