內容轉換

CasinoGames · 发表于 2025-11-1 15:17:16

標頭功能變數名稱
預設值
描述

MIME-Version
1.0
此標頭欄位是出現在 MIME 格式訊息中的第一個 MIME 標頭欄位。此標頭欄位會出現在其他標準 RFC 2822 標頭欄位之後，但在任何其他 MIME 標頭欄位之前。 MIME 感知電子郵件用戶端會使用此標頭欄位來識別 MIME 編碼的訊息。當此標頭欄位不存在時，MIME 感知電子郵件用戶端會將訊息識別為純文字。

Content-Type
text/plain

此標頭欄位會識別訊息內容的媒體類型，如 RFC 2046 中所述。媒體類型包含類型、子類型，以及一或多個選擇性參數，例如定義 MIME 字元編碼的 charset= 參數。開頭為「x-」的類型不是標準的。開頭為「vnd」的子類型是廠商特有的。 IANA (的網際網路指派號碼授權單位) 維護已註冊媒體類型的清單。如需詳細資訊，請參閱 MIME 媒體類型。

            多部分媒體類型可讓您使用不同媒體類型所定義的區段，在相同的訊息中提供多個訊息元件。某些 Content-Type 域值包括 text/plain、text/html、multipart/mixed 和 multipart/alternative。

Content-Transfer-Encoding
7 位
此標頭欄位可以描述有關訊息的下列資訊：編碼演算法，用來轉換存在於訊息本文中的任何非 US-ASCII 文字或二進位資料。描述訊息本文目前條件的指標。
MIME 訊息中可以有多個 Content-Transfer-Encoding 標頭欄位的值。當 Content-Transfer-Encoding 標頭欄位出現在訊息標頭中時，它會套用至訊息的整個本文。當 Content-Transfer-Encoding 標頭欄位出現在多部分訊息的其中一個部分時，它只適用于訊息的該部分。

將編碼演算法套用至訊息本文資料時，訊息本文資料會轉換成純文字 US-ASCII 文字。此轉換可讓訊息通過僅支援 US-ASCII 文字訊息的舊版 SMTP 訊息伺服器。表示在訊息本文上使用編碼演算法的 Content-Transfer-Encoding 標頭欄位值如下所示：

            可引號列印：此編碼演算法會使用可列印的 US-ASCII 字元來編碼訊息本文資料。如果原始郵件內文大部分是 US-ASCII 文字，可加上引號的可列印編碼會提供一些可讀取且精簡的結果。除了等號之外，所有可列印的 US-ASCII 文字字元 (=) 字元都可以在沒有編碼的情況下表示。
            Base64：此編碼演算法主要以 RFC 1421 中定義的隱私權增強型郵件 (PEM) 標準為基礎。 Base64 編碼會使用 64 個字元的字母編碼演算法和 PEM 所定義的輸出填補字元來編碼訊息本文資料。 Base64 編碼的訊息通常比原始訊息大 33%。 Base64 編碼會產生可預測的訊息大小增加，並且最適合用於二進位資料和非 US-ASCII 文字。
一般而言，您不會在相同的訊息中看到使用多個編碼演算法。

當訊息本文上未使用任何編碼演算法時，Content-Transfer-Encoding 標頭欄位只會識別訊息本文資料的目前條件。 Content-Transfer-Encoding 標頭欄位的下列值指出訊息本文上未使用任何編碼演算法：

            7 位：這個值表示訊息本文資料已經是 RFC 2822 格式。具體而言，這表示下列條件必須成立：所有文字行長度都必須小於 998 個字元。所有字元都必須是具有 1 到 127 字元值的 US-ASCII 文字。CR 和 LF 字元只能一起用來表示文字行的結尾。
整個訊息本文可能是 7 位，或多部分訊息中訊息本文的一部分可能是 7 位。如果多部分訊息包含具有任何二進位資料或非 US-ASCII 文字的其他元件，則必須使用可加上引號或 Base64 編碼演算法來編碼訊息的該部分。

具有 7 位主體的訊息可以使用標準 DATA 命令在 SMTP 訊息伺服器之間移動。

            8 位：此值表示訊息本文資料包含非 US-ASCII 字元。具體而言，這表示下列條件必須成立：所有文字行長度都必須小於 998 個字元。訊息本文中的一或多個字元具有大於 127 的值。CR 和 LF 字元只能一起用來表示文字行的結尾。
整個訊息本文可以是 8 位，或多部分訊息中訊息本文的一部分可能是 8 位。如果多部分訊息包含具有二進位資料的其他元件，則必須使用可加引號或 Base64 編碼演算法來編碼訊息的該部分。

具有 8 位主體的訊息只能在支援 RFC 1652 中定義之 8BITMIME SMTP 延伸模組的 SMTP 訊息伺服器之間移動，例如執行 Exchange 2000 Server 或更新版本的伺服器。具體而言，這表示下列條件必須成立：
8BITMIME 關鍵字必須在伺服器的 EHLO 回應中公告。訊息仍會使用 SMTP 標準 DATA 命令來傳輸。不過，BODY=8BITMIME 參數必須新增至 MAIL FROM 命令的結尾。
            二進位：這個值表示訊息本文包含非 US-ASCII 文字或二進位資料。具體而言，這表示下列條件成立：允許任何字元序列。沒有行長度限制。二進位訊息元素不需要編碼。
具有二進位主體的訊息只能在支援 RFC 3030 中定義之 BINARYMIME SMTP 擴充功能的 SMTP 訊息伺服器之間移動，例如執行 Exchange 2000 Server 或更新版本的伺服器。具體而言，這表示下列條件必須成立：
BINARYMIME 關鍵字必須在伺服器的 EHLO 回應中公告。BINARYMIME SMTP 擴充功能只能與 CHUNKING SMTP 擴充功能搭配使用。
            區塊化可讓大型訊息本文以多個較小的區區塊轉送。區塊處理也定義于 RFC 3030 中。 CHUNKING 關鍵字也必須在伺服器的 EHLO 回應中公告。訊息會使用 BDAT 命令而非標準 DATA 命令來傳輸。當訊息具有訊息本文時，BODY =BINARYMIME 參數必須新增至 MAIL FROM 命令的結尾。
7 位、8 位和二進位值永遠不會一起存在於相同的多部分訊息中。這些值互斥。可加上引號的可列印或 Base64 值可能會出現在 7 位或 8 位多部分訊息本文中，但絕不會出現在二進位訊息本文中。如果多部分訊息本文包含由 7 位和 8 位內容組成的不同部分，則整個訊息會分類為 8 位。如果多部分訊息本文包含由 7 位、8 位和二進位內容組成的不同部分，則整個訊息會分類為二進位。

Content-Disposition
附件
此標頭欄位會指示啟用 MIME 的電子郵件用戶端應如何顯示附加檔案，如 RFC 2183 中所述。此欄位的值可以是 [內嵌] 或 [附件]。當此欄位的值為 Inline 時，附件會顯示在訊息本文中。當此欄位的值為 Attachment 時，附加檔案會顯示為與訊息本文不同的一般附件。當值為 Attachment 時，可以使用其他參數，例如 Filename、Creation-date 和 Size。

		自动登录	找回密码
密码			立即注册

內容轉換

浏览过的版块