개발자 도구 · Base64 인코더 및 디코더
이메일 첨부 파일이 Base64인 이유: MIME, 7비트 전송 및 76-열 라인
· 배경
베이스64 인코딩
이메일은 7비트 ASCII 텍스트로 작성되었으며 첨부 파일은 이를 통과해야 했습니다. 이 게시물에서는 MIME이 Base64를 채택한 방법, 줄이 76 문자로 래핑되는 이유, 크기 및 디버깅에 대한 의미를 추적합니다.
오래된 릴레이를 통해 손상된 첨부 파일이 도착했습니다. MIME이 해결하기 위해 고안한 8비트 문제
이메일은 1970년대와 1980년대에 7비트 ASCII 텍스트 전용으로 설계되었습니다. 이메일을 전달하는 프로토콜인 SMTP는 각 줄이 최대 998 문자의 7비트 ASCII(문자 0-127 문자)일 것으로 예상합니다. PDF와 같은 바이너리 파일이나 SMTP를 통해 직접 이미지를 보내는 것은 실패합니다. 바이트 128-255은 이전 메일 서버 및 릴레이에 의해 손상되거나 거부됩니다. 첨부 파일에는 인코딩이 필요합니다. MIME(다용도 인터넷 메일 확장, RFC 2045)은 모든 바이트 시퀀스를 7비트 ASCII 텍스트로 나타내는 base64를 포함한 Content-Transfer-Encoding 헤더 값을 정의하여 이 문제를 해결했습니다.
MIME은 7비트(인코딩 없음, 안전한 ASCII에만 해당), 8비트(범용이 아닌 8비트 바이트를 지원하는 서버용), quoted-printable(안전하지 않은 바이트만 인코딩하고 ASCII 읽기 가능 유지), base64(모든 것을 인코딩하여 호환성 최대화) 등 여러 가지 콘텐츠 전송 인코딩 옵션을 제공합니다. Base64는 단순하고 표준화되어 있으며 오래되었거나 엄격하게 7비트만 사용하더라도 모든 메일 시스템에서 안전을 보장하기 때문에 바이너리 첨부 파일로 선택되었습니다. 단점은 크기입니다. Base64는 원래 바이트보다 약 1/3 더 큽니다.
Base64가 해결하는 전송 문제 — 인쇄 가능한 문자로 임의의 바이트 표현
3 KB PDF은 대략 Base64 텍스트의 4 KB가 됩니다. 76 문자 줄 제한은 RFC 2045에서 비롯됩니다.
SMTP는 최대 998 자까지 줄을 허용하지만 이전 메일 시스템과 일부 스팸 필터는 긴 줄을 거부합니다. RFC 2045은 MIME Base64 줄이 76 문자(CRLF 줄 끝 포함)를 초과하지 않아야 메일 서버가 전송을 중단하지 않도록 지정합니다. 한계는 마술적이지 않습니다. 이는 가독성(76 문자는 대부분의 1980년대 터미널에 적합), 이전 시스템과의 호환성, 스팸 또는 바이러스 패턴으로 감지되지 않는 것 사이의 역사적 절충안입니다.
이 도구에 표시되는 출력 선택 항목 — 표준 패딩 및 선택적 76 문자 래핑
최신 메일 시스템은 일반적으로 더 긴 줄을 지원하지만 76 문자 줄로 인코딩하면 첨부 파일이 가장 오래된 수신자에게도 전달됩니다. RFC 2045이 MIME Base64를 정의한 후 RFC 4288(미디어 유형) 및 RFC 2183(콘텐츠 처리)은 첨부 파일에 레이블을 지정하는 표준화된 방법을 추가했습니다. PDF 첨부 파일이 있는 메시지에는 Content-Transfer-Encoding: base64 헤더, Content-Type: application/pdf 헤더, 76 문자 줄이 있는 Base64로 인코딩된 PDF 바이트가 포함됩니다. 메일 리더는 줄 바꿈(CRLF 문자)을 제거한 다음 Base64를 디코딩하여 원래 바이트를 복구함으로써 줄을 디코딩합니다.
MIME Base64 첨부 파일을 디코딩하려면 공백을 무시해야 합니다. RFC에 따르면 디코더는 디코딩 중에 줄바꿈(CR 및 LF 문자)을 건너뛰어야 합니다. 이것이 공백을 허용하는 Base64 디코더가 실용적인 이유입니다. 대부분의 실제 MIME 메일에는 줄 바꿈이 있습니다. 일부 디코더는 엄격하고 공백을 거부하는 반면(줄 바꿈이 없어야 하는 JWT과 같은 컨텍스트에 적합), 다른 디코더는 관대하고 공백을 건너뜁니다(MIME에 적합).
실제로 76 문자 옵션 — 인코더가 줄 바꿈을 삽입하고 디코더가 줄 바꿈을 무시하는 방법
Base64 인코더 및 디코더 도구는 두 가지를 모두 처리할 수 있습니다. 여러 줄로 붙여넣은 첨부 파일을 허용하고 디코딩 중에 줄 바꿈을 무시합니다. 크기에 미치는 영향은 예측 가능합니다. RFC 2045 base64 래핑은 출력의 76 문자당 하나의 CRLF(2 바이트)를 추가합니다. 10 KB 파일의 경우 Base64는 대략 13.3 KB에 76 문자마다 CRLF를 추가하여 총 약 13.5 KB입니다. 오버헤드는 대략 1/3 정도 더 많은 바이트입니다.
이메일 크기 제한은 일반적으로 원본 파일 크기가 아닌 인코딩된 크기에 대해 명시됩니다. 25 MB 제한이 있는 메일 서버는 첨부 파일의 25 MB가 아니라 인코딩된 메시지의 25 MB을 의미합니다. 원본 파일 크기를 계산하려면 1.33(더 정확하게는 4를 3로 나눈 값)으로 나누어야 합니다. 인용 인쇄 가능 인코딩은 인쇄 가능한 ASCII를 변경하지 않고 128-255 바이트와 몇 가지 특수 문자만 인코딩하는 대안입니다.
작업 예: 원시 메시지 소스 읽기 — Base64 부분 찾기 및 작은 텍스트 첨부 파일 디코딩
원시 메시지 소스를 열면 대부분 ASCII로 구성된 텍스트 파일을 읽을 수 있습니다. Base64는 일반 ASCII 텍스트까지 포함하여 모든 것을 난독화합니다. Quoted-printable은 바이너리 파일에는 거의 사용되지 않지만(PDF의 경우 매우 비효율적임) 텍스트에는 가끔 사용됩니다. 메일 리더는 첨부 파일 유형에 따라 인코딩을 선택합니다. 브라우저는 일반적으로 사용자에게 어떤 인코딩을 적용할지 묻지 않습니다.
이메일 메시지의 Base64 본문은 별도의 파일이 아니라 바이트 자체입니다. 메일 리더에 첨부 파일이 표시되면 리더는 이미 Base64를 디코딩했으며 원본 파일을 표시하고 있는 것입니다.
실제 크기 비용 - 대략 1/3 바이트가 더 많고 인코딩된 크기에 대해 메일 크기 제한이 명시된 이유
원시 메시지 소스(대부분의 메일 클라이언트의 옵션)를 보면 MIME 헤더와 Base64로 인코딩된 본문이 표시됩니다. Base64 인코더 및 디코더 도구를 사용하면 메시지 소스의 일부를 수동으로 디코딩할 수 있습니다. Base64 부분을 복사하고 줄 바꿈을 제거한 후 도구에 붙여넣습니다.
MIME 메시지의 여러 첨부 파일은 다중 부분 경계를 사용합니다. 각 부분에는 자체 헤더(Content-Type, Content-Transfer-Encoding)와 본문이 있습니다. 메시지의 일반 텍스트 대체 버전은 한 부분으로 나타나고 각 첨부 파일은 다른 부분으로 나타납니다. 경계 문자열은 부품을 분리합니다. 어떤 부분의 콘텐츠에도 나타나지 않도록 선택되었습니다. 메일 리더는 경계를 구문 분석하고 Content-Transfer-Encoding 헤더에 따라 각 부분을 디코딩하여 메시지를 재구성합니다.
여기서 다루지 않는 내용 — 인코딩된 단어 헤더, S/MIME 및 8BITMIME 확장 심층
RFC 2045 base64 인코딩은 오늘날 보편적이지 않습니다. 일부 메일 시스템은 8비트 전송을 지원하며 더 이상 base64가 필요하지 않습니다. 일부 시스템에서는 다른 인코딩 이름을 사용하거나 사용자 정의 헤더를 추가합니다. 그러나 76 문자 줄이 있는 base64는 어디에서나 모든 메일 시스템에 도달해야 하는 첨부 파일에 대해 가장 호환되는 선택으로 남아 있습니다. 메일 클라이언트를 사용하여 파일을 첨부할 때 클라이언트는 일반적으로 바이너리 파일에 대해 자동으로 base64를 선택하고 줄 바꿈을 처리하며 MIME 헤더를 추가합니다.
메커니즘을 이해하면 첨부 파일이 손상된 것처럼 보이거나 메시지 소스를 수동으로 작업할 때 디버깅하는 데 도움이 됩니다. 보내는 이메일 메시지를 작성하거나 구문 분석하려면 MIME 구조를 이해해야 합니다. 라이브러리는 인코딩, 줄 바꿈 및 헤더를 처리해야 합니다. 일반적으로 MIME을 수동으로 구성하지 않습니다. 그러나 원시 메시지 소스를 구문 분석하는 경우(전송 문제 디버깅 또는 프로그래밍 방식으로 첨부 파일 추출) Content-Transfer-Encoding: base64는 다음 본문이 76 문자 래핑된 base64임을 의미하므로 올바른 디코더를 적용할 수 있습니다.
요약: Base64는 이메일의 호환성 레이어입니다. Base64 인코더 및 디코더를 사용하여 원시 메시지의 작은 텍스트 부분을 로컬에서 읽을 수 있는 방법
base64 자체는 표준 RFC 4648입니다. 래핑 및 MIME 헤더는 이메일에만 적용됩니다. 이메일 첨부 파일은 base64입니다. 왜냐하면 이메일은 일반 텍스트용으로 만들어졌고 base64는 텍스트 전용 프로토콜을 통해 바이너리 데이터를 보내는 가장 간단하고 보편적인 호환성 레이어이기 때문입니다. 76 문자 줄 제한은 1980년대 터미널과 느린 네트워크의 역사적인 인공물이지만 호환성을 위한 표준으로 지속됩니다.
이 기록을 이해하면 MIME이 존재하는 이유, 여러 인코딩 옵션이 있는 이유, 최신 메일 시스템이 바이너리를 직접 지원할 수 있음에도 불구하고 base64가 첨부 파일의 기본값으로 남아 있는 이유가 설명됩니다. Base64 인코더 및 디코더를 사용하면 MIME 본문을 수동으로 사용하여 인코딩을 확인하거나 디버그할 수 있습니다.