Campos de cabeceras MIME estándar

Esta sección es un resumen de las cabeceras MIME estándar y puede resultar útil como una guía de consulta rápida. No es 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 por omisión de Content-Type es text/plains. 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 simplemente 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 necesita 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 cualquier parámetro adicional se delimita 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 sintácticamente esto es correcto, ya que no hay un parámetro de límite válido, este mensaje se rechazará.

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 puede encerrarse opcionalmente entre comillas. Cuando aparece en el cuerpo del mensaje MIME, el valor va precedido de la secuencia '--' y debe prestarse atención ya que el valor resultante (en este ejemplo será --Boundary) no puede aparecer en el cuerpo del mensaje. Si se codifican los datos de mensaje como quoted-printable, deberá tener un límite que incluya una secuencia, por ejemplo "=_", que no puede aparecer en un cuerpo quoted-printable.

A continuación, se muestran algunos valores Content-Type comunes. Se permite cualquier otro valor y simplemente se almacena en el árbol lógico.

Content-Type Descripción
text/plain Se utiliza generalmente para un mensaje típico de correo o de noticias. También es común text/richtext.
text/xml Se utiliza generalmente con SwA (SOAP with Attachments)
application/octet-stream Se utiliza cuando el mensaje es de tipo desconocido y 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 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. Esto puede 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 únicos valores permitidos por el perfil básico WS-I es:

  • 7bit - el valor por omisión
  • 8bit
  • binary
  • base64
  • quoted-printable

Los valoes 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 controla 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 pueda leerlo un usuario. Este valor con toda probabilidad se utiliza junto con un Content-Type de text/plain.

Content-ID

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

Content-Description

Opcional. Permite describir las partes.

Codificaciones MIME

La sección siguiente proporciona una guía básica de la codificación base64 y quoted-printable. Consulte RFC 1521 para obtener 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).

Figura 1. Transformación de datos base64Có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 rellenan 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 cualquier otro carácter que no esté en el alfabeto anterior).

Ejemplos:

Input (Entrada) Output (Salida)
Algunos datos codificados en base64. U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
life of brian bGlmZSBvZiBicmlhbg==\012
what d2hhdA==
quoted-printable

Esta codificación sólo es apropiada si la mayor parte de los datos constan 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.

En cuanto a 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 se ha de continuar.

Conceptos relacionados
Modelado de mensajes
El modelo de mensaje
Tareas relacionadas
Desarrollo de modelos de mensaje
Cómo trabajar con objetos de modelo de mensaje
Referencia relacionada
Información de referencia de modelo de mensaje
Propiedades de objeto de modelo de mensaje
Información adicional de dominio MRM
Información adicional de dominio MIME
Información relacionada
RFC 1521: MIME Parte Uno: Mecanismos para especificar y describir el formato de los cuerpos del mensaje de Internet
RFC 822: Estándar para el formato de los mensajes de texto de Internet ARPA
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ad30590_