關於 MIME 和在 Exchange 2000 伺服器及 Exchange Server 2003 中的內容轉換的常見問題

文章翻譯 文章翻譯
文章編號: 836555 - 檢視此文章適用的產品。
全部展開 | 全部摺疊

結論

本文包含關於 MIME 標準和編碼的方式讓不同郵寄的系統,以一起運作的常見問題集問題的答案。本文件簡短地說明您可以要如何疑難排解在 Microsoft Exchange 環境中的亂碼或無法讀取的郵件訊息。

其他相關資訊

Q1: 什麼是電子郵件訊息的格式?

A1: 網際網路電子郵件會遵循 RFC 2822 中定義的格式標準。訊息是由標頭欄位和主體所組成。 標頭欄位的集體命名 「 頁首 」 的訊息。郵件的本文是選擇性的。不含一個本文,但不是無標頭,可以傳送訊息。

標頭會包含一連串有特殊的語法字元行定義於 RFC 2822 格式標準。本文包含一連串的字元,請依照下列標頭,並且,藉由空白的一行 (也就是具有執行任何動作之前翼傳回線條),並線條送紙 [CRLF] 來分隔標頭。

標頭欄位是線條由組成的欄位名稱,後面接著冒號 (:),後面接著欄位主體,並且由一個 CRLF 結束。欄位名稱必須組成可列印 US-ASCII 字元 (也就是有字元 33 到 126 (含) 之間的值),之,除了冒號。在冒號作為分隔字元。

欄位內文可能會由為 [CRLF 除外的任何 US-ASCII 字元所組成。不過,欄位內文可能包含 CRLF 用於標頭 摺疊] 及 [unfolding 時。摺疊是當,為了方便起見,單一行出現在多行上。unfolding 是與相反。所有欄位主體必須都遵循 3 和 4 標準的 RFC 2822 格式的章節所述的語法。

郵件內文可能包括一或多個區段。每個主體區段被隔開的邊界。界限參數是以兩個連字號 (-) 開頭的文字字串。

Q2: 什麼是 MIME?

A2: MIME 是標準,可以用來在單一訊息中包含各種類型的內容。MIME 延伸簡易郵件傳送通訊協定 (SMTP) 格式的郵件訊息,以包含文字或非文字的多個內容。部份訊息可能是音訊,影像或文字在不同的字元設定。標準 MIME 衍生自 RFC 2821 及 2822年。

Q3: 如何並 Exchange 處理 MIME?

A3: 有三個主要元件在 Exchange 中的執行內容轉換:
  • IMAIL 元件是核心元件,將網際網路郵件轉換為 MAPI / Exchange 格式,反之亦然。它也會檢查訊息的完整性。
  • EXMIME 元件是負責轉譯 Exchange 的內部物件表示法中的網際網路郵件,以及產生 MIME 格式的郵件。
  • RFHTML 元件純文字格式 (RTF) 訊息,將其轉換成轉換 HTML 之間互相 Microsoft Outlook 用戶端上的設定與 Exchange Server 電腦上的設定。

Q4: 什麼是 MIME 格式化的電子郵件訊息的最小需求?

A4: 出現在標頭和主體,通常會有一個 MIME 格式化電子郵件訊息。一個至少 MIME 訊息必須有標頭。本文是選擇性的。[標頭] 區段會包括 [MIME 1.0 版標頭 (每個郵件所定義的 RFC 2822 一個)。

本文章節包括:
  • 內容型別 (這是選擇性的。預設值是文字/純,所定義的 RFC 2822 5.2)。
  • 內容傳遞編碼標頭] (這是選擇性的。預設值為 7 位元所定義的 RFC 2822 6.1)。
  • 內容配置標頭 (這是選擇性)。
  • 一個內容識別碼 (這是選擇性)。


Q5: 什麼是 MIME 版本標頭?

A5: MIME 版本標頭欄位代表 MIME 格式化的訊息。傳送的訊息從較早的軟體不支援 MIME 沒有此欄位。 郵件用戶端使用此欄位不存在,來區別非 MIME 訊息。

Q6: 什麼是內容類型標頭?

A6: 內容類型] 欄位用來在一個欄位中指定類型和副類型的資料。

標頭型別是多重/混合、 多重/替代方案、 文字/純、 文字/html、 應用程式/applefile、 應用程式/ms-tnef 以及應用程式/八位元資料流。

Q7: 什麼是內容轉移編碼?

A7: 不同的郵件系統以不同的方式,處理資料,而且某些較舊的郵件系統無法處理多媒體資料。

如果要解決無法處理多媒體資料的系統,編碼配置用來將資料轉換成統一的 7 位元格式。當收件者會收到訊息時,資料會還原成其原始格式。內容轉移編碼格式的某些範例如下:
  • 以引號括住-可列印
  • Base64
  • 8 位元
  • 7 位元
  • 二進位


Q8: 如何在 Exchange 5.5 中實作是傳遞編碼?

A8: Exchange 5.5 編碼以引號括住-可列印的格式或與必要的 7 位元格式。此外,Exchange 5.5 編碼以 Base64 格式的訊息,如果訊息的 25%製造的 8 位元的字元 (也就是字元位於美國 ASCII 範圍之外的)。這只適用於訊息主體 ; 附件永遠是 Base64 編碼。

Q9: 如何傳遞編碼在 Exchange 2000 Server 中實作?

A9: 路由群組界限和 SMTP 目標目的地決定了 Exchange 2000 伺服器將郵件的編碼。Exchange 2000 會編碼為以引號括住-可列印或 7 位元或傳輸中立壓縮格式 (TNEF) 收件者或兩個伺服器/不同路由群組其收件者到網際網路之間傳送時。

傳送至收件者/伺服器位於相同的路由群組時,Exchange 2000 Server 會編碼二進位或摘要 TNEF 中。

Q10: 如何在 Microsoft Exchange Server 2003 中實作是傳遞編碼?

A10: 當路由群組界限,Exchange 和 SMTP 目標目的地也會判斷 Exchange Server 2003 將郵件的編碼。

在混合模式 Exchange Server 2003 會編碼為以引號括住-可列印或 7 位元 (TNEF 格式) 收件者或兩個伺服器/不同路由群組其收件者到網際網路之間傳送時。

在原生模式 Exchange Server 2003 編碼二進位 (摘要 TNEF) 中時傳送到收件者/伺服器相同或其他路由群組中。

Q11: 什麼是內容配置標頭?

A11:這個標頭識別是否一區段會顯示為一個附件或出現在郵件內文中。

Q12: 如何並 Exchange 處理附件?

A12:Exchange Server 2003 將網際網路郵件儲存在其原生 (Native) 格式。這表示如果從網際網路格式感知的用戶端就像 Outlook Express 讀取的郵件,它們將呈現在其原始格式。

不過時從 MAPI 用戶端讀取的郵件,, IMAIL 對應網際網路格式適當的項目到 MAPI 內容。在實際上最小的一組 MAPI 屬性網際網路郵件甚至會傳遞至信箱之前必須升級從網際網路郵件 ; 這些包括 PR_SENT_REPRESENTING、 PR_SUBJECT,以及收件者表格。

從網際網路格式視計算 PR_BODY、 PR_HTML 及 PR_ATTACH_DATA_BIN 等其他 MAPI 內容。當 MAPI 用戶端第一次要求訊息時,就會發生轉換。Exchange 2000 伺服器再將提升這些原生的 MIME 屬性,以 MAPI 格式。

內容轉換在 Exchange Server 2003,呈現給用戶端輸入的 MIME 郵件時,期間 IMAIL 會執行下列動作:
  1. IMAIL 檢查完整檔案名稱 (Nameext) MIME 標頭中。如果找到一個名稱使用檔案名稱。
  2. IMAIL 檢查有部分的檔名。如果找到一個 IMAIL 會查看
    HKEY_CLASSES_ROOT/MIME/Database/content-type
    子機碼,以將檔案名稱副檔名對應到內容類型。如果找到相符的內容類型該副檔名會新增到該附件。如果找到不相符的內容類型會使用部分檔案名稱。
  3. 如果沒有檔案名稱在內容型別或內容配置標頭中指定的 IMAIL 搜尋相符的內容類型。如果找到一個附件將具有 ATT name 的格式 extext 其中是這個內容類型相關聯的副檔名。如果找到不相符的內容類型會使用.att"的延伸。Exchange 2000 伺服器需要內容類型標頭中的檔案名稱。


Q13: 什麼是完整的訊息結構?

A13:以下是郵件的一個完整與所顯示的所有標頭的範例。收件者通常會看到內文部分。已經在方括號中加入註解。

Received: from SMTP server (server1.example1.com IP address) 

by Receiver SMTP version 1.0 (server2.example2.com IP address); 

Mon, 28 Oct 2002 08:42:42 -0500 (EST)

Message-ID: <006@example1.com>

From: "User1" <user1@example1.com> (RFC 2822 sender) 

To: "User2" user2@example2.com> (RFC 2822 recipient) 

Subject: A test message to see if you can see me now!

Date: Mon, 8 Nov 2002 13:46:54 +0100

MIME-Version: 1.0

Content-Type: multipart/mixed; 
boundary="----=_NextPart_000_005A_01C27E88.79B98A90"

X-Priority: 3

Return-Path: user1@domain1.com

X-OriginalArrivalTime: 28 Oct 2002 13:45:00.0541 (UTC) 
FILETIME=[35F0A2D0:01C27E88]

 

This is a multi-part message in MIME format (If you see this in the message 
body, there is a problem. Notice there is no space or CRLF in the headers in the previous text. There must be no space until the message body itself)

 

This message is in MIME format. Since your mail reader does not understand this 
format, some or all of this message may not be legible. (If you see this in the 
message body, there is a problem)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary) 

 

Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

 

Can you see me now??! (This is the text of the message. You see this in your mail client.)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary. See Multipart/Mixed 
definition earlier in this article.) 

Content-Type: image/jpeg;

name="Haloweenpictures.jpg"

Content-Transfer-Encoding: base64 (All attachments in Exchange 2000 Server are encoded by using base64 and bloat 33%.)  

Content-Disposition: attachment;

filename="Haloweenpictures.jpg"

 

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB  (Base64 data in raw format. This is the picture being encoded in binary format; to 
be repackaged later back as a picture.)

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

------=_NextPart_000_005A_01C27E88.79B98A90--


Q14: 為什麼執行郵件地址顯示在我的郵件內文?

A14:在第一個 「 CRLF CRLF 」 MIME 資料流中代表郵件本文的開頭。因此,如果兩個標頭之間有 <CRLF><CRLF>順序,用戶端 (Microsoft Outlook 或 Microsoft Outlook Express) 將顯示亂碼的訊息。

網際網路郵件標頭和郵件本文之間,必須在第一個 「 CRLF CRLF 」 來區隔。這些標頭稱為 P1 標頭。P1 標頭是信封標頭,而且不處理的 IMAIL 網際網路訊息的一部分。

Exchange 可能會轉寄至智慧主機、 內容的掃描裝置、 病毒牆或防火牆。協力廠商防火牆軟體有時可能會扭曲的郵件。

您可能也會收到的電子郵件訊息透過 UNIX 系統、 透過一個防火牆或透過病毒牆。而且,協力廠商內容掃描的裝置可能是在網路上。如果您在網路上有相似的應用程式或裝置,請確認收件者限制]。請避免在診斷測試中使用這類裝置或應用程式。

Q15: 為什麼做問號出現在我的訊息?

A15:如果問號出現在郵件,表示系統並不知道如何轉譯的某些 ANSI 或 Unicode 字元在訊息中。您必須確定檢視訊息時用戶端具有安裝符合輸入的字元集的字碼頁。比方說,請確定 Windows 工作站日本的地區設定安裝日文中寫入的檢視訊息。

Q16: 為什麼我沒有開啟 HTML 郵件的困難和我在我的應用程式記錄檔中看到事件 12002 和 12003?

A16:這些應用程式記錄檔事件是從來源 Exchange 資訊儲存庫,而且內容轉換錯誤。這些訊息部份可以忽略,而且在收到的郵件上沒有任何影響。但是如果看到許多這些訊息在應用程式記錄檔中看到是否用戶端有開啟 HTML 郵件的問題。

如果發生這種情形,建立更多診斷資訊,像是服務套件版本問題訊息的應用程式和系統記錄檔複本的複本,然後疑難排解。

Q17: 為什麼我有時看郵件內文以附件方式?

A17:您必須建立訊息的來源的相關資訊。您必須建立來源伺服器的所有詳細資料。您必須調查寄件者是在 UNIX 網路上。如需有關這個問題的詳細資訊,按一下 [下面的文件編號,檢視 「 Microsoft 知識庫 」 中的發行項]:
323482 Exchange 會顯示以附件的方式使用 「 線內 」 MIME 內容配置標頭的訊息
Q18: 我要為什麼看到 「 這是多元的訊息,在 」 或 「 這個訊息在 MIME 格式 」 的電子郵件本文中? MIME 格式。

A18:您可能會看到文字本文中下列一項:
  • 「 這是多元 MIME 格式訊息 」。
  • 「 這個訊息是以 MIME 格式。因為郵件讀取器不了解此格式,部份或全部這封郵件可能不是易於閱讀 」。

此文字已插入第一個界限之前,通常出現在每個多部份郵件而且看不到用戶端除非有電子郵件格式有問題。比方說硬碟分行符號可能被插入訊息中錯誤的位置。

如果要這個問題的疑難排解開啟郵件保存在 Microsoft Exchange 網際網路郵件服務。若要開啟郵件保存,使用 Exchange Server 2003 封存接收器公用程式]、 將郵件儲存為.eml 或.pst,然後執行詳細分析]。如 「 封存 」 接收功能的更多有關,按一下 [下面的文件編號,檢視 「 Microsoft 知識庫 」 中的發行項]:
307798封存接收器公用程式是在 Service Pack 2
Q19: 為什麼是我的郵件大小大於我預期約 33%,為什麼是它 base64 編碼即使它不包含附件嗎?

A19:如果您使用下列的字元組,就會發生這種行為:
  • 日文 Shift JIS
  • KOR
  • 日文 EUC
  • 韓文 ISO-2202年-KR
  • 台灣 ISO 2202 TW
  • 中文 ISO-2202年-CN
  • 中文 HZ_GB Big5,GB18030


Q20: 什麼是其他常見和已知的問題?

A20:從一台 Exchange Server 2003 伺服器轉送到另一個的訊息可能會出現亂碼,並且郵件的收件者可能會顯示在訊息主體。

比方說這可能是因為傳入的網際網路 Exchange Server 2003 電腦然後再到另一部 Exchange Server 2003 電腦,從網際網路路由的郵件中。
該訊息可能會正確顯示在 [輸入網際網路 Exchange Server 2003 上,但混亂後端 Exchange 伺服器上。如果減少在郵件上的收件者數目,也可能會變更這些徵狀。 這個問題可以出現幾個原因,但有兩個最常見的原因:
  • RFC 2822 郵件標題的一行中 998 字元而不是依行中有超過 1000年或 1024年個字元。詳細資訊請參閱要求的註解 (RFC) 2822年。此,請造訪下列網際網路工程任務推動小組 (IETF) 網站]:
    http://www.ietf.org/rfc/rfc2822.txt?number=2822
    如果使用二進位資料,或 區塊,將會轉送到 Exchange Server 2003 電腦的郵件,您可能會遇到這個問題。區塊是擴充為支援以區塊傳送資料的 SMTP 格式。

    當 Exchange Server 2003 收到一則訊息,在一行中有多個 998 字元時,SMTP 服務剖析標頭,並探索線條長度超過 1000 個字元。SMTP 服務然後假設這一行不是頁首的一部份,且包含主體中。

    SMTP 服務,Exchange Server 電腦上的將會再 re-write 它自己的標頭包括訊息 ID 及 DATE 標頭後面跟著一個空白行或一個 CRLF。
  • 線條長度限制。有許多的實作方式的以配合 RFC 2821 的傳輸需求不接受每包括 [CRLF 的一行超過 1000 個字元的訊息。因此,郵件應用程式必須不建立這類訊息。若要解決這個問題,關閉 ESMTP 動詞命令 (或區塊) 功能,Exchange Server 電腦上,並強制 Exchange Server 電腦來設定格式中典型的 SMTP 郵件格式化時轉送郵件。如需詳細資訊,請按一下下列的文件編號,檢視 「 Microsoft 知識庫 」 中的文件:
    257569如何關閉 ESMTP 動詞命令在 Exchange 2000 伺服器及 Exchange Server 2003 中
    821733內送訊息被混亂,如果 [收件者] 行超過 1,022 字元

?考

如需格式的標準 ARPA 網際網路文字訊息的多個資訊,請參閱 RFC 822。如果要執行此動作請造訪下列 IETF 網站:
http://www.ietf.org/rfc/rfc0822.txt?number=822
有關更多 MIME,請參閱 RFC 2045 2046年、 2047年、 2048 及 2049年。此,請造訪下列 IETF 網站:
http://www.ietf.org/rfc/rfc2045.txt?number=2045
http://www.ietf.org/rfc/rfc2046.txt?number=2046
http://www.ietf.org/rfc/rfc2047.txt?number=2047
http://www.ietf.org/rfc/rfc2048.txt?number=2048
http://www.ietf.org/rfc/rfc2049.txt?number=2049
如需詳細內容配置標頭欄位的相關資訊,請參閱 RFC 2183]。此,請造訪下列 IETF 網站:
http://www.ietf.org/rfc/rfc2183.txt?number=2183

屬性

文章編號: 836555 - 上次校閱: 2007年10月25日 - 版次: 3.4
這篇文章中的資訊適用於:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
關鍵字:?
kbmt kbfaq kbinfo KB836555 KbMtzh
機器翻譯
重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本:836555
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com