1. 程式人生 > >發郵件的協議: smtp 協議:

發郵件的協議: smtp 協議:

MIME郵件格式

在RFC 2822文件中定義了簡單的 ASCII編碼的Email的郵件格式,然而隨著Internet的發展,Email郵件僅僅傳輸簡單的文字已經滿足不了使用者的需求,為了在Email 中傳輸大量HTML、影象、聲音以及各種附件格式,一種新的擴充套件的郵件格式應運而生——MIME。由於在MIME郵件格式非常複雜,大量的RFC文件中對 MIME郵件格式進行了定義與說明,比如RFC2045, RFC2046, RFC2047, RFC2049, RFC2231, RFC2387, RFC4288, RFC4289等。因此,MIME郵件格式為我們提供了極大的靈活性的同時也給我們解讀MIME格式的Email郵件帶來了極大的困難。以下就一封具體的郵件原始資訊對MIME郵件格式作出一個概要的介紹。

解釋幾個常用且不易理解的Content-Type開頭的MIME首部:

Received: from JSJ104 (unknown [202.204.96.147])

    by smtp14 (Coremail) with SMTP id wKjRDyJAHALkc2lFEtAjAg==.38990S2;

    Sun, 26 Nov 2006 19:00:55 +0800 (CST)

Subject: =?gb2312?B?MTIzMTIzxOO6wzEyMzEyMw==?=

Date: Sun, 26 Nov 2006 19:01:04 +0800

MIME-Version: 1.0

Content-Type: multipart/alternative;

    boundary="----=_NextPart_000_0003_01C7118D.38E01920"

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2900.2869

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C7118D.38E01920

Content-Type: text/plain;

    charset="gb2312"

Content-Transfer-Encoding: base64

MTIzMTIzMTIz

------=_NextPart_000_0003_01C7118D.38E01920

Content-Type: text/html;

    charset="gb2312"

Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv

L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu

dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w

MC4yOTAwLjI5OTUiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8

Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj4xMjMxMjMxMjM8L0ZPTlQ+

PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0003_01C7118D.38E01920--

這封Email具有一個郵件首部,然後是郵件的主體部分,它包括一個文字和一個HTML型別。可以注意到這樣一行編碼 “boundary="----=_NextPart_000_0003_01C7118D.38E01920" ”,它是用來隔離MIME郵件的各個實體部分。

在RFC2822中定義了MIME郵件首部的格式:

field-name ":" [ field-body ] CRLF

例如:

MIME-Version: 1.0

Content-Type: multipart/alternative;

Content-Type: text/plain;

Content-Transfer-Encoding: base64

最常見也用途最都的MIME首部是以Content-Type開頭的,在RFC2046給出了它的定義,大致與如下內容相似:

Content-Type: text/plain;

Content-Type: text/plain; charset=ISO-8859-1

Content-Type: text/plain; charset=us-ascii

Content-Type: text/plain; charset=utf-8

Content-Type: text/html;

Content-Type: text/html; charset=ISO-8859-1

Content-Type: text/css

Content-Type: image/gif; name=image004.gif

Content-Type: image/jpeg; name="image005.jpg"

Content-Type: message/delivery-status

Content-Type: message/rfc822

Content-Type: audio/x-mpeg

Content-Type: video/mpeg-2

Content-Type: application/msword

Content-Type: application/mspowerpoint

Content-Type: application/zip

Content-Type: multipart/mixed;     boundary="----=_Part_3431_12384933.1139387792352"

Content-Type: multipart/alternative; boundary="----=_Part_4088_29304219.1115463798628"

Content-Type: multipart/related;     boundary="----=_Part_2067_9241611.1139322711488"

Content-Type: multipart/digest;     boundary="----=Next message 15543233913938263541"

Content-Type: multipart/report; report-type=delivery-status;

              boundary="k04G6HJ9025016.1136391237/carbon.singnet.com.sg"

Content-Type: multipart/parallel

1) Content-Type: multipart/mixed

它表明這封Email郵件中包含各種格式的MIME實體但沒有具體給出每個實體的型別。

2) Content-Type: multipart/alternative

如果同一封Email郵件既以文字格式又以HTML格式傳送,那麼要使用Content-Type: multipart/alternative。這兩種郵件格式實際上是顯示同樣的內容但是具有不同的編碼。

3) Content-Type: multipart/related

用於在同一封郵件中傳送HTML文字和影象或者是其他類似型別。

郵件主體的編碼:

主要是包括quoted-printable與base64兩種型別的編碼。Base64和Quoted-Printable都屬於MIME(多用途部分、多媒體電子郵件和 WWW 超文字)的一種編碼標準,用於傳送諸如圖形、聲音和傳真等非文字資料)。

一.Base64

  Base64是現今在網際網路上應用最多的一種編碼,絕大多數的電子郵件軟體頭把它作為預設的二進位制編碼,比如我們常用的Outlook。

Base64內容傳輸編碼被設計用於以人無法可讀的方式來表述八位組的任意序列。編碼與解碼演算法很簡單,但是編碼資料總是比非編碼資料長33%。這種編碼實際上類似於RFC1421中定義的在增強保密郵件(PEM)應用程式中使用的編碼方式。

  編碼程式將字元流順序放入一個 24 位的緩衝區,缺字元的地方補零。從左到右,一個24位輸入組通過級聯3個八位輸入組組成。隨後這24位截斷成為 4 個部分,每個部分 6 位,分別被翻譯為base64字母表中的一個單獨數字。當通過Base64編碼一個位流時,位流必須假設為以最高有效位優先的順序排列。也就是說,流中的第一位將是第一位元組中的高階位,而第八位則位第一位元組中的低端位元組位。

  如果輸入資料不足24個字元,即只有一個或兩個位元組時,則需要經過特殊處理——在資料末尾填充"="字元,這可以隔斷附加的資訊造成編碼的混亂。

在Base64編碼資料中,任何在Base64字母表之外的字元將被忽略。Base64編碼中的非法字元序列也將被忽略,例如"=====".

二.Quoted-Printable

    Quoted-Printable與Base64一樣,常常用在Email系統中。它通常用於少量文字方式的8位字元的編碼,例如Foxmail就用它做對主題和信體的編碼。這種編碼的應該是很好辨認的:它有大量的'='。

   QP的演算法非常的簡單但是編碼效率很低(1:3),它是專門為了處理8位字元制定的。它的演算法是:讀一個字元,如果ASCII碼大於127,即字元的第8位是1的話,進行編碼,否則忽略(有時也對7位字元編碼)。

foxmail 配置的時候,需要配置   發郵件伺服器,和收取郵件的伺服器和埠。

這個 需要檢視使用的郵件服務提供商使用的伺服器 傳送 和接受郵件的協議。

SMTP  傳送郵件伺服器的埠 一般為 465 或 587 

imap pop 接受郵件的埠一般為 993 。