Ferramentas de desenvolvedor · Codificador e decodificador Base64
Por que os anexos de e-mail são Base64: transporte de MIME, 7 bits e linhas de coluna 76
· Fundo
base64 codificação
O e-mail foi criado para texto de 7 bits ASCII e os anexos precisavam passar por ele. Esta postagem rastreia como MIME adotou Base64, por que as linhas são agrupadas em 76 caracteres e o que isso significa para tamanho e depuração.
O anexo que chegou corrompido através de um relé antigo — o problema de 8 bits que MIME foi inventado para resolver
O e-mail foi projetado nas décadas de 1970 e 1980 apenas para texto de 7 bits ASCII. SMTP, o protocolo que transporta e-mail, espera que cada linha tenha no máximo 998 caracteres de 7 bits ASCII (caracteres 0-127). Enviar um arquivo binário como PDF ou uma imagem diretamente por meio de SMTP falharia: os bytes 128-255 seriam corrompidos ou rejeitados por servidores de e-mail e retransmissores antigos. Os anexos precisam de codificação. MIME (Extensões de correio de Internet multiuso, RFC 2045) resolveu isso definindo valores de cabeçalho de codificação de transferência de conteúdo, incluindo base64, que representa qualquer sequência de bytes como texto 7-bit ASCII.
MIME oferece várias opções de codificação de transferência de conteúdo: 7bit (sem codificação, apenas para ASCII seguro), 8bit (para servidores que suportam bytes de 8 bits, não universais), imprimível entre aspas (codifica apenas bytes não seguros, mantendo ASCII legível) e base64 (codifica tudo, maximizando a compatibilidade). Base64 foi escolhido para anexos binários porque é simples, padronizado e garante segurança em qualquer sistema de correio, não importa quão antigo ou estritamente 7 bits. A desvantagem é o tamanho: Base64 é cerca de um terço maior que os bytes originais.
O problema de transporte que Base64 resolve – representando bytes arbitrários com caracteres imprimíveis
Um 3 KB PDF torna-se aproximadamente 4 KB de texto Base64. O limite de linha de 76 caracteres vem de RFC 2045.
SMTP permite linhas de até 998 caracteres, mas sistemas de e-mail mais antigos e alguns filtros de spam rejeitam linhas longas. RFC 2045 especifica que as linhas MIME Base64 não devem exceder 76 caracteres (mais um final de linha CRLF), para que um servidor de e-mail nunca interrompa o transporte. O limite não é mágico; é um compromisso histórico entre legibilidade (76 caracteres cabem na maioria dos terminais dos anos 1980), compatibilidade com sistemas antigos e evitar detecção como spam ou padrões de vírus.
As opções de saída visíveis nesta ferramenta - preenchimento canônico e quebra automática de caracteres 76 opcional
Os sistemas de correio modernos geralmente suportam linhas mais longas, mas a codificação para linhas de 76 caracteres garante que o anexo chegue até mesmo ao destinatário mais antigo. Depois que RFC 2045 definiu MIME Base64, RFC 4288 (tipos de mídia) e RFC 2183 (Disposição de conteúdo) adicionaram maneiras padronizadas de rotular anexos. Uma mensagem com um anexo PDF inclui um cabeçalho Content-Transfer-Encoding: base64, um cabeçalho Content-Type: application/pdf e os bytes PDF codificados como Base64 com linhas de caracteres 76. Um leitor de e-mail decodifica as linhas removendo as quebras de linha (CRLF caracteres) e depois decodificando o Base64 para recuperar os bytes originais.
A decodificação de um anexo MIME Base64 requer ignorar os espaços em branco. O RFC diz: os decodificadores devem pular quebras de linha (caracteres CR e LF) durante a decodificação. É por isso que um decodificador Base64 que aceita espaços em branco é prático; a maioria dos e-mails MIME reais terão quebras de linha. Alguns decodificadores são rígidos e rejeitam espaços em branco (adequados para contextos como JWT, onde quebras de linha não devem estar presentes), enquanto outros são tolerantes e ignoram espaços em branco (adequados para MIME).
A opção de caractere 76 na prática — como o codificador insere e o decodificador ignora quebras de linha
A ferramenta codificador e decodificador Base64 pode lidar com ambos: aceita um anexo colado com várias linhas e ignora as quebras de linha durante a decodificação. O impacto do tamanho é previsível. RFC 2045 empacotamento base64 adiciona um CRLF (2 bytes) por 76 caracteres de saída. Para um arquivo 10 KB, o Base64 é aproximadamente 13.3 KB, mais CRLF a cada 76 caracteres: cerca de 13.5 KB no total. A sobrecarga é de aproximadamente um terço a mais de bytes.
Os limites de tamanho de e-mail geralmente são indicados para o tamanho codificado, não para o tamanho do arquivo original; um servidor de e-mail com limite 25 MB significa 25 MB da mensagem codificada, não 25 MB de anexos. O cálculo do tamanho do arquivo original requer a divisão por 1.33 (ou mais precisamente, por 4 dividido por 3). A codificação para impressão entre aspas é uma alternativa que mantém a impressão ASCII inalterada e codifica apenas bytes 128-255 e alguns caracteres especiais.
Exemplo resolvido: lendo uma fonte de mensagem bruta - encontrando a parte Base64 e decodificando um pequeno anexo de texto
Um arquivo de texto contendo principalmente ASCII permanece legível se você abrir a origem da mensagem bruta. Base64 ofusca tudo, até mesmo texto ASCII simples. Quoted-printable raramente é usado para arquivos binários (seria muito ineficiente para um PDF), mas às vezes é usado para texto. Um leitor de e-mail escolhe a codificação com base no tipo de anexo; um navegador geralmente não pergunta ao usuário qual codificação aplicar.
O corpo Base64 de uma mensagem de e-mail é apenas os próprios bytes, não um arquivo separado. Quando você vê um anexo em um leitor de e-mail, o leitor já decodificou o Base64 e está mostrando o arquivo original.
O custo do tamanho na prática – aproximadamente um terço a mais de bytes e por que os limites de tamanho de correspondência são declarados para o tamanho codificado
Se você visualizar a fonte da mensagem bruta (uma opção na maioria dos clientes de e-mail), verá os cabeçalhos MIME e o corpo codificado em Base64. A ferramenta codificador e decodificador Base64 pode ajudá-lo a decodificar manualmente um fragmento de uma fonte de mensagem; copie a peça Base64, remova as quebras de linha e cole-a na ferramenta.
Vários anexos em uma mensagem MIME usam um limite multipartes. Cada parte tem seus próprios cabeçalhos (Content-Type, Content-Transfer-Encoding) e corpo. Uma versão alternativa em texto simples da mensagem aparece como uma parte e cada anexo aparece como outra parte. A cadeia de limite separa as partes; foi escolhido para não aparecer no conteúdo de nenhuma parte. Um leitor de correio reconstrói a mensagem analisando os limites e decodificando cada parte de acordo com seu cabeçalho Content-Transfer-Encoding.
O que isso não cobre – cabeçalhos de palavras codificadas, S/MIME e a extensão 8BITMIME em profundidade
RFC 2045 a codificação base64 não é universal hoje. Alguns sistemas de correio suportam transporte 8 bits e não requerem mais base64. Alguns sistemas usam nomes de codificação diferentes ou adicionam cabeçalhos personalizados. Mas base64 com linhas de 76 caracteres continua sendo a escolha mais compatível para anexos que devem chegar a qualquer sistema de correio, em qualquer lugar. Quando você anexa um arquivo usando um cliente de email, o cliente geralmente escolhe base64 automaticamente para arquivos binários, lida com a quebra de linha e adiciona os cabeçalhos MIME.
Compreender o mecanismo ajuda a depurar quando um anexo parece corrompido ou quando você está trabalhando manualmente com uma origem de mensagem. Criar ou analisar uma mensagem de e-mail de saída requer a compreensão da estrutura MIME. Uma biblioteca deve lidar com a codificação, quebra de linha e cabeçalhos; você normalmente não constrói MIME manualmente. Mas se você estiver analisando uma fonte de mensagem bruta (depurando um problema de entrega ou extraindo anexos programaticamente), saber que Content-Transfer-Encoding: base64 significa que o corpo a seguir é 76-character-wrapped base64 permite que você aplique o decodificador correto.
Conclusão: Base64 é a camada de compatibilidade de e-mail - como o codificador e decodificador Base64 permite que você leia localmente uma pequena parte de texto de uma mensagem bruta
O próprio base64 é padrão RFC 4648; os cabeçalhos wrapper e MIME são específicos para e-mail. Os anexos de email são base64 porque o email foi criado para texto simples e base64 é a camada de compatibilidade mais simples e universal para enviar dados binários por meio de um protocolo somente texto. O limite de linha de 76 caracteres é um artefato histórico dos terminais e redes lentas da década de 1980, mas persiste como padrão de compatibilidade.
A compreensão desse histórico explica por que MIME existe, por que existem várias opções de codificação e por que base64 continua sendo o padrão para anexos, embora os sistemas de correio modernos possam suportar binários diretamente. O codificador e decodificador Base64 permite trabalhar manualmente com corpos MIME para verificar ou depurar a codificação.