[메일] “Multipart” Content-Type

출처: http://blog.naver.com/skimms/10051107325

★ “Multipart” Content-Type

 

Content-Type 중 하나로, 서브 타입으로 mixed, alternative, digest, related 를 갖는다.

여러 개의 독립된 섹션으로 구성된 데이터를 하나의 메시지로 조합하여 전송한다.

 

메시지는 헤더와 본문으로 구성되고, 이것은 NULL 라인으로 구분한다.

본문은 라인의 집합으로 평면적 구성이므로, 여러 부분(multi part)으로 나누려면 각 부분의 경계를 표시해야 하며, 이것이 Multipart Content-Type의 기본 파라미터가 된다. 이 파라미터를 boundary라 한다.

 

 

* 기본 구조

 

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

 

 

* boundary

boundary로 쓰일 수 있는 문자는 ASCII 문자 중에서 일부에 속한다.

Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08j34c0p

이것은 콜론이 들어가 있으므로 올바른 boundary 구성이라고 볼 수 없다. ( 콜론은 헤더 필드 이름과 필드 본문을 구분하기 위해서 사용되는 문자이다.)

다음처럼 따옴표로 묶어 사용하면 적법하다.

Content-Type: multipart/mixed; "boundary=gc0p4Jq0M:2Yt08j34c0p"

 

 

* Multipart로 구성된 메시지의 예제

 

From: Nathaniel Borenstein To: Ned Freed Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" This is the preamble. It is to be ignored, though it is a handy place for composition agents to include an explanatory note to non-MIME conformant readers. --simple boundary                                           --------------- ① This is implicitly typed plain US-ASCII text. It does NOT end with a linebreak. --simple boundary Content-type: text/plain; charset=us-ascii This is explicitly typed plain US-ASCII text. It DOES end with a linebreak. --simple boundary--                                         --------------- ② This is the epilogue. It is also to be ignored.

 

 

① --simple boundary       : 메시지 부분 간의 실제 경계로 사용한다.

② --simple boundary--    : multipart의 끝을 의미한다.

 

Content-type이 multipart로 선언되면 첫번째 경계가 나타나기 전까지의 메시지는 ‘반드시’ 무시해야 한다.

경계가 나타나면 다음 경계 전까지의 부분을 하나의 본문 파트로 처리한다.

그리고 multipart의 끝을 의미하는 바운더리가 나타나면 multipart 메시지가 끝난 것으로 처리한다.

이후의 모든 문자 또한 ‘반드시’ 무시해야 한다.

 

 

* multipart 타입의 서브 타입

 

서브 타입	설 명
mixed	mulitpart 타입의 기본 서브타입. (알 수 없는 mulitpart 서브 타입은 mulitpart/mixed로 처리한다.) 각 부분의 기본 컨텐트 타입은 ‘text/plain’이다.   각 부분은 연관관계가 없으며, 각 부분의 순서만 약간 의미가 있다. 꼭 하나의 (특히 첫번째) 본문 부분이 inline 메시지이고, 나머지는 attachment라는 보장은 없다. 또한, 각 본문 부분도 mulitpart로 구성될 수 있다. (이론적으로 무한대의 중첩이 가능.) 대부분은 세 단계의 mulitpart가 구성된다.
alternative	형식상은 mulitpart/mixed와 동일하나, 이 타입은 같은 내용에 대한 서로 다른 버전을 담고 있다.   이 메시지를 처리하는 쪽, 즉 MUA에서는 자신의 환경에 맞는 가장 좋은 버전 하나만 선택하면 된다. 보통은 가장 훌륭한 버전을 맨 뒤에 놓는다.
digest	기본 문법은 mulitpart/mixed와 동일하나, mulitpart/mixed 타입에서 각 부분의 기본 컨텐트 타입이 ‘text/plain’인 것과는 달리 이 타입은 기본 컨텐트 타입이 ‘message/rfc822’이다.   cf. message/rfc822 : 헤더를 포함한 메시지 자체를 나타낸다. 즉, 메일 메시지를 캡슐화하고 있는 것이라고 보면 된다. 보통 되돌아온 메일에 attach로 달려있는 원래 메시지가 이 타입을 가진다.
parallel	mulitpart/mixed 타입과 다른 점은, 각 본문 파트가 (하드웨어에 의하든 소프트웨어에 의하든) 병렬적으로 디스플레이가 가능해야 한다.   예를 들어, 프리젠테이션 같이 텍스트/이미지/오디오가 동시에 나타나야 하는 경우이다. 하지만 플랫폼의 제약을 많이 받기 때문에, 실제 사용되는 일은 거의 없다.
report	현재 메시지의 상태를 알리기 위해 사용된다. 즉, 되돌아오는 메일 등을 이 형태로 처리한다. 본문 파트의 일부분으로 사용될 수 없으며, ‘반드시’ 탑 레벨의 컨텐트 타입으로만 쓰일 수 있다. 또한, 메시지 전체는 반드시 7비트 아스키 문자로만 이루어져 있어야 한다. (실제로는 8비트로 된 경우도 존재한다.)   이 타입의 서브 파트는 2 or 3개이고 다음 순서로 나타나야 한다. 첫번째 부분은 사람이 알아볼 수 있는 상태 설명 부분이다. 보통 Content-Type이 지정되어 있지 않기 때문에, Content-Type을 text/plain으로 설정해서 보게 된다. 두번째 부분은 기계가 파싱해서 사용할 수 있는 상태 설명이다. Content-Type은 "message/delivery-status"와 같은 형태로 나타난다. 이 부분도 반드시 나타나야 한다. 세번째 부분(선택 사항)은 원래 메시지 전체 or 일부분을 가지고 있다. 보통은 헤더에 문제가 있어서 메시지가 되돌아 오는 경우가 많기 때문에, RFC에서는 메시지 헤더만을 가지는 "text/rfc822" (실제로는 message/rfc822-headers가 더 많다) 타입을 권장하고 있지만, 요즘은 "message/rfc822" 타입으로 메시지 전체가 포함되는 것이 일반적이다.
related	각 본문 파트가 연관을 갖고 있다. 각 부분을 연결하는 방식이 응용프로그램마다 천차만별이다.   이 타입이 중요한 이유는 HTML 문서를 메시지로 전달하기 위한 것이다. HTML문서에는 단순히 텍스트뿐만 아니라 이미지 등의 객체가 포함되어야 하는데, 거기에 바로 각 content들을 Content-ID로 연결해서 사용하는 것이다.

 

 

* mulitpart/alternative로 구성된 메시지의 예제

 : 각 부분의 내용은 같지만, 서로 다른 포맷을 가진다.

 

From: Nathaniel Borenstein To: Ned Freed Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii ... plain text version of message goes here ... --boundary42 Content-Type: text/enriched ... RFC 1896 text/enriched version of same message goes here ... --boundary42 Content-Type: application/x-whatever ... fanciest version of same message goes here ... --boundary42--

 

 

* mulitpart/digest로 구성된 메시지의 예제

: 각 부분의 기본 컨텐트 타입이 ‘message/rfc822’이다.

 

From: Moderator-Address To: Recipient-List Date: Mon, 22 Mar 1994 13:34:51 +0000 Subject: Internet Digest, volume 42 MIME-Version: 1.0 Content-Type: multipart/digest; boundary="---- main boundary ----" ------ main boundary ---- ...Introductory text or table of contents... ------ main boundary ---- Content-Type: multipart/digest;boundary="---- next message ----" ------ next message ---- From: someone-else Date: Fri, 26 Mar 1993 11:13:32 +0200 Subject: my opinion ...body goes here ... ------ next message ---- From: someone-else-again Date: Fri, 26 Mar 1993 10:07:13 -0500 Subject: my different opinion ... another body goes here ... ------ next message ------ ------ main boundary ------

 

 

 

 

 

★ “Message” Content-Type

 

* Message 타입의 서브 타입

 

서브 타입	설 명
RFC822	가장 간단하게 메일 메시지를 포함하고 있는 타입. 되돌아온 메시지에 가장 많이 포함된다.
Partial	큰 메시지의 경우, 여러 개의 메시지로 잘라서 보내고, 받는 쪽에서 합쳐서 봐야 할 필요가 있을 때 사용하기 위한 타입. 각 메시지에 몇 번째 조각인지, 전체는 몇 조각인지를 표시한다. 또한, 같은 메시지의 조각임을 나타내기 위해 id라는 파라미터를 사용한다.   메시지 분할의 원칙은 http://www.iwiz.pe.kr/bbs/view/java/article_38.html 를 참조하자.
	총 3조각의 메시지 중 2번째 조각.	Content-Type: Message/Partial; number=2; total=3; id=”oc=jpbe0M2Yt4s@thumper.bellcore.com” or Content-Type: Message/Partial;          id=”oc=jpbe0M2Yt4s@thumper.bellcore.com”; number=2;
	총 3조각의 메시지 중 3번째 조각.	Content-Type: Message/Partial; number=3; total=3;  id=”oc=jpbe0M2Yt4s@thumper.bellcore.com” (반드시 총 조각수를 갖고 있어서, 자신이 마지막 조각임을 알려야 한다.)
External-Body	실제 내용이 메시지 내부에 있는게 아니라 외부에 있다고 알린다.

 

 

[출처] [메일] “Multipart” Content-Type|작성자 플그림이