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.
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 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:
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 |
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:
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.
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.
Opcional. Permite describir las partes.
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.
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).
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== |
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.