Campos de Cabeçalho Padrão MIME

Esta seção é um resumo dos cabeçalhos MIME comuns e pode ser útil como uma referência rápida. Ela não é uma especificação definitiva de MIME. Em alguns casos, o analisador MIME permite documentos não estritamente válidos de acordo com o padrão. Por exemplo, ele não insiste na presença de um cabeçalho MIME-Version. Todos os campos de cabeçalho MIME padrão são apenas gravados na árvore lógica conforme aparecem no documento MIME. O analisador MIME apenas toma uma nota especial do campo de cabeçalho Content-Type.

Todos os cabeçalhos MIME podem incluir comentários colocados entre parênteses, conforme mostrado no exemplo para o cabeçalho MIME-Version.

Campos de Cabeçalho MIME

MIME-Version

Exemplo:

MIME-version: 1.0 (gerado por my-application 1.2)

Para que um documento MIME esteja de acordo com o RFC 2045, este campo é requerido no cabeçalho de nível superior com um valor de 1.0. MIME-Version não deve ser especificado em partes individuais.

Content-Type

Content-Type não é requerido para que um documento esteja de acordo com o RFC 2045, mas um Content-Type de nível superior é requerido pelo analisador MIME. Content-Type assume como padrão text/plains. Content-Type define o tipo de dados em cada parte como um type/subtype. O analisador MIME aceita a maioria dos valores para Content-Type e apenas armazena-os na árvore lógica. As únicas exceções são:

  • O analisador MIME rejeita qualquer valor de Content-Type com o tipo = message
  • O analisador MIME assume que um valor de Content-Type com o tipo = multipart introduz um documento MIME multipartes e rejeita tal valor se ele não contiver um parâmetro de limite válido. O valor do parâmetro de limite define o separador entre partes da mensagem em uma mensagem multipartes. Em uma mensagem multipartes aninhada, é necessário um valor de limite exclusivo para cada nível de aninhamento.

Sintaxe:

Content-Type: type/subtype;parameter

Onde tipo e subtipo definem o Content-Type e os parâmetros opcionais são delimitados por pontos e vírgulas.

Exemplo 1:

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

No exemplo 1, Content-Type é definido como multipart/related e também possui uma definição de parâmetro opcional (type=text/xml). Embora isso seja sintaticamente correto, como não existe nenhum parâmetro de limite válido, esta mensagem será rejeitada.

Exemplo 2:

Content-Type: multipart/related;boundary=Boundary;type=text/xml 

O Exemplo 2 mostra uma definição de Content-Type válida, em termos de sintaxe e de semântica. Opcionalmente, o valor de limite pode ser colocado entre aspas. Quando ele aparece no corpo MIME, o valor é precedido pela seqüência '--' e é necessário atenção porque o valor resultante (neste exemplo ele seria --Boundary) não pode aparecer no corpo da mensagem. Se os dados da mensagem estiverem codificados como quoted-printable, você deve ter um limite que inclua uma seqüência, como "=_", que não pode aparecer em um corpo quoted-printable.

Alguns valores comuns de Content-Type são mostrados abaixo. Quaisquer outros valores são permitidos e apenas armazenados na árvore lógica.

Content-Type Descrição
text/plain Geralmente utilizado para uma mensagem de correio ou de notícias simples. text/richtext também comum.
text/xml Geralmente utilizado com SwA (SOAP with Attachments)
application/octet-stream Utilizado quando a mensagem tem um tipo desconhecido e contém qualquer tipo de dados como bytes.
application/xml Utilizado para dados xml específicos de aplicativos
x-type Utilizado para tipo de conteúdo não padrão. Deve começar com x-
image/jpeg Utilizado para imagens. image/jpeg e image/gif são formatos de imagens comuns utilizados
multipart/related Utilizado para várias partes relacionadas em uma mensagem. Especificamente utilizado com SwA (SOAP with Attachments)
multipart/signed Utilizado para várias partes relacionadas em uma mensagem, incluindo assinatura. Especificamente utilizado com S/MIME
multipart/mixed Utilizado para várias partes independentes em uma mensagem
Content-Transfer-Encoding

Opcional. Muitos Content-Types são representados como dados de caracteres de 8 bits ou binários. Isto pode incluir XML que, geralmente utiliza a codificação UTF-8 ou UTF-16. Este tipo de dados não pode ser transmitido por alguns protocolos de transporte e pode ser codificado como 7 bits.

O campo de cabeçalho Content-Transfer-Encoding é utilizado para indicar o tipo de transformação utilizada para a codificação deste tipo de dados em um formato de 7 bits.

Os únicos valores permitidos pelo WS-I Basic Profile são:

  • 7bit - o padrão
  • 8bit
  • binário
  • base64
  • quoted-printable

Todos os valores 7bit, 8bit e binary indicam que não ocorreu nenhuma codificação. É possível que um gateway de correio em conformidade com MIME possa utilizar este valor para controlar como ele manipulará a mensagem. Por exemplo, codificando-o como 7bit antes de transmitir seu roteamento por SMTP.

Os valores base64 e quoted-printable significam que o conteúdo foi codificado. O valor quoted-printable significa que apenas caracteres que não tenham 7 bits no original são codificados e destina-se a gerar um documento que ainda é legível por humanos. Muito provavelmente, esta configuração será utilizada junto com um Content-Type de tipo text/plain.

Content-ID

Opcional. Permite que partes sejam etiquetadas e referidas a partir de outras pastes da mensagem. Estas partes geralmente são referidas a partir da parte 0 (a primeira) da mensagem.

Content-Description

Opcional. Permite que as partes sejam descritas.

Codificações MIME

A seção a seguir tem como objetivo fornecer um guia básico para as codificações base64 e quoted-printable. Consulte o RFC 1521 para obter uma especificação definitiva de codificações MIME.

base64

Os dados originais são divididos em grupos de 3 octetos. Cada grupo é então tratado como 4 grupos concatenados de 6 bits, sendo cada um deles convertido em um único dígito no alfabeto base64. O alfabeto base64 é A-Z, a-z, 0-9 e / (com A=0 e /=63).

Figura 1. Transformação de Dados base64 Como os dados de 8 bits são divididos em dados codificados de 6 bits.

Se menos de 24 bits estiverem disponíveis no final dos dados, os dados codificados serão preenchidos utilizando o caractere "=". O comprimento máximo da linha nos dados codificados é de 76 caracteres e as quebras de linhas (e quaisquer outros caracteres que não constam do alfabeto acima) são ignoradas durante a decodificação.

Exemplos

Input Out
Alguns dados codificados em base64. U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
life of brian bGlmZSBvZiBicmlhbg==\012
what d2hhdA==
quoted-printable

Esta codificação é apropriada apenas se a maior parte dos dados incluir caracteres imprimíveis. Especificamente, os caracteres nos intervalos 33-60 e 62-126 geralmente são representados pelos caracteres ASCII correspondentes. Os caracteres de controle e dados de 8 bits devem ser representados pela seqüência = seguidos por um par de dígitos hexadecimais.

O espaço ASCII padrão <SP> e a guia horizontal <HT> são representados sozinhos, a menos que apareça no fim de uma linha codificada (sem uma quebra de linha suave); nesse caso, o formato hexadecimal equivalente deve ser utilizado (=09 e =20 respectivamente).

As quebras de linha nos dados são representados pela seqüência de quebra de linha RFC 822 <CR><LF> e devem ser codificadas como "=0D=0A", se os dados binários estiverem sendo codificados.

Em relação ao base64, o comprimento máximo de linha nos dados codificados é de 76 caracteres. Um sinal '=' no final de uma linha codificada (uma quebra de linha 'moderada') é utilizado para informar o decodificador que a linha será continuada.

Conceitos relacionados
Modelagem de Mensagens
O Modelo de Mensagem
Tarefas relacionadas
Desenvolvendo Modelos de Mensagens
Trabalhando com Objetos de Modelo de Mensagem
Referências relacionadas
Informações de Referência do Modelo de Mensagens
Propriedades do Objeto de Modelo de Mensagem
Informações adicionais do domínio MRM
Informações Adicionais sobre Domínio MIME
Informações relacionadas
RFC 1521: MIME Parte Um: Mecanismos para Especificar e Descrever o Formato de Corpos de Mensagens da Internet
RFC 822: Padrão para o Formato de Mensagens de Texto da Internet ARPA
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ad30590_