이메일에 데이터를 첨부 할 때 Thunderbird가 첨부 파일보다 훨씬 큰 결과 이메일의 전체 크기를 계산하는 것을 알았습니다.

최근 예는 다음과 같습니다. 두 개의 이미지 (13MB 및 3.6MB)는 총 약 17MB 여야합니다. 네 줄의 텍스트가있었습니다. 그런 다음 Thunderbird에서 총 22MB 크기의 이메일을 정말로 보내고 싶은지 물었습니다.

그 차이는 어디에서 오는가? 5MB의 텍스트가 약간 비슷합니다.

귀하의 데이터는 17 MiB입니다. MiB에는 1024 KiB가 있습니다. KiB에는 1024B가 있습니다. 바이트에는 8 비트가 있습니다. 142,606,336 비트입니다.

Base 64 인코딩은 6 비트마다 별도의 바이트로 인코딩합니다. 따라서 약 23,767,722 바이트가 필요합니다. 1024로 두 번 나누면 22.67 MiB가됩니다. 이것이 22 MiB가 시작된 곳입니다.

이메일은 꽤 오래된 기술이며 8 비트 클린 파이프를 가정하지 않습니다.

이메일이 더 큰 이유는 무엇입니까?

base64최대 3 바이트 그룹을 4 개의 인쇄 가능한 ASCII 문자 그룹으로 인코딩하는 데이터가 인코딩되기 때문 입니다. 일반적으로 이러한 인쇄 가능한 문자 그룹은 줄로 나뉩니다.

결과적으로 인코딩 된 데이터가 원본 데이터 크기의 1 배 이상입니다.

왜 base64가 사용됩니까?

이메일은 오랜 역사를 가지고 있으며 원래 텍스트를 전달하도록 설계되었습니다. ASCII 인쇄 가능한 문자를 나타내는 바이트 값만 지구상의 다양한 전자 메일 시스템을 안정적으로 통과 할 수 있습니다.

따라서 MIME은 다른 데이터를 ASCII 텍스트로 인코딩하기위한 두 가지 체계, 즉 다른 비트가 거의없는 ASCII 텍스트 용으로 디자인 된 "quoted-printable"과 임의의 이진 데이터 용 "BASE64"로 나 di습니다.

이러한 제한을 시도하고 제거하기 위해 SMTP 프로토콜에 대한 확장이있었습니다. 첫째, 1994 년 8BITMIME은 더 높은 옥텟 값을 허용하지만 불행히도 줄 길이 및 줄 끝과 관련된 한계를 제거하지 않았으므로 임의의 이진 데이터에는 적합하지 않았습니다. 1995 년의 BINARYMIME은 임의의 이진 데이터를 포함하는 메시지의 전송을 허용했습니다.

그러나 이러한 표준은 널리 채택되지 않았습니다. 한 가지 문제는 메일 체인의 한 홉이 지원하지만 다음 홉은 지원하지 않으면 어떻게됩니까? 그런 다음 메일 서버는 그대로 메일을 보낼 수 없으며, 전달할 수없는 것으로 거부하고 반송 (사용자가 받아 들일 수 없을 것임)하거나 메일 서버에 상당한 추가 코드가 필요한 메일을 반송해야합니다. . 멀티 파트 형식에서 콘텐츠 전송 인코딩을 사용하지 않는 것과 관련된 MIME 규칙에 따라 변환이 특히 어려워집니다.