遇到亂碼郵件，首先要判斷產生的原因。
出現亂碼的原因很多，其中一種可能是由于Internet上的某些郵件主機不支持8位（非ASCII碼格式）傳輸造成的。具體的說，在直接發送中文雙字
節或二進制等非ASCII碼格式的郵件（如中文雙字節文件、圖片文件.jpg、可執行文件.exe或壓縮文件.zip等二進制文件）時，郵件主機無法處
理，便把信件中每個字符的第八位都過濾掉（截去第八位），從而使此信息和初始信息截然不同，造成郵件信息的失真或損壞。因此，在發送8位格式的文本文件
時，必須事先進行編碼，將文件轉換為7位ASCII碼或更少位數的格式，然后才能保證文件的正確傳送。收件人收到7位或更少位格式的郵件之后，可以再轉換
為8位的格式，這樣就可以閱讀了。
一般電子郵件系統的“附件”功能可以自動對信件先進行編碼，
然后送出。而如果收信人的電子郵件系統（如Netscape Email、Pegasus、Eudora、Accacia、MS Internet
Mail等)能夠區別信件的編碼方式，則可以自動將信件解碼。然而由于各種電子郵件軟件的默認配置不同，收件人和發件人自己定制的一些選項也會各不相同，
所以在收到編碼的信件后，系統不一定能識別出信件所用的編碼方法。識別不出編碼方法，系統自然無法自動解碼，這樣當你查看信件內容時，就會出現所謂的亂
碼，使收信人無法閱讀該文件。
其次，就是要判斷關鍵字符，去判斷其編碼方法。
不同的亂碼，在不同的平臺上有不同的解決方法，因此解碼前必須先看一下文件的內容，根據特征對文件可能的編碼方式（Uuencode、Base64
encode、QP－encode或其它編碼方式）進行判斷。請注意，Uuencode格式與Base64
encode格式非常相似，它們的差別僅僅在于“信頭”部分的不同。
第一種編碼方法：Uuencode這是很早以前在UNIX上就有的編碼程序，主要用戶都集中在UNIX環境的使用者中，目前使用者已經很少。這種軟件內部所用的算法為base64。其大體格式為：
begin 644 kk.zip
M1G)O;2!I;&EN＋F)B3T!C(VEE＋FYC=’4N961U＋G1W(%=E9"!.;W8@(#8@,3(ZM,SDZ,
C4@,3DY－@I296－E:79E9#H@9G)O;2!F;&%B;6%I;"YF;&%B＋F9U:
FET……………..
end
說明：
在亂碼前面含有“begin xxx”，后面緊接著編碼之前原始文件的名稱，接著是已經過編碼的信件的內容，在亂碼內容后面，即最后一行為“end”。
第二種編碼方法：BASE64
encode這種編碼方式是將3個字節（8位）用4個字節（6位）表示，由于編碼后的內容是6位的，因此可以避免第8位被截掉，其大體格式為：
MIME－Version：1.0
Content－Type：text/plain; charset="us－ascii"
Content－Transfer－Encoding:base64
Status：R
SGmhQbF6pm6hSafapmK69Lj0pFexb6q＋sXqsT6Skp
OWrSKXzsN3DRLFNrmGhQQ0Kq1＋sTqq6vdCx<BR>
0LF6tFit07Ddw0ShRw0KDQqtuqX9p2m2RLF6p9qoz6XOIE
1Py3Jvc29mdCuiBJbnRlcm5ldCBN……
說明：
Base64編碼信件的亂碼前一般有如下幾部分“信頭”：Content－Type(內容類型)、charset(字符集)及Content－Transfer－Encoding(內容傳輸亂碼方式)，判斷的依據比較明顯。
第三種編碼方法：QpencodeQP編碼全名為“Quoted－Printable
Content－Transfer－Encoding”。由于用這種格式表示的信息，其內容主要都是ASCII字符集中可以打印的字符，因此名稱中含有printable。其大體格式為：
=A1A=B1z=A6n=A1I=A7=DA=A6b=BA=F4=B8=F4=A4W=B1o……
=E5==ABH=A5=F3=B0=DD=C3D=B1M=Aea=A1A……
說明：
采用QP（Quoted－Printable）編碼方式的信件很容易進行判別，因為它的內容通常有很多等號“=”，因此不需要看“信頭”也可以判斷是否為QP編碼。
第三，根據所用的操作系統選擇相應的軟件程序，然后進行解碼。
判斷出亂碼信件的編碼方法后，再根據自己所擁有的軟件種類，選取合適的解碼軟件。由于不同平臺上不同的軟件程序使用方法差別很大，作者無法在此一一說
明，只能由讀者自己參照程序附帶的Help、Readme等文件的說明，自行對亂碼郵件進行解碼。這里著重介紹DOS和Windows下的編
/解碼程序的大體優缺點，供讀者下載程序時參考。
如果嘗試過上述步驟后仍然無法解決問題，則可能有另外的原因：
1.該郵件采用了其它的編碼方法，如Binhex或XXencode編碼等。只要亂碼前面有“信頭”信息（一般顯示了該郵件所用的編碼方式），即可用Xferp111或其它“智能型”Windows程序將其解碼。
2.是否在中文環境內。如果你所用的操作系統是英文環境，而你又沒有外掛中文系統（如中文之星）或未切換為中文（如RICHWIN四通利方或南極星等）
編碼方式，則你自然看不到中文，而只能看到亂碼。注意，雙字節字符有中文簡/繁體的GB和BIG5碼及日文的JIS、EUC和朝鮮文的KSC碼等，在GB
碼環境下看其他雙字節字符時也只能看到亂碼。
3.一封郵件的內容中第8位字節被濾掉了。這種情況下的郵件幾乎無法還原。
總之，如果上述措施都難以解決問題的話，只好請教發件人了。
為了盡量避免出現亂碼問題，下面給出幾點建議：
1.利用“附件”功能發送文件
使用Netscape、Eudora或Pegasus等郵件系統附加這類非標準ASCII碼格式的文件時，附加文件通常可以自動進行“base64”
方式編碼（僅對附件部分進行編碼）。在用“附件”方式發送郵件之前，無需進行編碼；如果編碼的話，將會給解碼帶來很多麻煩，意即收件人必須再一次進行解
碼。一般來說收件人都可以成功解碼這類“附加”文件，因此強烈建議你采用這種方法發送中文類郵件。
2.如果無法以附件方式發送文件，則必須在正文中發送中文或二進制文件。
如果發/收件人之間遠隔萬里，如在中國和美國之間，則傳送過程中，第八位將可能被截掉。這時最好先在正文中用中文給收件人發一封測試信，并了解對方能
否正確收到郵件正文。如果第八位被截掉，則收件人將會看到一些亂碼，而不是上述的uu/b64/Qp等格式，而且這種信件幾乎不可恢復。這種情況的解決方
案是，在Netscape、Eudora或Pegasus Mail等你所使用的郵件系統中，選擇其首選項或選項配置中的“Quoted
Printalbe”或“MIME encoding”。
3.發送重要信息時先發測試信
發送重要信息時，為了確認是否無須編碼即可發送正文，應該先發送測試信。而且還應確定收件人能否對附件文件進行解碼。如果發送已經編碼的郵件，則最好
添加足夠的“信頭”信息，以便收件人知道所需的解碼方法。建議對uuencode/UUDeview編碼方式用uuencoding作信頭，對mpack
編碼方式用base64 encoding作信頭。
400 186 1886
