WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Campos de Cabeçalho Padrão MIME

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.

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 é 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:

  • O analisador MIME rejeita qualquer valor de Content-Type com type = message.
  • O analisador MIME assume que um valor de Content-Type com type = multipart introduz um documento MIME multiparte e rejeita um valor desse tipo 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, um valor de limite exclusivo é necessário para cada nível de aninhamento.

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
Content-Transfer-Encoding

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:

  • 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. 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.

Content-ID

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.

Content-Description

Opcional. Este campo possibilita que partes sejam descritas.

Codificações MIME

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.

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).

Este diagrama mostra como dados de 8 bits são transformados 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 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==
quoted-printable

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.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:29:30


Tópico de ReferênciaTópico de Referência | Versão 8.0.0.5 | ad30590_