Por que o tamanho do meu email é cerca de um terço maior que o tamanho dos arquivos anexados?

111

Ao anexar dados aos meus emails, notei que o Thunderbird calcula o tamanho total do email resultante como muito maior do que os arquivos anexados.

Aqui está um exemplo recente: duas imagens, uma com 13 MB e outra com 3,6 MB, devem totalizar aproximadamente 17 MB. Havia quatro linhas de texto. O Thunderbird me perguntou se eu realmente queria enviar um email com um tamanho total de 22 MB.

De onde vem essa diferença? 5 MB de texto parece um pouco demais.

email thunderbird base64

— arc_lupus
fonte

Observe que isso geralmente afeta coisas como tamanho máximo. Se não me engano, o e-mail do Google geralmente permite e-mails com no máximo 25 MB, mas os 25 MB são calculados após a codificação; portanto, você não pode enviar uma imagem de 25 MB com um e-mail, porque, quando codificado, na verdade seria muito grande.

— Bakuriu 27/10/16

O comentário do @ Bakuriu também se aplica ao servidor Outlook + Exchange. Sugiro que a pergunta subjacente seja realmente: por que os clientes de email (geralmente - o Tbird parece melhor do que o outlook novamente) relatam apenas o tamanho do arquivo local quando é o tamanho codificado em base64 que importa?

— Chris H

@MarcksThomas Não quero argumentar contra o apelo de ter uma fonte de conhecimento abrangente, facilmente pesquisável, contra apenas ter todo o conhecimento facilmente pesquisável. Mas isso é necessário? Acho que não. - Não acho que a pergunta não seja útil, apenas acho que ela não atende aos requisitos básicos para manter o site livre de perguntas desnecessárias e torna mais difícil encontrar as coisas realmente importantes, que não são respondeu em qualquer outro lugar. É o que deveríamos estar fazendo! - arc_lupus, como eu apenas espreito neste site, geralmente, meu voto negativo ainda não é bom. Mas como é, está.

— Alexander Kosubek

Relacionado a: superuser.com/questions/568506/…

— glenneroo

Respostas:

214

Seus dados eram 17 MiB. Existem 1024 KiB em um MiB. Existem 1024 B em um KiB. Existem 8 bits em um byte. Então são 142.606.336 bits.

A codificação Base 64 codifica a cada seis bits como um byte separado. Então, precisamos de cerca de 23.767.722 bytes. Dividindo por 1024 duas vezes, obtemos 22,67 MiB. Então é daí que o MiB 22 vem.

O email é uma tecnologia bastante antiga e não assume um cachimbo limpo de 8 bits.

— David Schwartz
fonte

Para decodificar um pouco a última linha: base-64 é uma maneira de codificar anexos como texto usando um conjunto limitado de "caracteres seguros garantidos" que não seriam distorcidos por algum equipamento intermediário, como az, AZ, 0-9

— Yorik 26/10/16

E, depois de entender a matemática na excelente resposta de David, basta multiplicar o tamanho dos anexos por 3/3 para obter o tamanho da mensagem de email que será enviada (mais o texto real).

— Kent

Mesmo se o e-mail soubesse que ele possui um canal completo de 8 bits, teria que ser codificado, pois é fundamentalmente um fluxo de texto - alguns caracteres desempenham funções de controle e, portanto, não devem ocorrer nos seus dados. Dito isto, existem melhores técnicas de codificação, mas elas não foram adotadas.

— Loren Pechtel 27/10/16

@LorenPechtel, você pode ter uma parte de aplicativo / fluxo de octetos em uma mensagem MIME. Tudo o que você precisa fazer é escolher um limite que não ocorra nos dados.

— OrangeDog

o que o base64 realmente faz é usar 4 bytes para cada 3 bytes originais. Embora isso pareça semelhante, é importante porque o comprimento é sempre um múltiplo de 4 e também porque não há razão para o nível de bits.

— Njzk2 27/10/16

Por que o email é maior?

Como os dados são codificados, base64codificam grupos de até três bytes como grupos de quatro caracteres ASCII imprimíveis. Normalmente, esses grupos de caracteres imprimíveis são divididos em linhas.

O resultado é que os dados codificados têm um pouco mais de 1/4 do tamanho dos dados originais.

Por que o base64 é usado?

O email tem uma longa história e foi originalmente projetado para transportar texto. Somente valores de bytes que representam caracteres imprimíveis ASCII poderiam passar de maneira confiável pela grande variedade de sistemas de email do planeta.

Assim, o MIME dividiu dois esquemas para codificar outros dados como texto ASCII - "imprimível entre aspas", projetado principalmente para texto ASCII com alguns outros bits, e "BASE64" para dados binários arbitrários.

Houve extensões no protocolo SMTP para tentar remover essas restrições. Primeiro, o 8BITMIME em 1994, que permitiu valores mais altos de octetos, mas infelizmente não removeu limites relacionados a comprimentos e terminações de linhas, portanto não era adequado para dados binários arbitrários; e depois BINARYMIME em 1995, que permitiu a transferência de mensagens contendo dados binários arbitrários.

No entanto, esses padrões não foram adotados amplamente. Um problema é: o que acontece se um salto na cadeia de correio os suporta, mas o próximo salto não? O servidor de correio não pode enviar o correio no estado em que se encontra, deve rejeitá-lo como não entregue e devolvê-lo (o que é improvável que seja aceitável para os usuários) ou convertê-lo (o que requer um código extra significativo no servidor de correio) . A conversão é especialmente dolorosa pelas regras MIME relacionadas ao não uso de codificações de transferência de conteúdo em tipos de várias partes.

— plugwash
fonte

Eu me pergunto por que o yEnc, por outro lado, teve bastante sucesso na Usenet ao substituir a UUE. Possivelmente porque os grupos de notícias binários pressionam muito mais os ISPs do que um e-mail binário ocasional?

— Igorsk # 30/16

@igorsk: plus Usenet / NN foi apresentado e entendido como com perda, onde você poderia publicar um artigo e nem todos os assinantes em todos os servidores necessariamente o receberiam. Havia (e ainda permanece) costumes sobre a citação em um acompanhamento 'suficiente' do (s) artigo (s) anterior (is), para que seu acompanhamento possa ser entendido por alguém que não obteve o (s) artigo (s) anterior (is) . Por outro lado, a maioria dos remetentes de email (não spammer) esperava que o "sistema" recebesse sua mensagem para os destinatários nomeados, embora algumas vezes depois de horas ou dias; hoje as pessoas reclamam até de pequenos atrasos.

— David_thompson_085