base64가 필요한 이유 (이진 파일을 이메일로 보낼 수없는 이유는 무엇입니까)?


30

Base64 인코딩을 읽고 있었고 Wikipedia에서 이것을 발견했습니다.

Base64 인코딩 체계는 텍스트 데이터를 처리하도록 설계된 미디어를 통해 저장 및 전송해야하는 이진 데이터를 인코딩해야 할 때 일반적으로 사용됩니다.

... 그리고 주어진 예는 이메일을 통해 바이너리 파일을 보내는 것입니다.

base64가 필요한 이유를 이해하려고합니다. 이진 데이터는 많은 바이트이므로 텍스트 데이터 인 ASCII로 직접 변환 할 수 없습니까? 왜 base64가 필요한가요? 또는 이메일에 ASCII의 제어 문자에 문제가 있습니까?


"직접 번역 가능"이란 무슨 뜻입니까? 어떤 의미에서 base64는 "직접"이 아닌가?
David Schwartz

왜 그것이 직접적이라고 생각합니까?
Cookie Monster

4
직접적이라고 생각하는 것이 아니라, "직접 번역 가능"이 옥시 모론이라고 생각합니다. "직접"이 번역 프로세스를 포함 할 수 있다면 base64가 직접이 아닌 이유는 무엇입니까? 번역 과정 일뿐입니다.
David Schwartz

답변:


37

이것에 관한 좋은 Wikipedia 기사 가 있습니다.


ARPAnet에 의해 사용 된 NCP의 초기 반복은 바이트 스트림보다 비트 스트림과 유사하거나 편리한 바이트 크기를 협상하려는 시도입니다. 8 비트 바이트는 훨씬 나중에 표준화되었습니다. 다른 컴퓨터에서 작동하는 파일 전송 프로토콜을 만들려는 여러 시도가있었습니다 (메일은 기본적으로 MAILandMLFL 명령 으로 FTP 프로토콜의 기능을 수행 한 다음 나중에 SMTPMTP 로 분할 했습니다). 이 기계들은 종종 다른 문자 인코딩 (ASCII 대 EBCDIC) 또는 다른 바이트 크기 , 8 비트 바이트 대 6 비트 대 ...

따라서 메일 전송 기능은 초기에 비교적 짧은 메시지를 일반 텍스트로 전송하기 위해 정의되었습니다. 구체적으로, "NVT-ASCII". 예를 들어 RFC 772 는 다음과 같이 말합니다.

메일 표시 및 저장

메일은 발신 호스트의 저장 장치에서 수신 호스트의 저장 장치로 전송됩니다. 두 시스템의 데이터 스토리지 표현이 다르기 때문에 메일에서 특정 변환을 수행해야 할 수도 있습니다. 예를 들어, NVT-ASCII는 시스템마다 데이터 스토리지 표현이 다릅니다. PDP-10은 일반적으로 NVT-ASCII를 5 비트의 7 비트 ASCII 문자로 저장하며 36 비트 워드로 왼쪽 정렬됩니다. 360은 NVT-ASCII를 32 비트 워드에서 4 개의 8 비트 EBCDIC 코드로 저장합니다. Multics는 NVT-ASCII를 36 비트 워드에 4 개의 9 비트 문자로 저장합니다.

간단하게하기 위해 모든 데이터는 MTP에 NVT-ASCII로 표시되어야합니다. 즉, 송신 및 수신 호스트가 서로 다른지 여부에 관계없이 문자를 전송할 때 문자를 표준 NVT-ASCII 표현으로 변환해야합니다. 발신자는 데이터를 내부 문자 표현에서 표준 8 비트 NVT-ASCII 표현으로 변환합니다 (TELNET 사양 참조). 수신자는 데이터를 표준 형식에서 자체 내부 형식으로 변환합니다. 이 표준에 따라 텍스트 줄의 끝을 나타내는 순서를 사용해야합니다.

8 비트가 와이어를 통해 전송 되더라도 8 비트는 보존 할 필요가 없기 때문에 종종 폐기되거나 엉망이됩니다. 사실, 일부 프로토콜이 필요 같은 초기로, 0으로 설정하는 8 비트를 SMTP의 RFC 아래에 인용한다. 다시 말해 소프트웨어는 8 비트 가 아니 었습니다 .

데이터 전송

TCP 연결은 8 비트 바이트 전송을 지원합니다. SMTP 데이터는 7 비트 ASCII 문자입니다. 각 문자는 8 비트 바이트로 전송되며 상위 비트는 0으로 지워집니다.

이것은 8 비트 ISO-8859- # 문자 인코딩이 널리 보급 된 후에도 오랫동안 지속되었습니다. 일부 서버는 이미 8 비트가 깨끗했지만 다른 서버는 그렇지 않았으며 8 비트 데이터를 맹목적으로 보내면 메시지가 엉망이되었습니다.

나중에 "확장 SMTP" 가 게시되어 메일 서버가 지원하는 SMTP 확장을 선언 할 수 있습니다. 그 중 하나는 8BITMIME수신 서버가 8 비트 데이터를 안전하게 수락 할 수 있음을 나타냅니다. MIME 메시지 부분에는 " Content-Transfer-Encoding : 8bit"가있을 수 있으며 어떤 방식으로도 인코딩되지 않았 음을 나타냅니다.

그러나 SMTP 프로토콜은 회선 기반으로 유지 .되며 "메시지 끝"표시기로 회선 (0D 0A 2E 0D 0A)을 사용할뿐만 아니라 998 옥텟 라인 제한이 있습니다. 즉, 대부분의 이진 파일은 변경없이 전송 될 수 있지만이 8 진수 시퀀스를 포함하는 파일은 전송 된 메시지의 끝으로 해석되고 나머지 파일은 SMTP 명령으로 해석되어 손상을 일으킬 수 있습니다. 마찬가지로, 수신 서버에서 998 옥텟보다 긴 "라인"이 잘릴 수 있습니다.

2000 년에는 "BINARYMIME"ESMTP 확장RFC 3030 으로 게시되어 SMTP를 통해 원시 이진 데이터를 전송할 수 있습니다. 메시지는 이제 길이가 0 인 청크를 터미네이터로 사용하여 미리 지정된 길이의 청크로 전송되며 Base64 및 이와 유사한 인코딩은 더 이상 필요하지 않습니다. 불행하게도이 확장을 지원하는 SMTP 서버는 거의 없습니다. 예를 들어 Postfix 나 Exim4 CHUNKING는 EHLO에 대한 응답으로 광고하지 않습니다 . BINARYMIME을 이용하려면 메시지 경로의 모든 서버에서 지원해야하는데 이는 하나 또는 두 개 이상일 수 있습니다.

참조 :


1
조직 내의 Exchange 서버는 BDAT 명령을 사용하여 전자 메일을 이진으로 보내지 만 조직 외부의 SMTP 서버에 대해서는이 작업을 수행하지 않습니다.
james.garriss 18.43에

7

일부 오래된 전자 메일 시스템 및 소프트웨어는 8 비트 가 아니 었으며 8 비트는 제어 문자로 사용되었습니다. 이진 파일을 정리하기에 충분했기 때문에 Base64 (또는 다른 인코딩 체계)가 필요했습니다.


90 년대의 일부 레거시 이메일 시스템이 메시지를 올바르게 이해하지 못할 수 있기 때문에 모든 바이트에 2 비트를 낭비하고 있습니다. Gmail 시대의 이러한 레거시 시스템은 1 % 미만일 수 있습니다. 소수의 사람들에게 왜 그렇게 많은 대역폭을 낭비하고 있는지 생각하고 있습니까? Base64는 메일로만 제한됩니까?
vaibhav.g
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.