Al enviar contenido de correo electrónico, es necesario configurar el encabezado "Codificación de transferencia de contenido". Observé muchos encabezados de correos electrónicos que recibí. Algunos correos electrónicos usan "7 bits" y otros usan "8 bits".

¿Cuál es la diferencia entre estos dos? ¿Qué se recomienda? ¿Se requiere alguna codificación especial para el cuerpo del correo electrónico para configurar estos encabezados?

Puede ser un poco denso de leer, pero la sección "Codificación de transferencia de contenido" de RFC 1341 tiene todos los detalles:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

La situación va de mal en peor. Aquí está mi resumen:

Antecedentes

SMTP, por definición (RFC 821), limita el correo a líneas de 1000 caracteres de 7 bits cada una. Eso significa que ninguno de los bytes que envíe por la tubería puede tener el bit más significativo ("orden más alto") establecido en "1".

El contenido que queremos enviar a menudo no obedecerá esta restricción de forma inherente. Piense en un archivo de imagen o un archivo de texto que contiene caracteres Unicode: los bytes de estos archivos a menudo tendrán su octavo bit establecido en "1". SMTP no permite esto, por lo que debe usar "codificación de transferencia" para describir cómo ha solucionado la falta de coincidencia.

Los valores del Content-Transfer-Encodingencabezado describen la regla que eligió para resolver este problema.

Codificación de 7 bits

7bitsimplemente significa "Mis datos constan solo de caracteres US-ASCII, que solo usan los 7 bits inferiores para cada carácter". Básicamente, estás garantizando que todos los bytes de tu contenido ya se adhieren a las restricciones de SMTP, por lo que no necesita un tratamiento especial. Puede leerlo como está.

Tenga en cuenta que cuando elige 7bit, acepta que todas las líneas de su contenido tienen menos de 1000 caracteres de longitud.

Siempre que su contenido se adhiera a esta regla, 7bites la mejor codificación de transferencia, ya que no es necesario ningún trabajo adicional; simplemente lee / escribe los bytes a medida que salen de la tubería. También es fácil observar el 7bitcontenido y darle sentido. La idea aquí es que si solo está escribiendo en "texto en inglés sin formato", estará bien. Pero eso no era cierto en 2005 y no es cierto hoy.

Codificación de 8 bits

8bitsignifica "Mis datos pueden incluir caracteres ASCII extendidos; pueden usar el octavo bit (más alto) para indicar caracteres especiales fuera de los caracteres estándar US-ASCII de 7 bits". Al igual que con 7bit, todavía hay un límite de línea de 1000 caracteres.

8bit, al igual que 7bit, en realidad no realiza ninguna transformación de los bytes a medida que se escriben o leen desde el cable. Simplemente significa que no está garantizando que ninguno de los bytes tenga el bit más alto establecido en "1".

Esto parece un paso adelante 7bit, ya que le brinda más libertad en su contenido. Sin embargo, RFC 1341 contiene este tidbit:

En el momento de la publicación de este documento, no existen transportes de Internet estandarizados para los que sea legítimo incluir datos binarios o de 8 bits no codificados en los cuerpos de correo. Por lo tanto, no hay circunstancias en las que la codificación de transferencia de contenido de "8 bits" o "binaria" sea realmente legal en Internet.

RFC 1341 salió hace más de 20 años. Desde entonces, hemos obtenido extensiones MIME de 8 bits en RFC 6152 . Pero incluso entonces, pueden aplicarse límites de línea:

Tenga en cuenta que esta extensión NO elimina la posibilidad de que un servidor SMTP limite la longitud de la línea; los servidores son libres de implementar esta extensión, pero sin embargo establecen un límite de longitud de línea no menor a 1000 octetos.

Codificación binaria

binaryes lo mismo que 8bit, excepto que no hay restricción de longitud de línea. Aún puede incluir los caracteres que desee y no hay codificación adicional. Similar a 8bit, RFC 1341 establece que no es realmente una codificación de transferencia de codificación legítima. RFC 3030 extendió esto con BINARYMIME.

Cotizado Imprimible

Antes de la 8BITMIMEextensión, era necesario que hubiera una forma de enviar contenido que no pudiera ser 7bitpor SMTP. Los archivos HTML (que pueden tener más de 1000 líneas de caracteres) y los archivos con caracteres internacionales son buenos ejemplos de esto. La quoted-printablecodificación (definida en la Sección 5.1 de RFC 1341) está diseñada para manejar esto. Hace dos cosas:

• Define cómo escapar de los caracteres que no son ASCII de EE. UU. Para que se puedan representar en solo caracteres de 7 bits. (Versión corta: se muestran como un signo igual más dos caracteres de 7 bits).
• Define que las líneas no tendrán más de 76 caracteres y que los saltos de línea se representarán con caracteres especiales (que luego se escapan).

Quoted Printable, debido a las líneas cortas y de escape, es mucho más difícil de leer para un humano que 7bito 8bit, pero admite una gama mucho más amplia de contenido posible.

Codificación Base64

Si sus datos son en gran parte sin texto (por ejemplo, un archivo de imagen), no tiene muchas opciones. 7bitestá fuera de la mesa. 8bity binaryno eran compatibles antes de las RFC de extensión MIME. quoted-printablefuncionaría, pero es realmente ineficiente (cada byte estará representado por 3 caracteres).

base64es una buena solución para este tipo de datos. Codifica 3 bytes sin procesar como 4 caracteres US-ASCII, lo cual es relativamente eficiente. RFC 1341 limita aún más la longitud de línea de los base64datos codificados a 76 caracteres para que quepan en un mensaje SMTP, pero eso es relativamente fácil de administrar cuando solo está dividiendo o concatenando caracteres arbitrarios en longitudes fijas.

La gran desventaja es que los base64datos codificados son prácticamente ilegibles para los humanos, incluso si es solo texto "sin formato" debajo.