읽기에는 약간 조밀 할 수 있지만 RFC 1341의 “Content-Transfer-Encoding”섹션에는 모든 세부 정보가 있습니다.

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

상황은 좀 나 빠졌다. 내 요약은 다음과 같습니다.

배경

정의에 따라 SMTP (RFC 821)는 메일을 각각 7 비트의 1000 자 줄로 제한합니다. 즉, 파이프로 보내는 바이트는 “1”로 설정된 최상위 ( “최상위 순서”) 비트를 가질 수 없습니다.

보내려는 콘텐츠는 본질적으로이 제한을 따르지 않는 경우가 많습니다. 이미지 파일 또는 유니 코드 문자가 포함 된 텍스트 파일을 생각해보십시오. 이러한 파일의 바이트는 종종 8 번째 비트가 “1”로 설정됩니다. SMTP에서는이를 허용하지 않으므로 “인코딩 전송”을 사용하여 불일치를 해결하는 방법을 설명해야합니다.

Content-Transfer-Encoding헤더 값은 이 문제를 해결하기 위해 선택한 규칙을 설명합니다.

7 비트 인코딩

7bit단순히 “내 데이터는 US-ASCII 문자로만 구성되며 각 문자에 대해 하위 7 비트 만 사용합니다.”라는 의미입니다. 기본적으로 콘텐츠의 모든 바이트가 이미 SMTP의 제한 사항을 준수하고 있으므로 특별한 처리가 필요하지 않습니다. 그대로 읽을 수 있습니다.

을 선택 7bit하면 콘텐츠의 모든 줄 길이가 1000 자 미만이라는 데 동의하는 것입니다.

콘텐츠가 이러한 규칙을 준수하는 한은 ( 7bit는) 최상의 전송 인코딩입니다. 추가 작업이 필요하지 않기 때문입니다. 파이프에서 나오는 바이트를 읽고 / 씁니다. 또한 7bit콘텐츠 를 눈으로 확인하고 이해 하기 쉽습니다 . 여기서 아이디어는 “일반 영어 텍스트”로만 작성하면 괜찮을 것입니다. 그러나 그것은 2005 년에 사실이 아니었고 오늘날에도 사실이 아닙니다.

8 비트 인코딩

8bit“내 데이터에 확장 ASCII 문자가 포함될 수 있습니다. 표준 US-ASCII 7 비트 문자 이외의 특수 문자를 나타 내기 위해 8 번째 (가장 높은) 비트를 사용할 수 있습니다.” 와 마찬가지로 7bit1000 자 줄 제한이 있습니다.

8bit와 마찬가지로 7bit는 와이어에서 쓰거나 읽을 때 실제로 바이트를 변환하지 않습니다. 그것은 단지 어떤 바이트도 “1”로 설정된 가장 높은 비트를 가지지 않을 것이라는 것을 보장하지 않는다는 것을 의미합니다.

7bit콘텐츠에서 더 많은 자유를 제공하므로 에서 한 단계 올라간 것처럼 보입니다 . 그러나 RFC 1341에는 다음 정보가 포함되어 있습니다.

이 문서의 발행 시점에는 메일 본문에 인코딩되지 않은 8 비트 또는 이진 데이터를 포함하는 것이 합법적 인 표준화 된 인터넷 전송이 없습니다. 따라서 “8 비트”또는 “바이너리”Content-Transfer-Encoding이 실제로 인터넷에서 합법적 인 상황은 없습니다.

RFC 1341은 20 년 전에 나왔습니다. 그 이후로 우리는 RFC 6152 에서 8 비트 MIME 확장 을 얻었습니다 . 그러나 그럼에도 불구하고 라인 제한은 여전히 ​​적용될 수 있습니다.

이 확장은 줄 길이를 제한하는 SMTP 서버의 가능성을 제거하지 않습니다. 서버는이 확장을 자유롭게 구현할 수 있지만 그럼에도 불구하고 1000 옥텟보다 낮은 라인 길이 제한을 설정합니다.

바이너리 인코딩

binary8bit줄 길이 제한이 없다는 점을 제외 하면과 동일 합니다. 원하는 모든 문자를 계속 포함 할 수 있으며 추가 인코딩이 없습니다. 와 유사하게 8bitRFC 1341은 실제로 합법적 인 인코딩 전송 인코딩이 아니라고 말합니다. RFC 3030 은이를 BINARYMIME.

인용 인쇄 가능

8BITMIME확장 이전에는 7bitSMTP를 통해 있을 수없는 콘텐츠를 보내는 방법이 필요했습니다 . HTML 파일 (1000 자 이상의 행이있을 수 있음) 및 국제 문자가있는 파일이 이에 대한 좋은 예입니다. quoted-printable(RFC 1341의 5.1 절에 정의) 인코딩은이 문제를 처리 할 수 있도록 설계되어있다. 두 가지 작업을 수행합니다.

• US-ASCII가 아닌 문자를 7 비트 문자로만 표현할 수 있도록 이스케이프하는 방법을 정의합니다. (짧은 버전 : 등호와 2 개의 7 비트 문자로 표시됩니다.)
• 줄이 76 자 이하이고 줄 바꿈이 특수 문자 (이스케이프 처리됨)를 사용하여 표시되도록 정의합니다.

이스케이프와 짧은 줄로 인해 Quoted Printable은 7bit또는 보다 사람이 읽기가 훨씬 어렵지만 8bit훨씬 더 광범위한 가능한 콘텐츠를 지원합니다.

Base64 인코딩

데이터가 텍스트가 아닌 경우 (예 : 이미지 파일) 옵션이 많지 않습니다. 7bit테이블에서 떨어져 있습니다. 8bit그리고 binary는 MIME 확장 RFC는 이전에 지원되지 않는했다. quoted-printable작동하지만 실제로 비효율적입니다 (모든 바이트는 3 문자로 표시됩니다).

base64이러한 유형의 데이터에 대한 좋은 솔루션입니다. 3 개의 원시 바이트를 4 개의 US-ASCII 문자로 인코딩하므로 상대적으로 효율적입니다. RFC 1341 base64은 SMTP 메시지에 맞게 인코딩 된 데이터 의 줄 길이 를 76 자로 제한 하지만 고정 된 길이로 임의의 문자를 분할하거나 연결하는 경우 비교적 쉽게 관리 할 수 ​​있습니다.

큰 단점은 base64인코딩 된 데이터가 그 아래에있는 “일반”텍스트 일지라도 사람이 거의 읽을 수 없다는 것입니다.