Campos de cabeceras MIME estándar

Consulte esta guía de consulta rápida de las cabeceras MIME comunes.

Esta información no proporciona una especificación definitiva de MIME. En algunos casos, el

analizador MIME permite documentos que estrictamente no son válidos según el estándar. Por
ejemplo, no insiste en la presencia de una cabecera MIME-Version. Todos los campos de
cabeceras MIME estándar se escriben simplemente en el árbol lógico tal y como aparecen en el
documento MIME. El analizador MIME sólo presta una atención especial al campo de cabecera
Content-Type.

Todas las cabeceras MIME pueden incluir comentarios encerrados entre paréntesis, como se
muestra en el ejemplo de cabecera MIME-Version.

Campos de cabeceras MIME

MIME-Version

Ejemplo:
MIME-version: 1.0 (generado por mi aplicación 1.2)

Para que un documento MIME se ajuste a RFC 2045, es necesario que este campo esté en la
cabecera de nivel superior con un valor de 1.0. MIME-Version no se debe especificar en las
partes individuales.

Content-Type

Content-Type no es necesario para que un documento se ajuste a RFC 2045, pero el

analizador MIME requiere una cabecera Content-Type de nivel superior. El valor
predeterminado de Content-Type text/plain. Content-Type define el tipo de datos de cada
parte como un type/subtype. El analizador MIME acepta la mayor parte de los valores para
Content-Type y los almacena en el árbol lógico. Las únicas excepciones son:

• El analizador MIME rechaza cualquier valor Content-Type con type = message

• El analizador MIME presupone que un valor Content-Type de type = multipart
introduce un documento MIME de varias partes y rechaza este valor si no contiene un
parámetro de límite válido. El valor del parámetro de límite define el separador entre
las partes del mensaje de un mensaje de varias partes. En un mensaje de varias partes
anidado, se requiere un valor de límite exclusivo para cada nivel de anidamiento.

Sintaxis:
Content-Type: type/subtype;parameter

donde type y subtype definen Content-Type y todos los parámetros adicionales se delimitan
con signos de punto y coma.

Ejemplo 1:
Content-Type: multipart/related;type=text/xml

En el ejemplo 1, Content-Type se define como multipart/related y también tiene una

definición de parámetro opcional (type=text/xml). Aunque esta estructura es correcta
sintácticamente, como no existe un parámetro de límite válido este mensaje se rechaza.
 Ejemplo 2:
Content-Type: multipart/related;boundary=Boundary;type=text/xml

El ejemplo 2 muestra una definición de Content-Type válida, en términos de sintaxis y de

semántica. El valor de límite se puede incluir opcionalmente entre comillas. Cuando aparece
en el cuerpo del mensaje MIME, el valor va precedido de la secuencia '--' y se debe asegurar
de que el valor resultante (en este ejemplo --Boundary) no aparezca en el cuerpo del
mensaje. Si se codifican los datos de mensaje como quoted-printable, deberá incluir un
límite que incluya una secuencia, por ejemplo "=_", que no puede aparecer en un cuerpo
quoted-printable.

La tabla siguiente muestra valores Content-Type comunes. Se permiten otros valores y se

almacenan en el árbol lógico.

Content-Type Descripción
text/plain Se utiliza normalmente para un mensaje típico de correo o
de noticias. También es común text/richtext.
text/xml Se utiliza normalmente con SwA (SOAP with Attachments).
application/octet- Se utiliza cuando el mensaje es de tipo desconocido y
stream contiene cualquier tipo de datos como bytes.
application/xml Se utiliza para datos xml específicos de la aplicación.
x-type Se utiliza para el tipo de contenido no estándar. Debe
comenzar por los caracteres x-.
image/jpeg Se utiliza para las imágenes. image/jpeg and image/gif son
formatos de imágenes comunes que se utilizan
multipart/related Se utiliza para varias partes relacionadas de un mensaje.
Específicamente se utiliza con SwA (SOAP with
Attachments)
multipart/signed Se utiliza para varias partes relacionadas de un mensaje
incluida la firma. Específicamente se utiliza con S/MIME
multipart/mixed Se utiliza para varias partes independientes de un mensaje
Content-Transfer-Encoding

Opcional. Muchos Content-Types se representan como datos de caracteres de 8 bits o datos

binarios y pueden incluir XML, que generalmente utiliza la codificación UTF-8 o UTF-16.
Este tipo de datos no se puede transmitir a través de algunos protocolos de transporte y se
puede codificar a 7 bits.

El campo de cabecera Content-Transfer-Encoding se utiliza para indicar el tipo de

transformación que se ha utilizado para codificar este tipo de datos en un formato de 7 bits.

Los valores siguientes sólo están permitidos por el perfil básico WS-I:

• 7bit - el valor predeterminado

• 8bit
• binary
• base64
• quoted-printable

Los valores 7bit, 8bit y binary significan todos que no se lleva a cabo la codificación. Es
posible que una pasarela de correo compatible con MIME utilice este valor para controlar
 cómo maneja el mensaje. Por ejemplo, codificarlo como 7bit antes de pasarlo a través de
SMTP.

Los valores base64 y quoted-printable significan que el contenido se ha codificado. El valor

quoted-printable significa que sólo los caracteres del original que no son de 7 bits están
codificados y están diseñados para generar un documento que sigue siendo legible para un
usuario. Este valor con toda probabilidad se utiliza junto con un Content-Type de
text/plain.

Content-ID

Opcional. Este campo permite que las partes tengan una etiqueta y se haga referencia a ellas
desde otras partes del mensaje. Generalmente, se hace referencia a estas partes desde la
parte 0 (la primera) del mensaje.

Content-Description

Opcional. Este campo permite describir las partes.

Codificaciones MIME
El apartado siguiente ofrece una guía básica a la codificación base64 y quoted-printable; consulte
RFC 1521 (al final de este tema se facilita un enlace) para consultar una especificación definitiva
de las codificaciones MIME.

base64

Los datos originales se dividen en grupos de 3 octetos. A continuación, cada grupo se trata
como 4 grupos de 6 bits concatenados, cada uno de los cuales se convierte en un solo dígito
del alfabeto base64. El alfabeto base64 es A-Z, a-z, 0-9, y / (con A=0 y /=63).

Este diagrama muestra cómo se dividen los datos de 8 bits en datos

codificados de 6 bits

Si hay menos de 24 bits disponibles al final de los datos, los datos codificados se añaden
utilizando el carácter “=” . La longitud máxima de línea de los datos codificados es de 76
caracteres y durante la decodificación se ignoran los saltos de línea (y todos los demás
caracteres que no estén en el alfabeto anterior).

Ejemplos:
 Entrada Output
Algunos datos
codificados en U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
base64.
life of brian bGlmZSBvZiBicmlhbg==
what d2hhdA==

quoted-printable

Esta codificación sólo es apropiada si la mayor parte de los datos consta de caracteres
imprimibles. Específicamente, los caracteres de los rangos 33-60 y 62-126 se suelen
representar mediante los caracteres ASCII correspondientes. Los caracteres de control y los
datos de 8 bits se deben representar mediante sequence = seguido de un par de dígitos
hexadecimales.

El espacio ASCII estándar< SP> y la tabulación horizontal <HT> se representan por sí

solas, a menos que aparezcan al final de una línea codificada (sin un salto de línea), en cuyo
caso se debe utilizar el formato hexadecimal equivalente (=09 y =20 respectivamente).

Los saltos de línea de los datos se representan mediante la secuencia de salto de línea RFC
822 <CR><LF> y se deben codificar como "=0D=0A" si se codifican los datos binarios.

Para base64, la longitud máxima de línea de los datos codificados es de 76 caracteres. Se

utiliza un signo ‘=' al final de una línea codificada (como un salto de línea ‘suave') para
indicar al decodificador que la línea debe continuar.