收到远方友人的电子邮件，当然是一件令人高兴的事，但当你满怀欣喜地打开的时候，面对的却是一堆乱码，扫兴之余更是着急。想必这样的情形每一个上网的用户都曾遇到过。的确，电子邮件的乱码问题是困扰中文电子邮件用户一件头疼的事，但并非每个用户都知道如何解决这个问题。下面笔者就从三个方面对E-mail 乱码问题进行一下探讨，同时提出具体的解决办法。

电子邮件软件常用的编码方式及判别方法

要解决电子邮件乱码的问题，我们很有必要了解一下电子邮件是如何进行编码的，以便可以“对症下药”，尽快解决问题。我们知道，由于历史原因，E-mail 只允许传送字符，而且是7位字符的E-mail 网关时，毫无疑问地会出现问题。这些7位的E-mail 网关把汉字内码第8位的1全部变成了0，于是形成了一些不可读的文字。好在现在越来越多的E-mail 网关已能处理8位字符，国内更是如此。所以，直接传送中文问题不大，但是要和国外的朋友通信就另当别论了，本文后面详述。

为了解决E-mail 传输8位字符以及二进制文件的问题，出现了各种各样的编码方式，概括地说，可分为对E-mail 正文的编码和对E-mail 附带文件的编码两类。对E-mail 正文的编码有Usenet 上专门针对中文的HZ 码等，对E-mail 附带文件的编码则有UUENCODE，BINBEX 等。而在Internet 上标准的编码方式却是MIME(Multi -purpose Internet Mail Exten—sions 多用途Internet 邮件扩展)，它对E-mail 传送多媒体信息(诸如声音、图像、二进制文件等)进行了一系列详细而复杂的定义，包括了对E-mail 正文的编码和对E-mail 的附带文件的编码。现在绝大多数的电子邮件软件如ENDORA、Foxmail、THE-BAT！等都支持MIME 编码方式。

纯中文方式编码：这就是我们通常看到的一般文本，没有经过任何编码，任何软件都能准确识别，因而不会出现任何乱码(在指定了正确的字符集后)。

UUENCODE 编码：一些较老的邮件服务器上这种编码使用较多，目前的Ftp Mail 等服务器也是使用此编码(如Mr—Cool 下载的文件等)。UUENCODE 编码的主要特征是编码首行由BeginXXX 开始，结束一行为End ，且通常其中的每一行的开始均为“M”，只要有了以上几个特征，就能确定是UUEN—CODE 编码。

QUOTED -PRINTABLE 编码：该种编码是将7FH以上的ASCII 字符(即汉字)用它对应的文字串表达出来，即如一个ASCII 编码为0ABH 的字符，将用=AB 来代表它。它的典型特征是文本中有大量的这种用“=”来构成的符号，即=XX=XX=XX 等，只要有这种符号，即可确认。

BASE64编码：BASE64 编码的判断较复杂，但它也有一个明显的特征，由于BASE64是通过“=”来实现行对齐，因而假如你在一个排列非常规则(每行字符数相同，一般为63 个)，没有任何可识别内容的编码，且若最后一行未满并有一至三个“=”之类字符时即可确认它是BASE64编码；特别的一点是，“.”不属于BASE64 编码后的字符，也就是说一个用BAS64正确编码后的信件将决不可能在信体部分有“.”出现，否则就是误编码。

HZ 编码：这是国外的中国人发明的一种编码方式，它把汉字的最高位去掉，然后用一特定符号来表明哪些编码经过了处理。这种编码也极易识别：在它信的内容中通常会有这样的一组符号：“～{”和“}～”，其中的内容是不可读的(乱码)，而在这一组分界符外的都是可读的英文字符。

Bit7码：这并非一种编码，而是网络传输误码。它是由于网络不支持8位传输引起的，通常在局域网的接入方案中较为常见。它跟HZ 编码类似，只是没有标明哪些内容是截去了最高位的，识别办法跟HZ 类似，如果一段信件中英文部分是正常的话，即为此种误码。该种误码无法解码，只能要求对方用7位编码(如以上的各种编码)重新发送。

由此可见，我们一旦知道了邮件的编码方式后，就可以使用相对应的解码软件将其解开。


E-mail 出现乱码的最根本原因就在于：编码与解码方式的不一致。当你收到一封充满乱码的E-mail 时怎么办呢？自己如何动手进行解决呢？下面我们来分析一下这方面的原因及解决方法。

E-mail 乱码的种类、产生原因及解决方法

1、中文内码不一致的“乱码”，最为常见的是BIG5码与GB码

现象：信件内容有空格、日文、偏旁部首、个别汉字等等。

原因：这种“乱码”是由于发信的计算机的中文内码不是国标码(GB)所造成的，如香港、台湾地区和海外使用的汉字系统多数是BIG5码。如果用此内码发送中文信件，国内使用的国标码的用户阅读时就会出现“乱码”现象。

解决方法一：在系统上加挂多内码语言显示平台，如四通利方的RichWin97(http ：//www.srsnet .com)、南极星1.60(http ：//www.njstar .com)、Magic Win98(http ：//www.jtwin .coom.my/magicein)及两岸通都是不错的选择。
解决方法二：选用支持BIG5码与GB码转换功能的E-mail 软件，如Fox—mail、方正飞扬等，缺点是有时效果不是很理想。

2、部分乱码

现象：收到的邮件中有的句子能正常显示，但是有的句子仍出现“乱码”。

原因一：发信人在输入汉字时不留意输入了某个控制键或者折行不正确，产生半个汉字的现象。众所周知，在计算机里，汉字是由两个字节组成的，如果不正确地折行，前一行最后一个字的前半部分留在本行，而后半部分则被折到了下一行。结果，后半部分与后面一个字的前半部分组成了一个新的汉字，如此类推，于是，整行汉字就成了天书。

解决方法：将邮件保存，用Word、WPS97等文字处理软件在汉字与乱码之间插入一个空格或者删除一个“乱码”字符。这样，邮件内容虽然少了一个字，但剩下的部分恢复正常，况且我们凭上下文也可基本猜到这个字了。

原因二：E-mail 软件(尤其是英文软件)以及邮件传输过程中也可能造成这种不正常的折行。英文E-mail 软件的自动折行是依据英文单词间的空格来判断的，但中文却没有空格。因此，E-mail 软件在进行折行处理时，出错就在所难免了。而在E-mail 的传输过程中，E-mail 网关对长行的处理方法也不尽相同，有时会使行末的半个汉字丢失，从而造成了半汉字现象。

解决方法：要彻底解决这个问题，最好是在每个汉字后加入空格，也就是利用汉字输入法字间加空的功能，这样就不会出现错误的折行了。现在的中文系统如RichWin 等，都提供了字间加空的选择。

原因三：有时汉字系统调用出错也会造成这种乱码，盗版的汉字平台出现这种方面问题的概率较高。

解决方法：使用正版软件，或者将系统内码先改为BIG5，这时看到全文“乱码”，再将内码改为国标码即可；或者重新调用汉字系统。

3、附件采用MIME 格式的“乱码”

现象：看到的信件内容全是大小写英文字母而且字符排列很整齐。

原因：之所以造成这种“乱码”，原因是发信人的E-mail 软件设置中使用的不全是8位格式，而且MIME 格式所造成的。

解决方法：将自己的E-mail 软件的附件格式设置成MIME 格式再阅读信件。

4、七位码的中文“乱码”

现象：看到的信件内容全是大小写英文字母中间还有西文大括号。

原因：发信者的E-mail 软件设置中使用的是7位格式。

解决方法：通知对方重发邮件。

5、UNEDCODE 类型的“乱码”

说明：其实，严格来说不能将其称为乱码，但是许多网友(尤其是一些网上新手)在面对这俨如天书的UNENCODE 编码的邮件时，往往无所适从，所以在此笔者也把它归为“乱码”了。

原因：时下，许多网友喜欢用Mr .COOL“下载”软件，或者中间通过E-mail 索取软件，而这些FTP Mail 服务器采用的是UNEDCODE 编码，所以接到的邮件就是一些文不成书的怪字符了。

解决方法一：选用支持UNENCODE解码功能的E-mail 软件，如ENDORA、THEBAT！等；

解决方法二：用Wincode、WinZip6.3等软件解码。对于拆分的邮件必须分别保存，然后将它们用DOS 的Copy 命令合成为一个以*.uu 为扩展名的文件，具体操作如下：copy 文件1+文件2+…文件N 文件名.uu ，然后再用上述软件解码即可。

6、非上述原因造成的“乱码”

现象：邮件的全文皆为乱码。

原因：E-mail 软件或邮件传输出错所造成的。这种问题出现的概率不是很高，但是在目前情况下仍然存在。比如，文件太长造成文件的丢失或少了一截，你的ISP 的收发邮件的服务器出现故障等等。

解决方法：如果是发信人E-mail 软件的问题，你可以请对方重新调整或更换一个E-mail 软件。至于诸如服务器故障之类的原因，就不是用户所能处理的了，最好咨询一下你的ISP，等故障排除后，请对方重发一次。


如何向海外的朋友发送中文E-mail

方法一：这是最简单、最直接的办法：要求对方使用简体中文Windows ，或者至少加挂一个多内码语言平台，如Rich—Win97、南极星等。但是，很显然，这种方法不太可行。

方法二：将汉字文本转换成图形，在电子邮件程序中以附件的形式发送，具体可以采取以下两种方法：

1、在Windows 的“画图”程序(Brush)中输入信件的内容，然后存成一个BMP等格式的图像文件；
2、用普通的文本编辑软件(如Win—dows 下的记事本、写字板、Word 等)输入信件内容，然后用HyperSnap 等截图软件保存为图像文件。

方法三：用TXT2EXE 等软件将信件的内容制成一个可执行文件，以附件的形式发送给对方。

该文章在 2012/2/17 0:15:16 编辑过