email - que - Content Transfer Encoding 7bit or 8 bit

que es content transfer encoding

Question

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

¿Cuál es la diferencia entre estos dos? ¿Cuál es recomendado? ¿Hay alguna codificación especial requerida para el cuerpo del correo electrónico para establecer estos encabezados?

Answer 1

Puede ser un poco denso de leer, pero la sección "Content-Transfer-Encoding" 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:

Fondo

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

El contenido que deseamos enviar a menudo no obedecerá esta restricción inherentemente. Piense en un archivo de imagen o en un archivo de texto que contenga 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 discrepancia.

Los valores del Content-Transfer-Encoding describen la regla que ha elegido para resolver este problema.

Codificación de 7 bits

7bit simplemente significa "Mis datos solo constan de caracteres US-ASCII, que solo utilizan los 7 bits inferiores para cada personaje". Básicamente está garantizando que todos los bytes en su contenido ya se adhieren a las restricciones de SMTP, por lo que no necesita un tratamiento especial. Puedes leerlo tal como está.

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

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

Codificación de 8 bits

8bit significa "Mis datos pueden incluir caracteres ASCII extendidos, pueden usar el 8vo (más alto) bit para indicar caracteres especiales fuera de los caracteres estándar de 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 se 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 de 7 7bit , ya que le da más libertad en su contenido. Sin embargo, RFC 1341 contiene este tidbit:

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

RFC 1341 salió hace más de 20 años. Desde entonces, obtuvimos Extensiones MIME de 8 bits en RFC 6152 . Pero incluso entonces, los límites de línea aún pueden aplicarse:

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

Codificación binaria

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

Quoted Printable

Antes de la extensión 8BITMIME , tenía que haber una forma de enviar contenido que no podía ser de 7 7bit través de 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 codificación quoted-printable (definida en la Sección 5.1 de RFC 1341) está diseñada para manejar esto. Hace dos cosas:

• Define cómo escapar caracteres que no sean US-ASCII para que puedan representarse solo en 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 por un humano que 7bit u 8bit , pero admite un rango mucho más amplio de contenido posible.

Codificación Base64

Si sus datos no son en gran medida de texto (por ejemplo, un archivo de imagen), no tiene muchas opciones. 7bit está fuera de la mesa. 8bit y binary no fueron compatibles antes de las RFC de extensión MIME. quoted-printable funcionaría, pero es realmente ineficiente (cada byte va a estar representado por 3 caracteres).

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

La gran desventaja es que los datos codificados en base64 son prácticamente ilegibles para los humanos, incluso si se trata simplemente de texto "simple" debajo.