Verifique esta referência rápida para os cabeçalhos MIME comuns.
Estas informações não fornecem um especificação definitiva de MIME. Em alguns casos, o analisador MIME permite documentos que não sã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 tem conhecimento especial somente do campo de cabeçalho Tipo de Conteúdo.
Todos os cabeçalhos MIME podem incluir comentários 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 é padronizado como text/plain. Content-Type define o tipo de dados em cada parte como um type/subtype. O analisador MIME aceitar a maioria dos valores para Content-Type e os armazena na árvore lógica. As únicas exceções são:
Sintaxe:
Content-Type: type/subtype;parameter
em que tipo e subtipo define o Content-Type e todos os parâmetros opcionais são delimitados por ponto e vírgula.
Exemplo 1:
Content-Type: multipart/related;type=text/xml
No exemplo 1, o Content-Type é definido como multipart/related e também possui uma definição de parâmetro opcional (type=text/xml). Embora esta estrutura esteja sintaticamente correta, porque um parâmetro de limite válido não existe, esta mensagem é 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. O valor do limite pode opcionalmente ser colocado entre aspas. Quando ele aparece no corpo MIME, o valor é precedido pela sequência '--' e você deve assegurar que o valor resultante (neste exemplo, --Boundary) não possa aparecer no corpo da mensagem. Se os dados da mensagem estiverem codificados como quoted-printable, você deverá incluir um limite que inclua uma sequência como "=_", que não pode aparecer em um corpo de quoted-printable.
A tabela a seguir mostra alguns valores de Content-Type comuns. Outros valores são permitidos e armazenados na árvore lógica.
Content-Type | Descrição |
---|---|
text/plain | Geralmente usado para um correio típico ou mensagem de notícias. text/richtext também é comum. |
text/xml | Geralmente usado 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 | Usado para dados xml específicos do aplicativo. |
x-type | Utilizado para tipo de conteúdo não padrão. Ele deve iniciar com os caracteres 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. Nuitos Content-Types são representados cmo caractere de 8 bits ou dados binários e podem incluir XML, que geralmente usa codificação UTF-8 ou UTF-16. Este tipo de dado não pode ser transmitido sobre alguns protocolos de transporte e podem ser codificados para 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 valores a seguir são permitidos apenas pelo Perfil Básico de WS-I:
Todos os valores 7bit, 8bit e binary indicam que não ocorreu nenhuma codificação. Um gateway de correio em conformidade com MIME pode usar este valor para controlar como ele trata 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 somente caracteres que não são de 7 bits no original são codificados e é destinado a gerar um documento que ainda seja legível. Esta configuração é para ser usada mais provavelmente em conjunto com um Content-Type igual a text/plain.
Opcional. Este campo possibilita que partes sejam rotuladas e referenciadas a partir de outras partes da mensagem. Estas partes geralmente são referidas a partir da parte 0 (a primeira) da mensagem.
Opcional. Este campo possibilita que partes sejam descritas.
A seção a seguir fornece um guia básico à codificação base64 e quoted-printable; consulte RFC 1521 (com link no final deste tópico) 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 de linha máximo nos dados codificados é de 76 caracteres e quebras de linha (e todos os outros caracteres que não estão no alfabeto acima) são ignoradas durante a codificação.
Exemplos
Input | Out |
---|---|
Alguns dados codificados em base64. | U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg== |
life of brian | bGlmZSBvZiBicmlhbg== |
what | d2hhdA== |
Esta codificação é apropriada somente se a maioria dos dados for formada de caracteres para impressão. Especificamente, caracteres nis intervalos 33-60 e 62-126 geralmente são representados pelos caracteres ASCII correspondentes. Caracteres de controle e dados de 8 bits devem ser representados pela sequência de = seguida por um par de dígitos hexadecimais.
O espaço ASCII padrão <SP> e a guia horizontal <HT> representam a si mesmos, a menos que eles apareçam no final da linha codificada (sem uma quebra de linha suave), nesse caso o formato hexadecimal equivalente deve ser usado (=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.
Para base64, o comprimento de linha máximo 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.