了解內容轉換

  • 發行項

 

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2016-11-28

內容轉換就是針對每位收件者來正確格式化郵件的處理程序。 是否在郵件上執行內容轉換，取決於所處理之郵件的目的地和格式。傳送到 Microsoft Exchange Server 組織中收件者的郵件，不需要任何內容轉換。 只有傳送到外部收件者的郵件，才可能需要內容轉換。

在 Exchange Server 2010 組織中，內容轉換是由已安裝 Hub Transport server role 之伺服器上的分類程式來處理。每一個郵件的分類是在新抵達的郵件放到提交佇列中之後進行。 在郵件放入傳遞佇列之前，除了收件者解析和路由解析之外，還會對郵件執行內容轉換。 如果單一郵件包含多位收件者，內容轉換會為每一位郵件收件者決定適當的編碼。 邊際傳輸伺服器上會進行縮寫的分類，其中不包含內容轉換作業。

目錄

了解電子郵件的結構

Exchange 2010 和 Outlook 郵件格式

內容轉換的元素

儲存區驅動程式執行的內容轉換

要尋找與內容轉換相關的管理工作嗎？ 請參閱 管理傳輸伺服器。

了解電子郵件的結構

您必須了解電子郵件的結構，才能更深入了解內容轉換。 SMTP 郵件是根據 7 位元 US-ASCII 純文字來撰寫和傳送電子郵件。 標準的 SMTP 郵件是由下列元素組成：

  • 郵件信封   RFC 2821 中會定義郵件信封。郵件信封包含傳輸和傳遞郵件所需的資訊。 收件者絕對看不到郵件信封，因為郵件信封是在郵件傳輸過程中產生，實際上不是郵件內容的一部分。

  • 郵件內容   RFC 2822 中會定義郵件內容。郵件內容是由下列元素組成：

    • 郵件標頭   郵件標頭是標頭欄位的集合。 標頭欄位依序由欄位名稱、冒號字元 ( : )、欄位內文及歸位/換行 (CR/LF) 字元組合所組成。

      欄位名稱必須由冒號字元 ( : ) 以外的可列印 US-ASCII 文字字元組成。 尤其是，允許具有 33 至 57 和 59 至 126 之值的 ASCII 字元。

      欄位內文可由任何 US-ASCII 字元組成，但歸位字元 (CR) 和換行字元 (LF) 除外。 不過，在 *「標頭摺疊」*中使用時，欄位內文可包含 CR/LF。 標頭摺疊就是將單一標頭欄位內文切割成多行，如 RFC 2822 的第 2.2.3 節所述。RFC 2822 的第 3 節和第 4 節則會說明其他的欄位內文語法需求。

    • 郵件內文   郵件內文就是郵件標頭後面出現的 US-ASCII 文字字元行的集合。 郵件標頭和郵件內文是以結尾是 CR/LF 字元組合的空白行隔開。 郵件內文是選用的。 郵件內文的任何文字行必須少於 998 個字元。 CR 和 LF 字元必須一起出現來表示行尾。

當 SMTP 郵件包含非 US-ASCII 純文字的元素時，郵件必須編碼以保留這些元素。 MIME 標準定義了將郵件中非文字之內容編碼的方法。 MIME 允許其他字元集的文字、非文字附件、Multipart 郵件內文及其他字元集的標頭欄位。 MIME 定義於 RFC 2045、RFC 2046、RFC 2047、RFC 2048 及 RFC 2077。MIME 定義可指定其他郵件屬性的郵件欄位集合。 下表說明一些重要的 MIME 標頭欄位。

重要的 MIME 標頭欄位

標頭欄位名稱 預設值 描述

MIME-Version

1.0

此標頭欄位是 MIME 格式的郵件中第一個出現的 MIME 標頭欄位。 此標頭欄位出現於其他標準 RFC 2822 標頭欄位之後，但在其他任何 MIME 標頭欄位之前。 MIME 感知電子郵件用戶端會使用此標頭欄位，以識別 MIME 編碼的郵件。 缺少此標頭欄位時，MIME 感知電子郵件用戶端會將郵件視為純文字。

Content-Type

text/plain

此標頭欄位可識別郵件內容的媒體類型，如 RFC 2046 所述。媒體類型由類型、子類型及一或多個選用的參數 (例如用來定義 MIME 字元編碼的 charset= 參數) 組成。 「x-」開頭代表非標準類型。 "vnd." 開頭的子類型則專門代表廠商。 網際網路指定編號機構 (IANA) 維護了一份已註冊的媒體類型清單。 如需相關資訊，請參閱 MIME 媒體類型 (英文)。

Multipart 媒體類型允許以不同媒體類型所定義的區段，讓相同的郵件中包含多個郵件部分。 一些 Content-Type 欄位值包括 text/plain、text/html、multipart/mixed 和 multipart/alternative。

Content-Transfer-Encoding

7bit

此標頭欄位可以說明下列郵件資訊：

  • 用來轉換郵件內文中的任何非 US-ASCII 文字或二進位資料的編碼演算法。

  • 說明郵件內文目前狀況的指標。

MIME 郵件的 Content-Transfer-Encoding: 標頭欄位可有多個值。 當 Content-Transfer-Encoding: 標頭欄位出現在郵件標頭內時，將會套用到整個郵件內文。 當 Content-Transfer-Encoding: 標頭欄位出現在 Multipart 郵件的其中一部分時，則只會套用到該郵件部分。

對郵件內文資料套用編碼演算法時，郵件內文資料會轉換為 US-ASCII 純文字。 此轉換可讓郵件通過僅支援 US-ASCII 文字郵件的舊型 SMTP 郵件伺服器。 指出郵件內文使用之編碼演算法的 Content-Transfer-Encoding: 標頭欄位的值如下：

  • Quoted-printable   此編碼演算法使用可列印的 US-ASCII 字元，將郵件內文資料編碼。 如果原始郵件文字大部分是 US-ASCII 文字，quoted-printable 編碼可以產生較易閱讀且簡潔的結果。 除了等號字元 ( = ) 以外，所有可列印的 US-ASCII 文字字元都不需要編碼就可呈現。

  • Base64   此編碼演算法絕大部分是根據 RFC 1421 所定義的 Privacy-Enhanced Mail (PEM) 標準。Base64 編碼使用 64 字元字母編碼演算法和 PEM 所定義的輸出填補字元，將郵件內文資料編碼。 Base64 編碼的郵件通常比原始郵件還大 33%。 Base64 編碼不會讓郵件大小的增加幅度超出預期，最適合用於二進位資料和非 US-ASCII 文字。

在相同的郵件中，通常不會使用多種編碼演算法。

當郵件內文未使用編碼演算法時，Content-Transfer-Encoding: 標頭欄位就只會識別郵件內文資料的目前狀況。 下列 Content-Transfer-Encoding: 標頭欄位值表示郵件內文未使用編碼演算法：

  • 7bit   此值表示郵件內文資料已經是 RFC 2822 格式。 特別是，這代表下列條件必須成立：

    • 所有文字行的長度必須少於 998 個字元。

    • 所有字元必須是具有字元值 1 至 127 的 US-ASCII 文字。

    • CR 和 LF 字元必須一起使用來表示一行文字的結尾。

    郵件內文可能整個都是 7bit，或是在 Multipart 郵件中，可能只有部分郵件內文是 7bit。 如果 Multipart 郵件中有其他部分具有任何二進位資料或非 US-ASCII 文字，則必須以 Quoted-printable 或 Base64 編碼演算法將該郵件部分編碼。

    利用標準的 DATA 命令，具有 7bit 內文的郵件可以在 SMTP 郵件伺服器之間流通。

  • 8bit   此值表示郵件內文資料包含非 US-ASCII 字元。 特別是，這代表下列條件必須成立：

    • 所有文字行的長度必須少於 998 個字元。

    • 郵件內文中有一或多個字元的值大於 127。

    • CR 和 LF 字元必須一起使用來表示一行文字的結尾。

    郵件內文可能整個都是 8bit，或是在 Multipart 郵件中，可能只有部分郵件內文是 8bit。 如果 Multipart 郵件中有其他部分具有二進位資料，則必須以 Quoted-printable 或 Base64 編碼演算法將該郵件部分編碼。

    具有 8bit 內文的郵件只能在支援如 RFC 1652 中所定義的 8BITMIME SMTP 延伸模組 (例如執行 Exchange 2010、Exchange Server 2007、Exchange Server 2003 或 Exchange 2000 Server 的伺服器) 的 SMTP 郵件伺服器之間流通。 特別是，這代表下列條件必須成立：

    • 伺服器的 EHLO 回應中必須通告 8BITMIME 關鍵字。

    • 郵件仍然是以 SMTP 標準 DATA 命令來傳送。 不過，必須在 MAIL FROM 命令的結尾加上 BODY=8BITMIME 參數。

  • Binary   此值表示郵件內文包含非 US-ASCII 文字或二進位資料。 特別是，這代表下列條件成立：

    • 允許任何字元順序。

    • 不限制行長度。

    • 二進位郵件元素不需要編碼。

    具有 8bit 內文的郵件只能在支援如 RFC 1652 中所定義的 BINARYMIME SMTP 延伸模組 (例如執行 Exchange 2010、Exchange 2007、Exchange 2003 或 Exchange 2000 的伺服器) 的 SMTP 郵件伺服器之間流通。特別是，這代表下列條件必須成立：

    • 伺服器的 EHLO 回應中必須通告 BINARYMIME 關鍵字。

    • BINARYMIME SMTP 延伸模組只能搭配 CHUNKING SMTP 延伸模組一起使用。 「區塊分割」(Chunking) 可以將較大的郵件內文分成多個較小的區塊來傳送。 區塊分割也定義於 RFC 3030。伺服器的 EHLO 回應中也必須通告 CHUNKING 關鍵字。

    • 郵件是利用 BDAT 命令來傳輸，而不是用標準的 DATA 命令。

    • 當郵件有郵件內文時，MAIL FROM 命令的結尾必須加上 BODY=BINARYMIME 參數。

在相同的 Multipart 郵件中，7bit、8bit 及 Binary 這三個值絕對不會同時出現。 這些值彼此互斥。 Quoted-printable 或 Base64 值可能會出現在 7bit 或 8bit Multipart 郵件內文中，但絕不會出現在 Binary 郵件內文中。 如果 Multipart 郵件內文包含由 7bit 和 8bit 內容所組成的不同部分，則整個郵件會歸類為 8bit。 如果 Multipart 郵件內文包含由 7bit、8bit 及 Binary 內容所組成的不同部分，則整個郵件就會歸類為 Binary。

Content-Disposition

Attachment

此標頭欄位 (於 RFC 2183 中有描述) 可指示已啟用 MIME 的電子郵件用戶端如何顯示附件檔。此欄位的值可能為 Inline 或 Attachment。 當此欄位的值是 Inline 時，附件會顯示在郵件內文中。 當此欄位的值是 Attachment 時，附件檔會顯示為一般附件，與郵件內文分開。 值為 Attachment 時還有其他參數可用，例如 Filename、Creation-date 及 Size。

Exchange 2010 和 Outlook 郵件格式

下列清單說明 Exchange 2010 和 Microsoft Outlook 中可用的基本郵件格式：

  • 純文字   純文字郵件只使用 US-ASCII 文字，如 RFC 2822 所述。郵件無法包含不同字型或其他文字格式。 純文字郵件可使用下列兩種格式：

    • 郵件標頭和郵件內文由 US-ASCII 文字組成。 附件必須以 Uuencode 編碼。 Uuencode 代表「Unix 對 Unix 編碼」，定義一種編碼演算法，可使用 US-ASCII 文字字元將二進位附件儲存在電子郵件的內文中。

    • 郵件實際上以 Content-Type 值 text/plain 進行 MIME 編碼，而 Multipart 郵件的文字部分則以 Content-Transfer-Encoding 值 7bit 編碼。 任何郵件附件的編碼都使用 Quoted-printable 或 Base64 編碼。 依預設，當您在 Outlook 中撰寫和傳送純文字郵件時，郵件實際上會以 Content-Type 值 text/plain 來進行 MIME 編碼。

  • HTML   HTML 郵件支援文字格式、背景影像、表格、項目符號及其他圖形元素。 根據定義，HTML 格式的郵件必須經過 MIME 編碼，才能保留這些格式元素。

  • RTF 格式   RTF 支援文字格式及其他圖形元素。 RTF 與傳輸中立封裝格式 (TNEF) 同義。 TNEF 和 RTF 可以交替使用。

    只有 Outlook 和少數其他 MAPI 電子郵件用戶端能夠判讀 RTF 郵件。MAPI 是 Microsoft 開發的訊息結構，可讓多支應用程式透過各種硬體平台與不同訊息系統互動。MAPI 建立在元件物件模型 (COM) 架構上。對於執行 Outlook 且已安裝 Mailbox server role 的電腦上的信箱，Exchange 2010 使用 MAPI 與這些信箱進行通訊。

    RTF 郵件格式和 MicrosoftWord 中可用的 RTF 文件格式完全不同。

  • TNEF   TNEF 是 Microsoft 專門用來封裝 MAPI 郵件內容的格式。 TNEF 郵件包含一個純文字版的郵件，以及一個包裝原始格式版本郵件的附件。 此附件通常名為 Winmail.dat。Winmail.dat 附件包含下列資訊：

    • 原始格式版本的郵件，例如包括字型、文字大小及文字色彩

    • OLE 物件，例如包括內嵌圖片或內嵌 MicrosoftOffice 文件

    • 特殊的 Outlook 功能，例如包括自訂表單、投票按鈕或會議邀請

    • 原始郵件中的一般郵件附件

    產生的純文字郵件可以用下列格式呈現：

    • RFC 2822 相容郵件，只由 US-ASCII 文字及 Uuencode 編碼的 Winmail.dat 附件組成

    • 含有 Winmail.dat 附件的 Multipart MIME 編碼郵件

    可完全判讀 TNEF 的 MAPI 相容電子郵件用戶端 (例如 Outlook) 可以處理 Winmail.dat 附件並顯示原始郵件內容，但絕不會顯示 Winmail.dat 附件。 無法判讀 TNEF 的電子郵件用戶端，可透過下列任何方式來呈現 TNEF 郵件：

    • 顯示純文字版的郵件，且郵件包含附件 Winmail.dat、Win.dat 或其他通稱，例如 Attnnnnn.dat 或 Attnnnnn.eml，其中的 nnnnn 預留位置代表隨機數字。

    • 顯示純文字版的郵件。 忽略或移除 TNEF 附件。 結果為純文字郵件。

    • 可判讀 TNEF 的郵件伺服器，可設定為從內送郵件中移除 TNEF 附件。 結果為純文字郵件。另外，有些電子郵件用戶端 (例如 Microsoft Outlook Express) 可能無法判讀 TNEF，但可辨識並忽略 TNEF 附件。 結果為純文字郵件。

    有協力廠商公用程式可以協助轉換 Winmail.dat 附件。

    Exchange 2010、Exchange 2007、Exchange 2003、Exchange 2000 與 Exchange Server 5.5 版 都可以判讀 TNEF。TNEF 郵件會透過標準的 DATA 命令動詞在 SMTP 郵件伺服器之間傳送。 Exchange 會根據下列情況自動使用 TNEF：

    • Exchange 2003   如果 Exchange 組織使用混合模式，對於在不同路由群組中的 Exchange 伺服器之間傳送的郵件，將會使用 TNEF。

    • Exchange 2000   在不同路由群組中於 Exchange 伺服器之間傳送的郵件，會使用 TNEF。

  • 摘要傳輸中立封裝格式 (STNEF)   STNEF 等同於 TNEF。 不過，STNEF 郵件和 TNEF 郵件的編碼方式不同。 尤其，STNEF 郵件一律為 MIME 編碼，且 Content-Transfer-Encoding 值一律為 Binary。 因此，郵件不會以純文字呈現，且郵件的內文也不含明確的 Winmail.dat 附件。 整個郵件只使用二進位資料來呈現。 Content-Transfer-Encoding 值為 Binary 的郵件，只能在支援且通告 BINARYMIME 和 CHUNKING SMTP 延伸模組 (如 RFC 3030 中所定義) 的 SMTP 郵件伺服器之間傳送。郵件一律使用 BDAT 命令在 SMTP 郵件伺服器之間傳送，而非使用標準的 DATA 命令。

    Exchange 2010、Exchange 2007、Exchange 2003 以及 Exchange 2000 都可以判讀 STNEF。當下列條件成立時，Exchange 會自動使用 STNEF：

    • Exchange 2010   對於在組織內的 Exchange 伺服器之間傳送的所有郵件，會使用 STNEF。

    • Exchange 2007   對於在組織內的 Exchange 伺服器之間傳送的所有郵件，會使用 STNEF。

    • Exchange 2003   如果 Exchange 組織使用原生模式，對於在組織內的 Exchange 伺服器之間傳送的所有郵件，將會使用 STNEF。

    • Exchange 2000   對於在相同路由群組中的 Exchange 伺服器之間傳送的郵件，會使用 STNEF。 對於在不同路由群組中 Exchange 的伺服器之間傳送的郵件，有一個未受支援的 Hotfix 也可以讓 Exchange 2000 使用 STNEF。

    Exchange 絕不會將 STNEF 郵件傳送給外部收件者。 只有 TNEF 郵件可傳送給 Exchange 組織外的收件者。

內容轉換的元素

內容轉換就是針對每一個外部收件者來正確格式化郵件的動作。 此轉換是由 Hub Transport Server 上的分類程式執行。

您在 Exchange 組織中可設定的內容轉換選項可分為下列幾類來說明：

  • TNEF 轉換選項   這些轉換選項指定是否該從離開 Exchange 組織的郵件中保留或移除 TNEF。

  • 郵件編碼選項   這些選項指定郵件編碼選項，例如 MIME 和非 MIME 字元集、郵件編碼及附件格式。

這些轉換和編碼選項彼此獨立。 例如，TNEF 郵件是否可離開 Exchange 組織，無關於這些郵件的 MIME 編碼設定或純文字編碼設定。

您可以在 Exchange 組織的各種層級指定內容轉換，如下列清單所述：

  • 遠端網域設定   遠端網域定義的設定，可讓外寄郵件在 Exchange 2010 組織和 Active Directory 樹系外的網域之間傳送。 即使沒有為特定網域建立遠端網域項目，原本就有一個預先定義的遠端網域稱為 Default，可用於所有遠端位址空間 ( * )。

  • 郵件使用者和郵件連絡人設定   郵件使用者類似郵件連絡人—兩者都有外部電子郵件地址，且包含 Exchange 組織以外的人員資訊。 主要的差別在於郵件使用者擁有可用來登入 Active Directory 網域，並且已授與權限可存取資源的安全性範圍。

  • Outlook 設定   在 Outlook 中，可讓您設定郵件的格式和編碼選項，如下列清單所述：

    • 郵件格式   您可以為所有郵件設定預設郵件格式。 在撰寫特定郵件時，也可以覆寫預設郵件格式。

    • 網際網路郵件格式   您可以控制是否將 TNEF 郵件傳送給遠端收件者，或是否要先轉換為更相容的格式。 對於傳送給遠端收件者的郵件，您也可以指定各種郵件編碼選項。 對於傳送給 Exchange 組織中收件者的郵件，這些設定則不適用。

    • 網際網路收件者郵件格式   您可以控制是否將 TNEF 郵件傳送給特定收件者，或是否要先轉換為更相容的格式。 您可以為 [連絡人] 資料夾中的特定連絡人設定轉換選項，也可以在撰寫郵件時，覆寫 [收件者]、[副本] 或 [密件副本] 欄位中特定收件者的轉換選項。 Exchange 組織中的收件者無法使用這些轉換選項。

    • 網際網路收件者郵件編碼選項   您可以為 [連絡人] 資料夾中的特定連絡人設定 MIME 或純文字編碼選項，也可以在撰寫郵件時，覆寫 [收件者]、[副本] 或 [密件副本] 欄位中特定收件者的轉換選項。 Exchange 組織中的收件者無法使用這些轉換選項。

    • 國際選項   您可以控制郵件使用的字元集。

TNEF 轉換選項

您可以指定下列層級的 TNEF 轉換選項：

  • 遠端網域設定

  • 郵件使用者和郵件連絡人設定

  • Outlook 設定，包括：

    • 郵件格式

    • 網際網路郵件格式

    • 網際網路收件者郵件格式

如需詳細資訊，請參閱 TNEF 轉換選項。

郵件編碼選項

您可以指定下列層級的郵件選項：

  • 遠端網域設定

  • 郵件使用者和郵件連絡人設定

  • Outlook 設定，包括：

    • 郵件格式

    • 網際網路郵件

    • 網際網路收件者郵件格式

    • 郵件字元集編碼選項

如需詳細資訊，請參閱郵件編碼選項。

儲存區驅動程式執行的內容轉換

儲存區驅動程式也會執行內容轉換。 儲存區驅動程式位於 Hub Transport Server，可在 Mailbox Server 和提交佇列之間傳輸郵件。 尤其，儲存區驅動程式可將郵件從寄件者的 [寄件匣] 傳輸到 Hub Transport Server 上的提交佇列，也可將郵件從 Hub Transport Server 上的提交佇列傳輸到收件者的 [收件匣]。 儲存區驅動程式會從 MAPI 轉換所有外寄郵件，也會將所有內送郵件轉換為 MAPI。 內容轉換追蹤可擷取這些儲存區驅動程式的轉換失敗。

如需相關資訊，請參閱內容轉換追蹤。

 © 2010 Microsoft Corporation. 著作權所有，並保留一切權利。