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.
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 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:
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 |
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:
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.
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.
Opcional. Permite que as partes sejam descritas.
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.
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).
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== |
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.