MIME

MIME
공연 예술 양식으로서의 MIME은 MIME 아티스트를 참조하십시오.그 외의 용도는, MIME(동음이의)을 참조해 주세요.
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

Multipurpose Internet Mail Extensions(MIME; 다목적 인터넷 메일 확장자)는 ASCII 이외의 문자 집합의 텍스트와 오디오, 비디오, 이미지 및 응용 프로그램 첨부 파일을 지원하도록 이메일 메시지의 형식을 확장하는 인터넷 표준입니다.메시지 본문은 여러 부분으로 구성될 수 있으며 헤더 정보는 비 ASC로 지정될 수 있습니다.II 문자 세트MIME 형식의 전자 메일 메시지는 일반적으로 SMTP(Simple Mail Transfer Protocol), POP(Post Office Protocol), IMAP(Internet Message Access Protocol)와 같은 표준 프로토콜로 전송됩니다.

MIME 표준은 일련의 코멘트 요구(RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 및 RFC 2049)로 지정되어 있습니다.SMTP 이메일과의 통합은 RFC 1521 및 RFC 1522에 규정되어 있습니다.

MIME 형식주의는 주로 SMTP를 위해 설계되었지만, 그 내용 유형은 다른 통신 프로토콜에서도 중요합니다.월드 와이드 웹용 HTTP(HyperText Transfer Protocol)에서 서버는 웹 전송 시작 부분에 MIME 헤더 필드를 삽입합니다.클라이언트는 컨텐츠 유형 또는 미디어 유형 헤더를 사용하여 표시된 데이터 유형에 적합한 뷰어 응용 프로그램을 선택합니다.

역사

MIME은 Andrew 고유의 데이터 [1]형식을 대체하는 크로스 플랫폼으로서 Carnegie Mellon University(CMU)에서 개발된 Andrew 프로젝트의 일부인 Andrew Messaging System에서 유래했습니다.

MIME 헤더필드

MIME 버전

이 헤더 필드의 존재는 메시지가 MIME 형식임을 나타냅니다.값은 보통 "1.0"입니다.필드는 다음과 같이 표시됩니다.

MIME 버전: 1.0

MIME의 공동창작자인 나타니엘 보렌스타인에 따르면, 버전 번호는 후속 버전에서 MIME 프로토콜에 대한 변경을 허용하기 위해 도입되었다.다만, Borenstein은, 이 기능의 실장을 방해하고 있는 사양의 쇼트 커밍을 인정했다.「우리는, 장래의 MIME 버전을 처리하는 방법을 적절히 지정하지 않았습니다.」 1.0을 알고 있는 것을 쓴다면 2.0이나 1.1을 알게 되면 어떻게 해야 할까요? 나는 그것이 당연하다고 다소 생각했지만 모두가 다른 방식으로 그것을 실행한 것으로 드러났다. 그 결과, 인터넷이 2.0이나 1.[2]1을 정의하는 것은 거의 불가능하게 됩니다."

콘텐츠 타입

이 헤더 필드는 메시지콘텐츠의 미디어 타입을 나타냅니다.예를 들어 유형 및 서브타입으로 구성됩니다.

Content-Type: 텍스트/보통

MIME은 멀티파트 타입을 사용함으로써 리프 노드가 멀티파트 이외의 콘텐츠 타입이고 비리프 노드가 다양한 멀티파트 타입 중 하나인 트리 구조로 메일 메시지를 배치할 수 있습니다.이 메커니즘은 다음을 지원합니다.

  • 텍스트/일반 텍스트메시지(「Content-Type:」의 디폴트값)
  • 텍스트 및 첨부 파일(텍스트/텍스트 및 기타 텍스트 이외의 부품과 혼합/반복)을 포함합니다.첨부파일을 포함한 MIME 메시지는 일반적으로 파일의 원래 이름을 "Content-Disposition" 필드로 나타내므로 파일 유형은 MIME 콘텐츠 유형과 (일반적으로 OS에 고유) 파일 확장자로 표시됩니다.
  • 원본 첨부 회신(텍스트/메시지 부분 및 메시지/메시지 부분으로서의 원본 메시지와 혼재/혼재)
  • 대체 콘텐츠, 예를 들어 일반 텍스트로 전송되는 메시지와 HTML과 같은 다른 형식(텍스트/일반 및 텍스트/html 형식으로 동일한 콘텐츠를 가진 멀티파트/대체)
  • image, audio, video, video/mp3, video/mp4, application/msword 등)
  • 기타 많은 메시지 구성체

콘텐츠 폐기

기존 MIME 사양은 메일 메시지의 구조만 설명했습니다.그들은 프레젠테이션 스타일의 문제를 다루지 않았다.content-disposition 헤더필드는 프레젠테이션스타일을 지정하기 위해 RFC 2183에 추가되었습니다.MIME 부품에는 다음이 있습니다.

  • 인라인 콘텐츠 디스포지션(메시지 표시 시 자동으로 표시됨) 또는
  • 첨부 파일 내용 처리는 자동으로 표시되지 않으며, 이 경우 이를 열려면 사용자의 작업이 필요합니다.

프레젠테이션 스타일 외에도, 내용-배치 필드는 파일 이름, 작성 날짜 및 수정 날짜를 지정하기 위한 매개변수를 제공하며, 이 매개변수는 독서자의 메일 사용자 에이전트가 첨부 파일을 저장하는 데 사용할 수 있습니다.

다음으로 헤더필드가 정의되어 있는 RFC 2183의 예를 제시하겠습니다.필드는 정의되어 있습니다.

Content-Disposition: 첨부파일명=삭제.jpeg; modification-date="1997년 2월 12일 수요일 16:29:51-0500";

파일명은 RFC 2231에 정의된 대로 부호화할 수 있습니다.

2010년 현재 메일 사용자 에이전트의 대부분은 이 처방을 완전히 따르지 않았습니다.널리 사용되는 Mozilla Thunderbird 메일클라이언트는 메시지의 내용 삭제 필드를 무시하고 독립된 알고리즘을 사용하여 자동으로 표시할 MIME 부분을 선택합니다.버전 3보다 이전 Thunderbird는 모든 MIME 부품에 대해 인라인 콘텐츠 디스포지션을 사용하여 새로 작성된 메시지를 발송합니다.대부분의 사용자는 내용 처리를 [3]첨부 파일로 설정하는 방법을 알지 못합니다.또한 많은 메일 사용자 에이전트는 헤더 필드의 Content-Disposition 파일 이름 매개변수 대신 content-type 헤더의 name 매개변수에 파일 이름으로 메시지를 발송합니다.파일명은 파라미터 파일명 또는 파라미터 파일명과 [4]이름을 모두 사용하여 지정해야 하므로 이 방법은 권장되지 않습니다.

HTTP에서 응답 헤더필드 Content-Disposition: attachment는 보통 클라이언트에 대한 힌트로 사용되며 응답 본문을 다운로드 가능한 파일로 나타냅니다.일반적으로 이러한 응답을 수신하면 웹 브라우저는 콘텐츠를 브라우저 창에 페이지로 표시하지 않고 기본 파일 이름을 나타내는 파일 이름으로 저장하라는 메시지를 표시합니다.

콘텐츠 전송 부호화

1992년 6월 MIME(RFC 1341, RFC 2045에 의해 폐지된 이후)는 ASCII 텍스트 형식 이외의 형식으로 바이너리 데이터를 나타내는 일련의 방법을 정의했습니다.content-transfer-encoding: MIME 헤더필드의 의미는 다음과 같습니다.

  • Content-Type 헤더에 지정된 원래 인코딩 위에 바이너리-to-text 인코딩 방식이 사용되었는지 여부를 나타냅니다.
  1. 이러한 바이너리-텍스트 부호화 방식이 사용되고 있는 경우는, 어느 쪽을 나타내고 있습니다.
  2. 그렇지 않은 경우 8비트 또는 이진 컨텐츠의 존재와 관련하여 컨텐츠 형식에 대한 설명적인 레이블을 제공합니다.

RFC 및 IANA의 전송 부호화 목록은 대소문자를 구분하지 않고 다음과 같은 값을 정의합니다.'7bit', '8bit' 및 'binary'는 원래 인코딩 위에 바이너리-to-text 인코딩이 사용되지 않았음을 의미합니다.이러한 경우 헤더필드는 전자 메일클라이언트가 메시지 본문을 디코딩하기 위해 실제로 용장화되어 있습니다만, 송신되는 오브젝트의 타입을 나타내는 인디케이터로서도 도움이 되는 경우가 있습니다.값 'quoted-printable' 및 'base64'는 전자 메일 클라이언트에 바이너리-to-text 인코딩 방식이 사용되었으며 메시지를 원래 인코딩(예: UTF-8)으로 읽기 전에 적절한 초기 디코딩이 필요하다는 것을 알려줍니다.

  • 일반 SMTP에서 사용하기에 적합합니다.
    • 7비트 – 코드 범위 1의 1행당 최대 998 옥텟..CR 및 LF(각각 코드 13 및 10)를 갖춘 127은 CRLF 회선 종료의 일부로서만 표시할 수 있습니다.이것이 기본값입니다.
    • quoted-printable : 임의의 옥텟시퀀스를 7비트 규칙을 충족하는 형식으로 인코딩하기 위해 사용합니다.주로 US-ASCII 문자로 구성되는 텍스트 데이터에 사용할 때 효율적이고 대부분 사람이 읽을 수 있도록 설계되었으며, 이 범위를 벗어나는 값의 일부 바이트도 포함합니다.
    • base64: 임의의 옥텟시퀀스를 7비트 규칙을 충족하는 형식으로 인코딩하기 위해 사용됩니다.텍스트 이외의 8비트 및 바이너리 데이터에 대해 효율적으로 설계되어 있습니다.US-ASCII 이외의 문자를 자주 사용하는 텍스트 데이터에 사용되는 경우가 있습니다.
  • 8 BITMIME SMTP 확장(RFC 6152)을 서포트하는 SMTP 서버에 적합합니다.
    • 8비트 – 1행당 최대 998 옥텟(CR 및 LF(각각 코드 13 및 10))까지 CRLF 행의 일부로서만 표시할 수 있습니다.
  • BINALMIME SMTP 확장(RFC 3030)을 지원하는 SMTP 서버와 함께 사용하기에 적합합니다.
    • binary : 옥텟의 임의의 시퀀스.

8BITMIME 확장의 SMTP 트랜스포트를 통해 임의의 바이너리 데이터를 송신하도록 명시적으로 설계된 인코딩은 정의되어 있지 않습니다.따라서 BISNALMIME이 지원되지 않는 경우에도 base64 또는 따옴표 인쇄 가능(관련 비효율성 포함)이 여전히 유용할 수 있습니다.이 제한은 MIME 첨부 파일이 있는 웹 서비스나 MTOM과 같은 MIME의 다른 사용에는 적용되지 않습니다.

부호화 워드

RFC 2822 이후 메시지헤더의 필드명과 값에 준거하고 있는 경우 ASCII 문자를 사용합니다.ASCII 이외의 데이터를 포함하는 값은 리터럴 문자열이 아닌 MIME 부호화 워드 구문(RFC 2047)을 사용해야 합니다.이 구문에서는 원래 문자 인코딩('charset')과 문자 집합의 바이트를 ASCII 문자로 매핑하기 위해 사용되는 content-transfer-encoding을 모두 나타내는 ASCII 문자 문자열을 사용합니다.

형식은 다음과 같습니다.=?문자 집합?부호화?부호화 텍스트?=".

  • charset은 IANA에 등록된 임의의 문자 집합입니다.일반적으로 메시지 본문과 동일한 문자 집합입니다.
  • 부호화에는, 「」를 사용할 수 있습니다.QQuoted-Printable 인코딩과 유사한 Q-encoding을 나타냅니다.Bbase64 인코딩을 나타냅니다.
  • encoded text는 Q 부호화 텍스트 또는 base64 부호화 텍스트입니다.
  • 부호화 워드는 문자 집합, 부호화, 부호화 텍스트, 딜리미터를 포함하여 75자를 초과할 수 없습니다.75 문자의 부호화 워드에 들어가는 것보다 많은 텍스트를 부호화하는 것이 바람직할 경우 여러 부호화 워드(CRLF SPACE로 구분)를 사용할 수 있습니다.

Q 인코딩과 따옴표 인쇄 가능의 차이

물음표("?") 및 등호("=")의 ASCII 코드는 인코딩된 단어를 구분하는 데 사용되므로 직접 표시할 수 없습니다.스페이스의 ASCII 코드는, 낡은 파서가 부호화 워드를 바람직하지 않게 분할할 가능성이 있기 때문에, 직접 표시할 수 없습니다.부호화를 보다 작고 읽기 쉽게 하기 위해 밑줄을 사용하여 공간의 ASCII 코드를 나타냅니다.따라서 밑줄을 직접 표시할 수 없는 부작용이 발생합니다.헤더 필드의 특정 부분에서 부호화된 단어를 사용하면 어떤 문자를 직접 나타낼 수 있는지에 대한 추가 제한이 발생합니다.

예를들면,

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

"Subject: 홀라, 세뇨르!"로 해석됩니다.

헤더 필드의 이름(Subject 등)에는 encoded-word 형식은 사용되지 않습니다.이러한 이름은 보통 영어 용어이며 미가공 메시지에서는 항상 ASCII로 표시됩니다.영어가 아닌 전자 메일 클라이언트에서 메시지를 볼 때 헤더 필드 이름이 클라이언트에 의해 변환될 수 있습니다.

멀티파트 메시지

MIME 멀티파트메시지는 헤더필드에 경계를 포함합니다.Content-Type:; 이 경계는 어느 부분에도 발생하지 않습니다.다음과 같이 각 부분과 메시지 본문의 시작과 끝에 배치됩니다.

MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=message 이것은 MIME 형식의 여러 부분으로 이루어진 메시지입니다. --message Content-Type: application/octet-stream Content-Transfer-Encoding: base64PGh0bWwci.PGHLYWQ+CiAgPC9oZWKPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUG Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --disc--

각 부분은 자체 콘텐츠 헤더로 구성됩니다(0개 이상).Content-헤더 필드) 및 본문.멀티파트 컨텐츠를 네스트 할 수 있습니다.그Content-Transfer-Encoding멀티파트 타입의 경우는, 복수의 디코딩 레벨에 의해서 발생하는 복잡함을 피하기 위해서, 항상 「7비트」, 「8비트」, 또는 「8비트」로 할 필요가 있습니다.멀티파트 블록 전체에 문자 집합이 없습니다(ASC 이외).부품 헤더의 II 문자는 Encoded-Word 시스템에 의해 처리되며, 부품 본문은 해당 컨텐츠 유형에 따라 지정된 문자 집합을 가질 수 있습니다.

주의:

  • 첫 번째 경계 앞은 MIME 준거 클라이언트에 의해 무시되는 영역입니다.이 영역은 일반적으로 오래된 비 MIME 클라이언트 사용자에게 메시지를 보내기 위해 사용됩니다.
  • 본문 텍스트와 충돌하지 않는 경계 문자열을 선택하는 것은 발송 메일 클라이언트에 달려 있습니다.일반적으로 이것은 긴 랜덤 문자열을 삽입함으로써 수행됩니다.
  • 마지막 경계는 끝에 하이픈이 2개 있어야 합니다.

멀티파트 서브타입

MIME 표준에서는 다양한 멀티파트메시지 서브타입이 정의되어 메시지 파트의 특성 및 메시지 파트의 상호 관계를 지정합니다.서브타입은 에 지정되어 있습니다.Content-Type메시지 전체의 헤더필드예를 들어 다이제스트 서브유형을 사용하는 멀티파트 MIME 메시지에는 다음 메시지가 있습니다.Content-Type"discart/disclosed"

RFC는 처음에 혼합, 다이제스트, 대체 및 병렬의 4가지 서브 타입을 정의했습니다.최소 호환 애플리케이션은 혼합 및 다이제스트를 지원해야 합니다.다른 서브타입은 옵션입니다.응용 프로그램은 인식할 수 없는 하위 유형을 "멀티파트/혼합"으로 처리해야 합니다.이후 서명된 데이터나 폼 데이터 등의 추가 서브타입은 다른 RFC에서 별도로 정의되어 있습니다.

혼재된

multipart/mixed는 다른 파일 전송에 사용됩니다.Content-Type헤더 필드를 인라인(또는 첨부 파일로)합니다.사진이나 읽기 쉬운 다른 파일을 보내는 경우, 대부분의 메일 클라이언트는 해당 파일을 인라인으로 표시합니다(Content-Disposition: 첨부 파일로 명시적으로 지정되지 않은 경우).각 부품의 기본 내용 유형은 "text/plain"입니다.

이 유형은 RFC 2046에 [5]정의되어 있습니다.

다이제스트

multipart/multiple은 여러 텍스트메시지를 발송하는 간단한 방법입니다.각 부품의 기본 content-type은 "message/rfc822"입니다.

MIME 타입은 RFC 2046에 [6]정의되어 있습니다.

대안

멀티파트/대체 서브타입은 각 부품이 동일한(또는 유사한) 콘텐츠의 "대체" 버전임을 나타냅니다.각 버전은 "Content-Type" 헤더가 나타내는 다른 형식입니다.부품의 순서가 중요합니다.RFC1341의 스테이트:일반적으로 멀티파트/대체 엔티티를 구성하는 사용자 에이전트는 선호도가 높은 순서대로 신체 부위를 배치해야 한다. 즉,[7] 선호 형식이 마지막에 있어야 한다.

그 후, 시스템은 처리할 수 있는 「최적의」표현을 선택할 수 있습니다.일반적으로 이 부분이 시스템이 이해할 수 있는 마지막 부분이 됩니다.다만, 다른 요인이 영향을 주는 경우도 있습니다.

클라이언트는 보통 텍스트버전보다 충실도가 낮은 버전을 송신하려고 하지 않기 때문에 이 구조에서는 일반 텍스트버전(존재하는 경우)이 우선됩니다.이를 통해 멀티파트 메시지를 이해하지 못하는 클라이언트의 사용자가 보다 쉽게 작업할 수 있습니다.

일반적으로 multipart/alternative는 두 부분으로 구성된 전자 메일에 사용됩니다. 하나는 일반 텍스트(텍스트/보통)이고 다른 하나는 HTML(텍스트/html)입니다.일반 텍스트 부분은 하위 호환성을 제공하는 반면 HTML 부분은 형식 및 하이퍼링크를 사용할 수 있습니다.대부분의 전자 메일 클라이언트는 HTML보다 일반 텍스트를 선호하는 사용자 옵션을 제공합니다.이는 로컬 요인이 응용 프로그램이 메시지의 "최적" 부분을 선택하는 방법에 어떻게 영향을 미치는지 보여주는 예입니다.

메시지의 각 부분이 동일한 내용을 나타내는 것을 의도하고 있지만, 표준에서는 어떠한 방법으로도 이 내용을 강제할 필요가 없습니다.한 때 안티스팸 필터는 텍스트/html 부분보다 구문 분석이 더 쉽기 [8]때문에 메시지의 텍스트/일반 부분만 검사합니다.그러나 스팸 발송자들은 결국 이 점을 이용하여 악의 없이 보이는 텍스트/일반적인 부분으로 메시지를 생성하고 텍스트/html 부분에 광고를 했습니다.안티스팸 소프트웨어는 결국 이 속임수를 따라잡았고, 멀티파트/[8]대안 메시지에서 텍스트가 매우 다른 메시지를 처벌했습니다.

이 유형은 RFC 2046에 [9]정의되어 있습니다.

관련된

멀티파트/관련은 각 메시지 부분이 집약 전체의 구성요소임을 나타내기 위해 사용된다.여러 개의 상호 관련 컴포넌트로 구성된 복합 객체용입니다. 구성 부품을 개별적으로 표시해서는 적절한 표시를 할 수 없습니다.메시지는 다른 부분을 인라인으로 참조하는 루트 부분(기본적으로 첫 번째 부분)으로 구성됩니다.이 루트 부분은 다른 부분을 참조할 수 있습니다.메시지 부분은 일반적으로 Content-ID에 의해 참조됩니다.참조 구문은 지정되지 않았으며 대신 부품에서 사용되는 인코딩 또는 프로토콜에 의해 지정됩니다.

이 서브타입의 일반적인 사용방법 중 하나는 이미지를 포함한 웹페이지를 1개의 메시지로 전송하는 것입니다.루트 부분에는 HTML 문서가 포함되어 이미지 태그를 사용하여 후자에 저장된 이미지를 참조합니다.

이 유형은 RFC 2387에 정의되어 있습니다.

보고하다

다중 파트/보고서는 메일 서버가 읽을 수 있도록 포맷된 데이터를 포함하는 메시지 유형입니다.텍스트/보통(또는 읽기 쉬운 다른 내용/유형)과 메일 서버가 읽을 수 있도록 포맷된 데이터를 포함하는 메시지/배달 상태로 나뉩니다.

이 유형은 RFC 6522에 정의되어 있습니다.

서명된

멀티파트/서명된 메시지는 메시지에 디지털 서명을 첨부하기 위해 사용됩니다.그것은 정확히 두 개의 신체 부위가 있는데, 신체 부위와 시그니처 부위가 있다.MIME 필드를 포함한 본문 부분의 전체는 서명 부분을 만드는 데 사용됩니다.「application/pgp-signature」(RFC 3156)나 「application/pkcs7-signature」(S/MIME) 등, 많은 시그니처 타입이 가능합니다.

이 유형은 RFC [10]1847에 정의되어 있습니다.

암호화되어 있다

멀티파트/암호화 메시지는 두 부분으로 구성됩니다.첫 번째 부분에는 어플리케이션/옥텟스트림의 두 번째 부분을 복호화하기 위해 필요한 제어 정보가 있습니다.서명된 메시지와 마찬가지로 제어부에 대한 개별 콘텐츠 유형에 따라 식별되는 다양한 구현이 있습니다.가장 일반적인 유형은 "application/pgp-encrypted"(RFC 3156) 및 "application/pkcs7-mime"(S/MIME)입니다.

RFC [11]1847에서 정의된 MIME 유형.

폼 데이터

MIME 유형 멀티파트/폼 데이터는 폼을 통해 제출된 값을 표현하기 위해 사용됩니다.원래 HTML 4.0의 일부로 정의되어 있으며 HTTP를 사용하여 파일을 제출하기 위해 가장 일반적으로 사용됩니다.RFC 7578에 규정되어 있으며, RFC 2388의 예를 대체하고 있습니다.

x-혼합 치환

콘텐츠 타입 multipart/x-mixed-replace는 HTTP를 통한 서버 푸시 및 스트리밍을 에뮬레이트하는 테크놀로지의 일부로 개발되었습니다.

혼합 치환 메시지의 모든 부분은 동일한 의미 의미를 가집니다.그러나 각 부품은 이전 부품을 완전히 수령하는 즉시 무효화('대체')됩니다.클라이언트는 개별 부품을 도착하는 즉시 처리해야 하며 메시지 전체가 완료될 때까지 기다리지 마십시오.

원래 [12]Netscape에 의해 개발된 이 제품은 여전히 Mozilla, Firefox, Safari 및 Opera에서 지원됩니다.MJPEG [13]스트림의 MIME 유형으로 IP 카메라에서 일반적으로 사용됩니다.2013년까지 Chrome에서 주요 리소스를 지원했습니다(이 컨텐츠 [14]유형을 사용하여 이미지를 표시할 수 있습니다).

이상

멀티파트/비터레인지는 단일 메시지의 연속되지 않은 바이트 범위를 나타내기 위해 사용되며 서버가 여러 바이트 범위를 반환할 때 HTTP에 의해 사용되며 RFC 2616에 정의되어 있습니다.

RFC 문서

  • RFC 1426, 8bit-MIME transport용 SMTP 서비스 확장.J. 클렌신, N. 프리드, M. 로즈, E. 스테퍼루드, D.크로커.1993년 2월
  • RFC 1847, MIME 보안 멀티파트: 멀티파트/서명 및 멀티파트/암호화
  • RFC 3156, OpenPGP에 의한 MIME 보안
  • RFC 2045, MIME 제1부: 인터넷메시지 본문의 형식
  • RFC 2046, MIME Part 2: 미디어 유형.프리드, 나다니엘 보렌스타인1996년 11월
  • RFC 2047, MIME Part 3: ASCII 이외의 텍스트를 위한 메시지 헤더 확장자키스 무어1996년 11월
  • RFC 4288, MIME 제4부: 미디어 타입의 사양과 등록 절차.
  • RFC 4289, MIME Part 4: 등록 절차.프리드, J. 클렌신2005년 12월
  • RFC 2049, MIME Part 5: 적합성 기준 및 예시N. 프리드, N. 보렌스타인1996년 11월
  • RFC 2183 "인터넷메시지에서의 프레젠테이션 정보 전달: Content-Disposition 헤더필드Troost, R., Dorner, S. 및 K.무어, 1997년 8월
  • RFC 2231, MIME 파라미터 값과 부호화 워드 확장자: 문자 집합, 언어 및 계속.N. Free, K. Moore.1997년 11월
  • RFC 2387, MIME 멀티파트/관련 콘텐츠 유형
  • RFC 1521, 인터넷메시지 본문 포맷 지정 및 설명 메커니즘

「 」를 참조해 주세요.

레퍼런스

  1. ^ Terry Gliedt (May 27, 1996). "Messages - a Multi-Media Mailer".
  2. ^ "History of MIME". networkworld.com. February 2011.
  3. ^ Giles Turnbull (2005-12-14). "Forcing Thunderbird to treat outgoing attachments properly". O'Reilly mac devcenter. Retrieved 2010-04-01.
  4. ^ Ned Freed (2008-06-22). "name and filename parameters". Retrieved 2017-04-03.
  5. ^ RFC 2046, 섹션 5.1.3
  6. ^ RFC 2046, 섹션 5.1.5
  7. ^ "RFC1341 Section 7.2 The Multipart Content-Type". World Wide Web Consortium. Retrieved 2014-07-15.
  8. ^ a b "Overview of Anti-spam filtering Techniques" (PDF). International Research Journal of Engineering and Technology. 4 (1). January 2017. S2CID 212596952. Retrieved 2020-02-20.
  9. ^ RFC 2046, 섹션 5.1.4
  10. ^ RFC 1847, 섹션 2.1
  11. ^ RFC 1847, 섹션 2.2
  12. ^ "An Exploration of Dynamic Documents". Netscape. Archived from the original on 1998-12-03.
  13. ^ "WebCam Monitor setup documentation". DeskShare. Archived from the original on 2010-05-11.
  14. ^ "249132 - Remove support for multipart/x-mixed-replace main resources - chromium - Monorail". bugs.chromium.org. Retrieved 2017-10-10.

추가 정보

외부 링크