遇到亂碼郵件，首先要判斷產(chǎn)生的原因。

出現(xiàn)亂碼的原因很多，其中一種可能是由于Internet上的某些郵件主機(jī)不支持8位（非ASCII碼格式）傳輸造成的。具體的說，在直接發(fā)送中文雙字
節(jié)或二進(jìn)制等非ASCII碼格式的郵件（如中文雙字節(jié)文件、圖片文件.jpg、可執(zhí)行文件.exe或壓縮文件.zip等二進(jìn)制文件）時(shí)，郵件主機(jī)無法處
理，便把信件中每個(gè)字符的第八位都過濾掉（截去第八位），從而使此信息和初始信息截然不同，造成郵件信息的失真或損壞。因此，在發(fā)送8位格式的文本文件
時(shí)，必須事先進(jìn)行編碼，將文件轉(zhuǎn)換為7位ASCII碼或更少位數(shù)的格式，然后才能保證文件的正確傳送。收件人收到7位或更少位格式的郵件之后，可以再轉(zhuǎn)換
為8位的格式，這樣就可以閱讀了。

一般電子郵件系統(tǒng)的“附件”功能可以自動(dòng)對(duì)信件先進(jìn)行編碼，
然后送出。而如果收信人的電子郵件系統(tǒng)（如Netscape Email、Pegasus、Eudora、Accacia、MS Internet
Mail等)能夠區(qū)別信件的編碼方式，則可以自動(dòng)將信件解碼。然而由于各種電子郵件軟件的默認(rèn)配置不同，收件人和發(fā)件人自己定制的一些選項(xiàng)也會(huì)各不相同，
所以在收到編碼的信件后，系統(tǒng)不一定能識(shí)別出信件所用的編碼方法。識(shí)別不出編碼方法，系統(tǒng)自然無法自動(dòng)解碼，這樣當(dāng)你查看信件內(nèi)容時(shí)，就會(huì)出現(xiàn)所謂的亂
碼，使收信人無法閱讀該文件。

其次，就是要判斷關(guān)鍵字符，去判斷其編碼方法。
不同的亂碼，在不同的平臺(tái)上有不同的解決方法，因此解碼前必須先看一下文件的內(nèi)容，根據(jù)特征對(duì)文件可能的編碼方式（Uuencode、Base64
encode、QP－encode或其它編碼方式）進(jìn)行判斷。請注意，Uuencode格式與Base64
encode格式非常相似，它們的差別僅僅在于“信頭”部分的不同。

第一種編碼方法：Uuencode這是很早以前在UNIX上就有的編碼程序，主要用戶都集中在UNIX環(huán)境的使用者中，目前使用者已經(jīng)很少。這種軟件內(nèi)部所用的算法為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”，后面緊接著編碼之前原始文件的名稱，接著是已經(jīng)過編碼的信件的內(nèi)容，在亂碼內(nèi)容后面，即最后一行為“end”。

第二種編碼方法：BASE64
encode這種編碼方式是將3個(gè)字節(jié)（8位）用4個(gè)字節(jié)（6位）表示，由于編碼后的內(nèi)容是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(內(nèi)容類型)、charset(字符集)及Content－Transfer－Encoding(內(nèi)容傳輸亂碼方式)，判斷的依據(jù)比較明顯。

第三種編碼方法：QpencodeQP編碼全名為“Quoted－Printable
Content－Transfer－Encoding”。由于用這種格式表示的信息，其內(nèi)容主要都是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）編碼方式的信件很容易進(jìn)行判別，因?yàn)樗膬?nèi)容通常有很多等號(hào)“=”，因此不需要看“信頭”也可以判斷是否為QP編碼。

第三，根據(jù)所用的操作系統(tǒng)選擇相應(yīng)的軟件程序，然后進(jìn)行解碼。

判斷出亂碼信件的編碼方法后，再根據(jù)自己所擁有的軟件種類，選取合適的解碼軟件。由于不同平臺(tái)上不同的軟件程序使用方法差別很大，作者無法在此一一說
明，只能由讀者自己參照程序附帶的Help、Readme等文件的說明，自行對(duì)亂碼郵件進(jìn)行解碼。這里著重介紹DOS和Windows下的編
/解碼程序的大體優(yōu)缺點(diǎn)，供讀者下載程序時(shí)參考。

如果嘗試過上述步驟后仍然無法解決問題，則可能有另外的原因：

1.該郵件采用了其它的編碼方法，如Binhex或XXencode編碼等。只要亂碼前面有“信頭”信息（一般顯示了該郵件所用的編碼方式），即可用Xferp111或其它“智能型”Windows程序?qū)⑵浣獯a。

2.是否在中文環(huán)境內(nèi)。如果你所用的操作系統(tǒng)是英文環(huán)境，而你又沒有外掛中文系統(tǒng)（如中文之星）或未切換為中文（如RICHWIN四通利方或南極星等）
編碼方式，則你自然看不到中文，而只能看到亂碼。注意，雙字節(jié)字符有中文簡/繁體的GB和BIG5碼及日文的JIS、EUC和朝鮮文的KSC碼等，在GB
碼環(huán)境下看其他雙字節(jié)字符時(shí)也只能看到亂碼。

3.一封郵件的內(nèi)容中第8位字節(jié)被濾掉了。這種情況下的郵件幾乎無法還原。

總之，如果上述措施都難以解決問題的話，只好請教發(fā)件人了。

為了盡量避免出現(xiàn)亂碼問題，下面給出幾點(diǎn)建議：

1.利用“附件”功能發(fā)送文件
使用Netscape、Eudora或Pegasus等郵件系統(tǒng)附加這類非標(biāo)準(zhǔn)ASCII碼格式的文件時(shí)，附加文件通?？梢宰詣?dòng)進(jìn)行“base64”
方式編碼（僅對(duì)附件部分進(jìn)行編碼）。在用“附件”方式發(fā)送郵件之前，無需進(jìn)行編碼；如果編碼的話，將會(huì)給解碼帶來很多麻煩，意即收件人必須再一次進(jìn)行解
碼。一般來說收件人都可以成功解碼這類“附加”文件，因此強(qiáng)烈建議你采用這種方法發(fā)送中文類郵件。

2.如果無法以附件方式發(fā)送文件，則必須在正文中發(fā)送中文或二進(jìn)制文件。
如果發(fā)/收件人之間遠(yuǎn)隔萬里，如在中國和美國之間，則傳送過程中，第八位將可能被截掉。這時(shí)最好先在正文中用中文給收件人發(fā)一封測試信，并了解對(duì)方能
否正確收到郵件正文。如果第八位被截掉，則收件人將會(huì)看到一些亂碼，而不是上述的uu/b64/Qp等格式，而且這種信件幾乎不可恢復(fù)。這種情況的解決方
案是，在Netscape、Eudora或Pegasus Mail等你所使用的郵件系統(tǒng)中，選擇其首選項(xiàng)或選項(xiàng)配置中的“Quoted
Printalbe”或“MIME encoding”。

3.發(fā)送重要信息時(shí)先發(fā)測試信
發(fā)送重要信息時(shí)，為了確認(rèn)是否無須編碼即可發(fā)送正文，應(yīng)該先發(fā)送測試信。而且還應(yīng)確定收件人能否對(duì)附件文件進(jìn)行解碼。如果發(fā)送已經(jīng)編碼的郵件，則最好
添加足夠的“信頭”信息，以便收件人知道所需的解碼方法。建議對(duì)uuencode/UUDeview編碼方式用uuencoding作信頭，對(duì)mpack
編碼方式用base64 encoding作信頭。