組織：中國(guó)互動(dòng)出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計(jì)劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：郭大剛（Guodagang   gdg0188_cn@sina.com）
譯文發(fā)布時(shí)間：2001-6-15
版權(quán)：本中文翻譯文檔版權(quán)歸中國(guó)互動(dòng)出版網(wǎng)所有?？梢杂糜诜巧虡I(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。

Net Working Group                                                G. Vaudreuil
Request for Comments: 1428                                        CNRI
February 1993


Internet郵件從Just-Send-8到8bit-SMTP/MIME的轉(zhuǎn)換
（RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME）


本備忘錄的狀態(tài)：
 本文檔提供了一種Internet社區(qū)的信息協(xié)議。它并不是規(guī)定了一個(gè)Internet標(biāo)準(zhǔn)。本
備忘錄的發(fā)布不受任何限制。


摘要：
為了通過8bit字符擴(kuò)充SMTP協(xié)議已經(jīng)定義了了[3][4]。按照這些協(xié)議的要求，通過擴(kuò)
充的SMTP協(xié)議傳送的消息將按照MIME協(xié)議的[1][2]被編碼。
在這些協(xié)議開始工作前，為了傳送8bit數(shù)據(jù)，幾個(gè)SMTP補(bǔ)充協(xié)議采用ad-hoc機(jī)制。
這急需擴(kuò)充了的SMTP環(huán)境和這些ad-hoc機(jī)制之間相互發(fā)揮作用。
1．	術(shù)語
RFC定義了7bit傳送。在本文檔中，傳送代理沒有在接收方的八進(jìn)制上用SMTP信息中
的比特集清除高級(jí)比特，這樣的傳送被稱為8bit透明傳送。
   在SMTP擴(kuò)充協(xié)議中的一個(gè)補(bǔ)充說明和8傳送MIME用8位一組中的全部8位信息的
8bit擴(kuò)充協(xié)議4被稱為8bit擴(kuò)充SMTP
   在擴(kuò)充SMTP協(xié)議中不接收8比特字符的擴(kuò)充體被稱為7bit ESMTP
   為改變或轉(zhuǎn)換一條信息的內(nèi)容用戶代理權(quán)威把網(wǎng)關(guān)定義為傳送代理。
2．	問題
在RFC821中定義的SMTP限制了internet 郵件到美國(guó)ASCⅡ5字符的傳送，隨著internet
已發(fā)展成包含非英文通信，通過其它字符集而非美國(guó)ASCⅡ字符集用來通信的需要促使
許多賣主和用戶來擴(kuò)充SMTP或RFC822來使用非ASCⅡ集。通常的方法是在現(xiàn)有的
RFC822/SMTP上傳送7bit ISO642字符集全局變量，利用8bitISO8859來擴(kuò)充SMTP和
RFC822協(xié)議，和使用PC的專用字符集 。第三種方法是用來處理日本郵件的，通過成
對(duì)的八進(jìn)制組清除高序bit，日文字符被表處理，顯現(xiàn)出來。在ISO釋放序列2022信息
中說明了從14bit字符集到7bit 字符集的轉(zhuǎn)換。
只要這些補(bǔ)充說明能夠不通過中級(jí)轉(zhuǎn)換而進(jìn)行通信，并有在不拖延地使用專用字符
集時(shí)有一個(gè)放寬的秘密協(xié)議，那么基本的郵件服務(wù)就能夠被提供。
在轉(zhuǎn)換為已定的8bitESMTP/MIME環(huán)境中，一個(gè)當(dāng)前沒有遵循協(xié)議的用戶所發(fā)送
的郵件能被另一個(gè)同樣沒有遵循協(xié)議的用戶所理解，這一點(diǎn)是很重要的。從8bit文本到
不可讀的Base—64編碼文本或被引用的可打印的“歪曲”編碼文本的轉(zhuǎn)換中降低了這
個(gè)現(xiàn)有的功能。在非美國(guó)ASCⅡ郵件和很可能出現(xiàn)到8bit/MIME轉(zhuǎn)換中的幾個(gè)新郵件
中，目前有一些有趣的非共同操作的例子，下面列出了到mine轉(zhuǎn)換的例子，在本備忘
錄中，只討論翻譯網(wǎng)關(guān)內(nèi)容4的解決辦法。



發(fā)件人
                     
   收件人           僅7bit         透明8bit          MIME/ESMTP

   僅7bit              (1)            (1)                 (1)
   
   透明8bit            (2)            (3)                 (4)

   MIME/ESMTP       (5)            (5)                 (6)


(1)	7bit 非MIME發(fā)件人到7bitMIME或透明8bit收件人
如果在發(fā)件人和收件人之間達(dá)成一個(gè)內(nèi)部的“超波段”一致，通過ISO646或ISO2022
字符集變量的轉(zhuǎn)換這將持續(xù)無變化的工作。一個(gè)從7bit到8bit/EMTP的網(wǎng)關(guān)不需要改變這
些信息的內(nèi)部。
（2）8bit發(fā)件人到7bit非MIME收件人
收件人將會(huì)接收到打包的bit郵件，這樣的郵件導(dǎo)致了數(shù)據(jù)之間的錯(cuò)誤解釋和字符的錯(cuò)
誤顯示和打印。使用ISO8859中美國(guó)ASCII子集字符語言發(fā)送的郵件在某種程度上是可讀
的。
（3）透明8bit發(fā)件人到透明8bit收件人
如果當(dāng)收件人和發(fā)件人之間達(dá)成了內(nèi)部的“超波段”一致后，用一個(gè)特殊的沒有貼標(biāo)
簽的字符集，在這種情況下會(huì)工作嗎？
（4）透明8bit發(fā)件人到非MIME7bit收件人
如果網(wǎng)關(guān)提供一個(gè)可行的升級(jí)路徑，如果這個(gè)網(wǎng)關(guān)插入的暗含的字符集的標(biāo)簽是正確
的，如果收件人支持發(fā)件人選擇的字符集，這種情況是可行的。這個(gè)例子是本備忘錄的焦點(diǎn)。
（5）MIME/ESMTP發(fā)件人到非MIME7bit收件人
由于ESMTP /MIME發(fā)件人不知道收件人是否接收8bit，發(fā)件人將把文本編碼成Base-64
或者是可被收件人看作“歪曲”了的引用形式。為了提供一個(gè)可用的下破路徑，網(wǎng)關(guān)必須有
一些關(guān)于收件人責(zé)任的常識(shí)。當(dāng)字符集能被清楚的識(shí)別時(shí)，在RFC1345中描述的MNEM編
碼技術(shù)在這個(gè)例子中可能會(huì)有幫助。
（6）MIME/ESMTP發(fā)件人到MIME/ESMTP收件人
如果收件人支持發(fā)件人所選擇的字符集，就可以達(dá)到互操作性。
3．	從透明8bit到ESMTP /MIME的升級(jí)路徑
改進(jìn)的用來支持?jǐn)U充的SMTP協(xié)議的網(wǎng)關(guān)可以提高M(jìn)IME接收到的一個(gè)8bit信息。
這與所有被ESMTP發(fā)送的8bit郵件必須編碼與MIME的要求是一致的。
一個(gè)站點(diǎn)可以通過完成對(duì)所有正遠(yuǎn)離此站點(diǎn)的消息的MIME轉(zhuǎn)換升級(jí)MIMEen-masse
對(duì)于文本信息，如果此站點(diǎn)使用單一的字符集，那么這個(gè)信息體會(huì)被加上一個(gè)MIME版本
的報(bào)頭和在該站點(diǎn)使用的字符集的內(nèi)容類型。
為了表明任何編碼都是必須的，必須添加一個(gè)適當(dāng)?shù)膬?nèi)容轉(zhuǎn)換編碼的報(bào)頭線。

例：
MIME版本：1.0
內(nèi)容-類型：Text/Plain;字符集=ISO-8859-1
內(nèi)容轉(zhuǎn)換編碼：8bit

如果使用的字符集沒有任何可用的信息，網(wǎng)關(guān)應(yīng)該使用“未知8bit”字符集來改進(jìn)內(nèi)容。
這個(gè)字符集參數(shù)的值表明了在消息中使用的字符集沒有任何可信的可以得到。
如果一個(gè)消息體被升級(jí)到MIME，包含非美國(guó)ASCII字符集的RFC822的報(bào)頭必須被升
級(jí)來和使用RFC1342編碼規(guī)則的報(bào)頭保持一致。
網(wǎng)關(guān)必須把所有未組織的報(bào)頭字段重新編碼以及根據(jù)RFC1342規(guī)則而來的RFC822的
“評(píng)注”和“短語”字段。
由于在RFC1342中沒有與“8bit”內(nèi)容報(bào)頭編碼規(guī)則值相同的消息體，所以所有8bit
報(bào)頭必須根據(jù)“B”或“Q”編碼方法來轉(zhuǎn)換形式。在ISO8859字符集中，“Q”編碼通常會(huì)
產(chǎn)生一些某種程度上可讀的報(bào)頭。
文檔中應(yīng)該用轉(zhuǎn)換字句:"rfc822-to- 8bit","rfc822-to-base-64"，"rfc822-to-quoted-printable"
添加跟蹤信息。
例如：
來自 dbc.mtview.ca.us   通過 dbc.mtview.ca.us
轉(zhuǎn)換 rfc822-to-8bit,星期二，9月1日，1992年，01：18：00-0700

附錄-“未知8bit字符集“
以下部分定義了一個(gè)“字符集“參數(shù)，用于一個(gè)MIME的內(nèi)容類型字段。
一個(gè)有特殊用途的被稱為“未知8bit“的字符集 被定義為一個(gè)未知的8bit字符集，被
編碼為一系列的8進(jìn)制。它可以在任何語言的任何字符集中被當(dāng)作標(biāo)簽，使用任何編碼方式。
它不能被進(jìn)一步定義。
在一條消息的“charset="字段中，這個(gè)符號(hào)的作用表明關(guān)于字符集的使用一切未知。在
非MIME到MIME的轉(zhuǎn)換中，將計(jì)劃使用這個(gè)標(biāo)簽，尤其在那些從SMTP到8bitESMTP/
MIME的轉(zhuǎn)換中。
這個(gè)字符集沒有打算被所有郵件的編寫者使用?？梢约俣ㄠ]件的編寫者了解所用的字
符集，并用在[1]中規(guī)定的字符集值標(biāo)記所寫郵件，通過當(dāng)前指定的序號(hào)文檔[6]修正所寫郵
件。
“未知8bit”標(biāo)簽僅計(jì)劃被郵件網(wǎng)關(guān)代理來使用。這個(gè)代理不能決定預(yù)期的字符集的超
波段信息。
未知8bit的解釋由郵件的閱讀者來負(fù)責(zé)?？梢约俣ㄔ谠S多例子中，人類用戶將能夠解
釋信息，選擇一個(gè)適當(dāng)?shù)淖址蝾A(yù)處理機(jī)。

致謝
本文檔起源于Ned Freed, Neil Katin和本作者的一次非正式談話。Jonathan Laventhol, 
Craig Everhart, Olle Jarnefors, and Olafur Gudmundsson接受了主要的意見。本文檔用
IETFSMTP擴(kuò)展工作組中許多成員的意見重新修訂而成。

參考

   [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1341, Bellcore, Innosoft, June 1992.

   [2] Moore, K., "Representation of Non-ASCII Text in Internet Message
       Headers", RFC 1342, University of Tennessee, June 1992.

   [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
       Nations University, Innosoft International, Inc., Dover Beach
       Consulting, Inc., Network Management Associates, Inc., The Branch
       Office, February 1993.

   [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
       E., and D. Crocker, "SMTP Service Extensions for 8bit
       MIMEtransport", RFC 1426, United Nations University, Innosoft
       International, Inc., Dover Beach Consulting, Inc., Network
       Management Associates, Inc., The Branch Office, February 1993.

   [5] Coded Character Set--7-Bit American Standard Code for Information
       Interchange, ANSI X3.4-1986.

   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

安全考慮
     本備忘錄中未討論安全問題。

作者地址
    Greg Vaudreuil




Internet郵件從Just-Send-8到8bit-SMTP/MIME的轉(zhuǎn)換
RFC1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME


1