이메일 콘텐츠를 보내는 동안 "Content Transfer Encoding"헤더를 설정해야합니다. 내가받은 이메일 헤더를 많이 봤습니다. 일부 이메일은 "7bit"를 사용하고 일부는 "8bit"를 사용합니다.
이 둘의 차이점은 무엇입니까? 어느 것이 권장됩니까? 이러한 헤더를 설정하기 위해 이메일 본문에 필요한 특수 인코딩이 있습니까?
이메일 콘텐츠를 보내는 동안 "Content Transfer Encoding"헤더를 설정해야합니다. 내가받은 이메일 헤더를 많이 봤습니다. 일부 이메일은 "7bit"를 사용하고 일부는 "8bit"를 사용합니다.
이 둘의 차이점은 무엇입니까? 어느 것이 권장됩니까? 이러한 헤더를 설정하기 위해 이메일 본문에 필요한 특수 인코딩이 있습니까?
답변:
읽기에는 약간 조밀 할 수 있지만 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헤더 값은 이 문제를 해결하기 위해 선택한 규칙을 설명합니다.
7bit단순히 "내 데이터는 US-ASCII 문자로만 구성되며 각 문자에 대해 하위 7 비트 만 사용합니다."라는 의미입니다. 기본적으로 콘텐츠의 모든 바이트가 이미 SMTP의 제한 사항을 준수하고 있으므로 특별한 처리가 필요하지 않습니다. 그대로 읽을 수 있습니다.
을 선택 7bit하면 콘텐츠의 모든 줄 길이가 1000 자 미만이라는 데 동의하는 것입니다.
콘텐츠가 이러한 규칙을 준수하는 한은 ( 7bit는) 최상의 전송 인코딩입니다. 추가 작업이 필요하지 않기 때문입니다. 파이프에서 나오는 바이트를 읽고 / 씁니다. 또한 7bit콘텐츠 를 눈으로 확인하고 이해 하기 쉽습니다 . 여기서 아이디어는 "일반 영어 텍스트"로만 작성하면 괜찮을 것입니다. 그러나 그것은 2005 년에 사실이 아니었고 오늘날에도 사실이 아닙니다.
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 절에 정의) 인코딩은이 문제를 처리 할 수 있도록 설계되어있다. 두 가지 작업을 수행합니다.
이스케이프와 짧은 줄로 인해 Quoted Printable은 7bit또는 보다 사람이 읽기가 훨씬 어렵지만 8bit훨씬 더 광범위한 가능한 콘텐츠를 지원합니다.
데이터가 텍스트가 아닌 경우 (예 : 이미지 파일) 옵션이 많지 않습니다. 7bit테이블에서 떨어져 있습니다. 8bit그리고 binary는 MIME 확장 RFC는 이전에 지원되지 않는했다. quoted-printable작동하지만 실제로 비효율적입니다 (모든 바이트는 3 문자로 표시됩니다).
base64이러한 유형의 데이터에 대한 좋은 솔루션입니다. 3 개의 원시 바이트를 4 개의 US-ASCII 문자로 인코딩하므로 상대적으로 효율적입니다. RFC 1341 base64은 SMTP 메시지에 맞게 인코딩 된 데이터 의 줄 길이 를 76 자로 제한 하지만 고정 된 길이로 임의의 문자를 분할하거나 연결하는 경우 비교적 쉽게 관리 할 수 있습니다.
큰 단점은 base64인코딩 된 데이터가 그 아래에있는 "일반"텍스트 일지라도 사람이 거의 읽을 수 없다는 것입니다.