Ao enviar conteúdo de e-mail, é necessário definir o cabeçalho "Codificação de transferência de conteúdo". Observei muitos cabeçalhos de e-mails que recebi. Alguns e-mails usam "7 bits" e outros usam "8 bits".
Qual é a diferença entre esses dois? O que é recomendado? Existe alguma codificação especial necessária para o corpo do e-mail para definir esses cabeçalhos?
Respostas:
Pode ser um pouco denso 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á o meu resumo:
O SMTP, por definição (RFC 821), limita o correio a linhas de 1000 caracteres de 7 bits cada. Isso significa que nenhum dos bytes que você envia pelo tubo pode ter o bit mais significativo (de "ordem superior") 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 contém caracteres Unicode: os bytes desses arquivos geralmente terão seu 8º bit definido como "1". O SMTP não permite isso, então você precisa usar a "codificação de transferência" para descrever como você contornou a incompatibilidade.
Os valores do Content-Transfer-Encodingcabeçalho descrevem a regra que você escolheu para resolver esse problema.
7bitsignifica simplesmente "Meus dados consistem apenas em caracteres US-ASCII, que usam apenas os 7 bits inferiores para cada caractere." Você está basicamente garantindo que todos os bytes em seu conteúdo já aderem às restrições do SMTP e, portanto, não precisa de tratamento especial. Você pode apenas ler como está.
Observe que, ao escolher 7bit, você concorda que todas as linhas de seu conteúdo têm menos de 1000 caracteres.
Contanto que o seu conteúdo cumpra essas regras, 7bité a melhor codificação de transferência, já que não há trabalho extra necessário; você apenas lê / grava os bytes conforme eles saem do tubo. Também é fácil visualizar o 7bitconteúdo e entendê-lo. A ideia aqui é que se você estiver apenas escrevendo em "texto simples em inglês", você ficará bem. Mas isso não era verdade em 2005 e não é verdade hoje.
8bitsignifica "Meus dados podem incluir caracteres ASCII estendidos; eles podem usar o 8º bit (mais alto) para indicar caracteres especiais fora dos caracteres US-ASCII de 7 bits padrão." Tal como acontece com 7bit, ainda há um limite de linha de 1000 caracteres.
8bit, assim como 7bit, não faz nenhuma transformação dos bytes conforme eles são gravados ou lidos na conexão. Significa apenas que você não está garantindo que nenhum dos bytes terá o bit mais alto definido como "1".
Isso parece um passo à frente 7bit, pois dá a você mais liberdade em seu conteúdo. No entanto, RFC 1341 contém este boato:
Até a publicação deste documento, não havia transportes de Internet padronizados para os quais fosse legítimo incluir dados binários ou de 8 bits não codificados em corpos de correspondência. Portanto, não há nenhuma circunstância em que a codificação de transferência de conteúdo "8 bits" ou "binária" seja realmente legal na Internet.
O RFC 1341 foi lançado há mais de 20 anos. Desde então, temos extensões MIME de 8 bits na RFC 6152 . Mesmo assim, os limites de linha ainda podem ser aplicados:
Observe que essa extensão NÃO elimina a possibilidade de um servidor SMTP limitar o comprimento da linha; os servidores são livres para implementar essa extensão, mas, no entanto, estabelecem um limite de comprimento de linha não inferior a 1000 octetos.
binaryé o mesmo que 8bit, exceto que não há restrição de comprimento de linha. Você ainda pode incluir os caracteres que desejar e não há codificação extra. Semelhante a 8bit, a RFC 1341 afirma que não é realmente uma codificação de transferência de codificação legítima. RFC 3030 estendeu isso com BINARYMIME.
Antes da 8BITMIMEextensão, precisava haver uma maneira de enviar conteúdo que não pudesse ser 7bitpor SMTP. Arquivos HTML (que podem ter mais de 1000 linhas de caracteres) e arquivos com caracteres internacionais são bons exemplos disso. A quoted-printablecodificação (definida na seção 5.1 do RFC 1341) foi projetada para lidar com isso. Ele faz duas coisas:
Imprimível citado, por causa das linhas curtas e de escape, é muito mais difícil de ler por um humano do que 7bitou 8bit, mas suporta uma gama muito mais ampla de conteúdo possível.
Se seus dados não forem em grande parte texto (por exemplo: um arquivo de imagem), você não tem muitas opções. 7bitestá fora da mesa. 8bite binarynão eram suportados antes das RFCs de extensão MIME. quoted-printablefuncionaria, 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. O RFC 1341 limita ainda mais o comprimento da linha de base64dados codificados a 76 caracteres para caber em uma mensagem SMTP, mas isso é relativamente fácil de gerenciar quando você está apenas dividindo ou concatenando caracteres arbitrários em comprimentos fixos.
A grande desvantagem é que os base64dados codificados são praticamente ilegíveis por humanos, mesmo que sejam apenas texto "simples" por baixo.