Estaba leyendo sobre la codificación Base64, y encontré esto en Wikipedia:
Los esquemas de codificación Base64 se usan comúnmente cuando existe la necesidad de codificar datos binarios que deben almacenarse y transferirse a través de medios diseñados para manejar datos textuales.
... y el ejemplo dado es el envío de archivos binarios por correo electrónico.
Estoy tratando de entender por qué se necesita base64. Dado que los datos binarios son un montón de bytes, ¿no serían directamente traducibles a ASCII, que son datos textuales? ¿Por qué se necesita base64? ¿O tiene el correo electrónico un problema con los caracteres de control en ASCII?
Respuestas:
Hay un buen artículo de Wikipedia sobre esto.
Las primeras iteraciones de NCP utilizadas por ARPAnet se parecían más a las secuencias de bits que a las de bytes, o los intentos de negociar un tamaño de bytes conveniente; el byte de 8 bits solo se estandarizó mucho más tarde. También hubo varios intentos de crear protocolos de transferencia de archivos que funcionarían en diferentes máquinas (el correo era inicialmente una función del protocolo FTP, principalmente como los comandos
MAILyMLFL, luego se dividió en MTP , luego SMTP ). Esas máquinas a menudo tenían diferentes codificaciones de caracteres (ASCII vs EBCDIC) o incluso diferentes tamaños de bytes , bytes de 8 bits frente a 6 bits frente a ...Por lo tanto, las funciones de transferencia de correo se definieron inicialmente para transferir mensajes relativamente cortos en texto sin formato; específicamente, "NVT-ASCII". Por ejemplo, RFC 772 dice:
Aunque se transmitían ocho bits a través del cable, el octavo bit a menudo se descartaba o se destrozaba, ya que no era necesario preservarlo; de hecho, algunos protocolos requieren que el octavo bit se establezca en cero, como el RFC SMTP inicial como se cita a continuación. En otras palabras, el software no estaba limpio de 8 bits .
Esto persistió durante mucho tiempo incluso después de que las codificaciones de caracteres ISO-8859- # de 8 bits se generalizaran. Aunque algunos servidores ya estaban limpios en 8 bits, muchos otros no lo estaban, y el envío a ciegas de datos de 8 bits habría resultado en mensajes destrozados.
Más tarde, se publicó "SMTP extendido" , permitiendo a los servidores de correo declarar extensiones SMTP que admitían; uno de ellos fue
8BITMIME, lo que indica que el servidor receptor podría aceptar con seguridad los datos de 8 bits. Las partes del mensaje MIME pueden tener " Codificación de transferencia de contenido : 8 bits", lo que indica que no están codificadas de ninguna manera.Sin embargo, el protocolo SMTP permaneció basado en la línea y tiene el límite de línea de 998 octetos, además de usar una
.línea (0D 0A 2E 0D 0A) como el indicador de "fin de mensaje". Esto significa que, aunque la mayoría de los archivos binarios podrían enviarse sin modificaciones, aún es posible que los archivos que contienen esta secuencia de octetos se interpreten como el final del mensaje transferido, y el resto del archivo como un comando SMTP, posiblemente causando daños. Del mismo modo, el servidor receptor puede cortar una "línea" de más de 998 octetos.En 2000, la extensión ESMTP "BINARYMIME" se publicó como RFC 3030 , lo que permite la transferencia de datos binarios en bruto a través de SMTP. El mensaje ahora se transfiere en fragmentos de longitud previamente indicada, con un fragmento de longitud cero utilizado como terminador, y ya no se necesitan codificaciones Base64 y similares. Desafortunadamente, pocos servidores SMTP admiten esta extensión; por ejemplo, ni Postfix ni Exim4 anuncian
CHUNKINGen respuesta a EHLO. Para aprovechar BINARYMIME, todos los servidores de la ruta del mensaje tendrían que admitirlo, que puede ser más que uno o dos.Ver también:
fuente
Algunos sistemas y software de correo electrónico antiguos no estaban limpios en 8 bits , el octavo bit se usaba como un carácter de control. Esto fue suficiente para acumular archivos binarios, por lo tanto, se necesitaba Base64 (u otros esquemas de codificación).
fuente