Codificação de transferência de conteúdo de 7 bits ou 8 bits

Ao enviar conteúdo de e-mail, é necessário definir o header “Content Transfer Encoding”. Eu observei muitos headers de e-mails que recebi. Alguns e-mails usando “7bit” e alguns estão usando “8bit”.

Qual é a diferença entre esses dois? Qual é recomendado? Existe alguma codificação especial necessária para o corpo do email para definir esses headers?

Pode ser um pouco difícil de ler, mas a seção “Content-Transfer-Encoding” do RFC 1341 tem todos os detalhes:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

A situação vai de mal a pior. Aqui está meu resumo:

fundo

SMTP, por definição (RFC 821), limita o correio a linhas de 1000 caracteres de 7 bits cada. Isso significa que nenhum dos bytes enviados pelo pipe pode ter o bit mais significativo (“maior ordem”) definido como “1”.

O conteúdo que queremos enviar muitas vezes não obedece a essa restrição inerentemente. Pense em um arquivo de imagem ou em um arquivo de texto que contenha caracteres Unicode: os bytes desses arquivos geralmente terão seu 8º bit definido como “1”. O SMTP não permite isso, portanto, é necessário usar “transferência de codificação” para descrever como você trabalhou com a incompatibilidade.

Os valores para o header Content-Transfer-Encoding descrevem a regra que você escolheu para resolver esse problema.

Codificação 7Bit

7bit significa simplesmente “Meus dados consistem apenas em caracteres US-ASCII, que usam apenas os 7 bits inferiores para cada caractere”. Você basicamente garante que todos os bytes em seu conteúdo já cumpram as restrições do SMTP e, portanto, não precisa de tratamento especial. Você pode apenas ler como está.

Observe que quando você escolhe 7 7bit , concorda que todas as linhas do seu conteúdo têm menos de 1.000 caracteres.

Contanto que seu conteúdo esteja de acordo com essa regra, o 7bit é a melhor codificação de transferência, já que não é necessário nenhum trabalho extra; você acabou de ler / escrever os bytes quando eles saem do cano. Também é fácil ver o conteúdo de 7 7bit e dar sentido a ele. A ideia aqui é que, se você está apenas escrevendo em “texto simples em inglês”, tudo bem. Mas isso não foi verdade em 2005 e não é verdade hoje.

Codificação 8Bit

8bit significa “Meus dados podem include caracteres ASCII estendidos; eles podem usar o 8º (mais alto) bit para indicar caracteres especiais fora dos caracteres padrão US-ASCII de 7 bits.” Tal como acontece com 7 7bit , ainda há um limite de linha de 1000 caracteres.

8bit , assim como o 7bit , não faz nenhuma transformação dos bytes conforme eles são gravados ou lidos no fio. Significa apenas que você não está garantindo que nenhum dos bytes terá o maior bit definido como “1”.

Isto parece ser um passo acima de 7 7bit , uma vez que lhe dá mais liberdade em seu conteúdo. No entanto, o RFC 1341 contém este boato:

A partir da publicação deste documento, não há transportes de Internet padronizados para os quais seja legítimo include dados não codificados de 8 bits ou binários em corpos de correio. Portanto, não há circunstâncias nas quais a codificação de transferência de conteúdo “8bit” ou “binária” seja realmente legal na Internet.

RFC 1341 saiu há mais de 20 anos. Desde então, obtivemos Extensões MIME 8bit no RFC 6152 . Mas, mesmo assim, os limites de linha ainda podem ser aplicados:

Note que esta extensão NÃO elimina a possibilidade de um servidor SMTP limitar o comprimento da linha; servidores estão livres para implementar essa extensão, mas ainda assim definir um limite de comprimento de linha não inferior a 1000 octetos.

Codificação Binária

binary é o mesmo que 8bit , exceto que não há restrição de comprimento de linha. Você ainda pode include qualquer caractere que desejar e não há codificação extra. Semelhante a 8bit , o RFC 1341 afirma que não é realmente uma codificação de transferência de codificação legítima. RFC 3030 estendeu isso com BINARYMIME .

Quoted Printable

Antes da extensão 8BITMIME , precisava haver uma maneira de enviar conteúdo que não pudesse ser 7bit SMTP. Arquivos HTML (que podem ter mais de 1000 caracteres) e arquivos com caracteres internacionais são bons exemplos disso. A codificação quoted-printable (definida na seção 5.1 da RFC 1341) foi projetada para lidar com isso. Isso faz duas coisas:

  • Define como escaping caracteres não-US-ASCII para que eles possam ser representados em apenas caracteres de 7 bits. (Versão curta: eles são exibidos como um sinal de igual e dois caracteres de 7 bits.)
  • Define que as linhas não terão mais de 76 caracteres e que as quebras de linha serão representadas usando caracteres especiais (que são então escapados).

Quoted Printable, por causa das linhas curtas e curtas, é muito mais difícil de ser lido por um ser humano do que 7 8bit ou 8bit , mas suporta uma faixa muito maior de conteúdo possível.

Codificação Base64

Se os seus dados são em grande parte não textuais (ex: um arquivo de imagem), você não tem muitas opções. 7bit está fora da mesa. 8bit e binary não eram suportados antes dos RFCs de extensão MIME. quoted-printable funcionaria, mas é realmente ineficiente (cada byte será representado por 3 caracteres).

base64 é uma boa solução para este tipo de dados. Ele codifica 3 bytes brutos como 4 caracteres US-ASCII, o que é relativamente eficiente. A RFC 1341 limita ainda mais o tamanho da linha de dados codificados em base64 a 76 caracteres para caber em uma mensagem SMTP, mas é relativamente fácil de gerenciar quando você está apenas dividindo ou concatenando caracteres arbitrários em comprimentos fixos.

A grande desvantagem é que os dados codificados em base64 são praticamente ilegíveis para os seres humanos, mesmo que seja apenas um texto “simples” por baixo.