邮件乱码破解完全手册（上） 袁宁 2000年 第53期 随着Internet的普及，在网上通过E-mail传递信息逐渐成为现代人生活的时尚，相信不久甚至还会成为一种生活的必需内容。但我们在接收电子邮件的时候，不时会发现接收的邮件是些怪模怪样的乱码，根本无法阅读。如果这些邮件的内容并不很重要，可能还不会有太大影响，可是假如是些紧急事件的通知或是生意场上的公函，则很可能就会给你带来不小的损失。遇到这种情况，你打算怎么办呢？把邮件丢进垃圾筒就当没收到，麻烦发信人再重发一次，还是自己找方法破译？ 我们知道，计算机以及很多计算机网络协议的制定都是建立在ASCII码（美国国家标准信息交换码，它是一种最基本的字符表示方法）基础上的，但是随着信息内容的日益丰富，用ASCII码表示计算机信息开始暴露出很大的不足，这主要表现在表示多国文字、图形、声音等二进制文件和信息压缩、信息保密等诸多方面。因此，在ASCII码和扩展ASCII码的基础上，用一定的规则定义一些新的信息表达形式就形成了信息传输和处理中的另一类概念和事物，这就是“编码”和“解码”。当信息编码和解码能够统一的时候，信息无疑是可以交换和被理解的；反之，当信息编码和解码不能够得到统一的时候，信息就无法被用于交换和理解，于是就产生了所谓的“乱码”。 既然乱码的产生是由于信息编码和解码不能够得到统一，那么解决乱码的过程自然就是找到和编码相统一的解码方法，并对计算机软件不能全自动进行正确解码的信息进行重新处理和解码，最终使得所恢复的信息能被人们理解和交换，这就是所谓的“破解”。 可以说，常见的乱码都有这样一些共性：（1）和汉字或其他语种的文字有关；（2）最常发生在电子邮件的传输和阅读中；（3）和传送二进制文件有关；（4）和信息加密解密、编码解码有关。而我们今天要讨论的电子邮件乱码的原因也正如前面所说，和相应的邮件发送系统、电子邮件软件以及操作系统平台本身，即它们用来自动识别和编码解码的协议规则，有着极为密切的关系。 本文以目前最常使用的电子邮件软件Outlook Express和Foxmail为例（其它电子邮件软件有所提及），尽可能给出常见乱码的乱码原因、乱码现象、标志格式和解决方案，并为你提供一套经典的破解流程作为参考，只是希望对你破解邮件乱码DIY能有些许帮助。 #1 一、乱码产生之来龙去脉篇 #1 （一）邮件乱码产生的原因 事实上造成邮件乱码的具体原因是很多的，但最为常见的不外乎有三种情况： 1.传输机制不同 由于Internet上的某些邮件服务器（国外居多）不支持8位（非标准ASCII码格式）的中文邮件传输，所以在它们之间传输邮件就会产生乱码。 具体来讲，这是因为Internet邮件协议是在1982年定义的，当时的邮件基本上只由英语文本组成，而没有其它文件格式，因此当时定义的邮件协议普遍只支持简单的ASCII码文本（对DOS、Windows及Unix操作系统来说，所有英文字母及符号都是用ASCII码来表示的，而ASCII码只用到每个字节8位中的前7位）。这样，为了支持国际上流行的邮件协议，Internet上不少邮件系统相应只支持7位的ASCII码字符传输方式在当时看来也就顺理成章。但非常不巧的是，由于汉字的内码是8位的（一个汉字是用两个扩展ASCII码表示的），所以当在电子邮件系统之间传送中文信息时，如果没有经过那些只支持7位的邮件系统（比如在国内的邮件系统间传输），自然可以正确的识别中文；但如果恰好经过了那些只支持7位字符的邮件系统（即使只有一台这样不支持8位传输条件的主机，中文邮件都可能被破坏），它们会硬把8位数据当作7位来处理，将汉字内码第8位的1全部变为0，这当然就使邮件内容立刻变得面目全非起来。 除了中文双字节邮件外，如果通过E-mail传送一些非ASCII码格式的文件（如.jpg、.exe、.zip）也会由于主机无法处理，而把信件中的每个字符的第8位都滤掉（即截去第8位），从而使信息和原始信息截然不同，造成邮件的完全损坏。这样的乱码当然就无法阅读了。由于传输机制不同造成邮件乱码的现象是邮件乱码产生的主要原因之一。 2.邮件编码不同 为了解决传输机制不同造成的邮件乱码，现在国际上普遍在电子邮件中采用各种邮件编码方式，即将8位的文件格式预先按照一定的规则进行编码，以使它可以完好地通过只支持7位字符的邮件传输系统。通过对邮件进行7位编码再进行传输和解码可以一定程度的解决截位乱码的现象。 为了能既克服传输机制不同造成的中文或非ASCII码格式传输错误，又不违背当初的协议标准，现在普遍采用的编码方法是在邮件信息中转换要传递的二进制数据。我们把二进制数据转换为文本数据称作编码（encode），反之则称为解码（decode）。但问题是由于目前的编码标准有很多，如UU、MIME、BINHEX编码等等，如果收发双方都使用同一种编码/解码方式，那邮件传送自然不会有任何的问题，然而，如果发送方采用一种方式，而接受方不能正确的识别出这种编码方法，无疑就会出现乱码。此外，有的邮件在传输过程中还可能被邮件系统进行过特别的处理，当然也可能对数据进行了某种特别的编码，但我们在接收的时候怎么能自动的知道它到底经过了哪些处理呢？这样的话，由于邮件编码不同造成乱码现象看来也就不足为奇了。 需要说明的是，由于在我国大陆地区，国标码GB2312码是通用的的简体中文内码，所以国内通行的绝大多数邮件系统都能够完全支持GB（国标码）内码的邮件，故而在国内邮件系统内传输电子邮件可以直接传送而不需要再进行任何编码。 3.电子邮件软件或操作系统不同 　 一般情况下，各种电子邮件软件的默认设置是不相同的，除此之外，收件人和发件人在电子邮件软件的自定义中的设定肯定也不尽相同，这无形中就为邮件乱码的产生创造了条件。如果发送方用某种编码方式发送了邮件，而接收方所持有的电子邮件软件对编码的设置与邮件编码不同，这样极有可能发生的情况是：电子邮件软件在收到编码过的信件后不能“自动”识别其编码方式，从而造成在查看信件的内容时出现所谓的乱码，我们自然无法阅读。此外，假如接收方所持有的电子邮件软件没有对应的解码功能，或者收发双方用的是两种支持不同编码的邮件软件，也同样可能造成无法正常阅读的错误。还有一种情况是，发送方从其他系统中转发了编码过的邮件内容给接收方，但接收的电子邮件软件只能将原编码过的内容原封不动的显示出来，而不能继续将这种“乱码”再进一步的智能转换为我们能阅读的文字。 与电子邮件软件的影响相似，由于各个国家、各个地区可能使用不同的操作系统（包括同一种操作系统的高低级版本、中英文版本），往往会在阅读邮件（还有网页）时看到所谓的“乱码”。如对于不同的汉字编码，中国大陆用GB码、中国台湾用Big5码和HZ码、港澳特区有用GB码，也有用Big5码的，由于操作系统汉字内码的差异，在收发邮件时遭遇到乱码也就不算奇怪了。 #1 （二）E-mail中常见的编码标准 如上面我们所谈到的那样，现在传送电子邮件的关键在于编码。只有经过编码，中文或非ASCII码格式的邮件才能正确通过Internet上那些不支持8位编码的邮件系统；只有电子邮件软件都完全支持，而且能正确识别编码的类别，电子邮件的内容才能为我们所阅读和理解。那么，在电子邮件系统中究竟有哪些编码标准呢？目前在E-mail中一般常用的编码标准有UU、MIME和BINHEX编码三种，其中MIME编码是目前应用最广泛的编码。下面我们就来详细了解一下这几种编码： 1.UU编码（Unix-to-Unix encoding） 　 这是邮件传输早期传送非ASCII码文件时最常使用的编码方式，它主要使用在Unix环境下（邮件系统大多都建立在Unix操作系统上），但目前使用者已经越来越少。UU编码实际上由Uuencode和Uudecode两部分组成，它们分别是Unix系统下的UU编码和解码程序，但其内部所用算法却是MIME编码中Base64编码的算法，后来被改写成为在DOS下运行的可执行程序。 UU编码传输邮件的原理是：在进行邮件发送前，先在DOS方式下用Uuencode.exe程序将原文件编码成ASCII码文件，然后再进行发送，而收件人在接到文件后只需用Uudecode.exe程序将文件还原即可。此外，UU编码并非只能对中文邮件进行编码，只要你寄出的文件包括.gif、.jpg、.exe、.zip等二进制文件，它都能按照编码、发送、收信、解码还原的步骤来予以传送。这种编码方法现在虽已经不很常用了，但Outlook Express、Foxmail等绝大多数电子邮件软件都支持它。 需要指出的是，UU编码是DOS系统下的编解码程序，在Windows系统中与之对应的编解码程序是Wincode（Winzip也采用了相似的原理）。事实上，Wincode的使用原理同DOS下的Uuencode和Uudecode相同，只不过它是利用了Windows的界面，从而使相应的操作方式更为简便和灵活。值得注意的是，Wincode程序除了支持UU编码外，还支持MIME、BINHEX等多种编码格式，故而应用范围相当广泛。 2.MIME编码（Multipurpose Internet Mail Extentions） 　虽然UU编码也能解决E-mail传送中文或非ASCII码文件的问题，但它的编解码方式在现在看来非常不方便，这就促使了MIME编码标准的产生。Mimencode最早被称为Mmencode，之所以提出用Mimencode代替Uuencode，是因为Uuencode编码使用的一些字符在一些邮件网关（特别是那些转换ASCII码和EBCDIC码的网关）中会造成传输障碍。另外，还有一些电子邮件软件不能对所有Uuencode码的算法进行正确解码而导致邮件的阅读困难，因此MIME编码就被设计用来替代Uuencode编码，但历史的结果是这些编码协议得到了共存。 MIME编码一般被译作“多媒体邮件传送模式”，它是可以传送多媒体文件，并在一封电子邮件中附加各种格式文件一起发送的编码标准。我们现在最常使用的电子邮件软件Outlook Express、Eudora、Foxmail和一些网上在线邮局如163、263等都是采用MIME编码方式的，所以我们得以非常轻松的收发电子邮件。 由于MIME定义的是一种编码规格，或者可以说只是一类编码的统称，所以能够符合MIME标准的编码方式并非只有一种。事实上只要符合MIME规格的编码方式都能顺利的传送邮件。目前在MIME编码标准下公认的两种编码方式分别是Base64编码和QP（Quote-Printable）编码。另外，Internet上还有几种种编码是HZ编码、UTF-7编码和UTF-8编码。 （1）Base64编码 Base64的编码规则是将整个文件重新编码成7位以适用于传送二进制文件。具体来说是将字符流顺序放入一个24位的缓冲区（缺字符的地方就补零），然后再将缓冲区截断成为4个部分（高位在前），每个部分6位，并用下面的64个字符重新表示：“ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/”。如果输入只有一个或两个字节，那么输出将用等号“=”补足，这样的编码方式可以有效隔断附加信息对编码造成的混乱。这就是Base64编码。 （2）QP（Quote-Printable）编码 QP编码的规则是，对于资料中的7位字符不作重新编码，而是仅将8位的数据转成7位即可。我们可以看到，QP编码是字符对应的编码，每个未编码的二进制字符都会被编码成3个字符，即一个等号加上两个该字符的16进制值，如“=A8”，但这样的编码数为1:3，所以编码效率相对于其它编码方式而言相当低。但不可否认的是，这种编码方法非常简单，特别适合那些数据大多数是7位的ASCII码文本、偶尔插入8位字母的情况，但遗憾的是对汉字编码效果不够好，因为每个双字节汉字经过编码后会变成6个字节。 （3）HZ编码 HZ编码也是一种Internet上常见的编码方式，它的编码规则是只对高位为1的字符（如汉字的双字节内码）进行编码。具体方法是将最高位屏蔽，只保留低7位，并将经过变换后的字符部分用符号~{和~}括起来，当解码的时候只需将括号对里面的那部分高位重置为1就可以正确的加以还原了。 　 需要特别指出的是，MIME编码标准如今已成为Internet电子邮件的主流编码标准。它的好处显而易见：我们可以物件作为包装方式，然后将多种不同文件一起打包后传送。发信人只要将欲发送的文件选定好，MIME编码就会在传送时即时编码，待收信人收取邮件后同样也能即时解码还原这些文件。可以看得出来，这种全部由电子邮件软件自动完成的传送方式较UU编码方式来说，实在是方便不少。当然，这种邮件传送方式成功的先决条件是双方的邮件软件都必须支持MIME编码功能，要不然发信人很方便的把信送出去了，但收信人的软件却没有这种功能而无法把它还原，他看到的自然就是一大堆乱码了。要知道，使用这种方式用户根本不需要知道它是如何进行编码解码的，不管是用中文写信，还是寄多媒体文件，只要选好文件，选完后寄出，其余的工作可全部由电子邮件软件自动完成。 由于MIME编码的这种便利性、可靠性，现在越来越多的电子邮件（几乎所有）都采用了这种编码方式，像我们国内用户最常使用的电子邮件软件Outlook Express、FoxMail、Eudora、The Bat！、Netscape Mail和Internet Mail等都支持MIME编码标准。一般来说，MIME编码中具体方式的选择也会影响编码之后邮件文件的大小，但具有MIME编码功能的E-mail软件大都能自动判别发送过来的邮件是采用何种MIME编码，然后自动选择是用Base64还是用QP来解码。当然，即使是正确的MIME编码也可能因为邮件文本格式的不规范而不能得以正确解码，这个时候，我们从E-mail软件或Hotmail里面得到的Base64编码或QP编码就可能成为乱码，这也是MIME编码产生乱码的主要原因之一。 3.BINHEX编码 　 由于BINHEX的编码方式主要用于Mac机，PC机上很少使用，所以一般PC机上的电子邮件软件多数支持MIME编码标准而很少支持BINHEX格式的。在我们常用的电子邮件软件中，只有Eudora具有这种功能可直接解读BINHEX编码。 4.其它编码 这类编码主要指日文Shift-JIS、日文Shift-EUC、韩文KSC、繁体中文Big5等语言内码，本文主要针对繁体中文Big5码而言。我们知道，由于它们是不同语言环境下的不同语言内码，在通过电子邮件传递的过程中就难免不出现乱码，因此这里将它们归为email中一类比较特别的编码。 特别提示：对于上面提到的四类编码，最新的Foxmail 3.1版支持Uuencode和MIME两种编码，但MIME编码只支持8位（8bit）编码方式（也有称作UTF-8编码的），另外它还支持us-ascii、ISO-8859-1、简体中文GB2312、日文Shift-JIS、韩文KSC、繁体中文Big5等多种字符集。总的来说，它比较适合以纯文本方式传送正文。而Outlook Express 5则支持Uuencode编码和MIME中的Base64以及QP两种编码方式以及UTF-7、UTF-8编码和多国文字字符集，除此之外它还支持邮件正文以HTML方式传送，这就是我们用Outlook Express能看到有着漂亮背景的邮件的原因。另外，我们上面提到的Windows下的Wincode解码程序也能支持Uuencode编码、MIME编码以及Binhex编码，但非常遗憾的是，对于MIME编码，Wincode只能处理Base64的编码，而没有QP编码的功能，实在是有些美中不足。 #1 二、乱码现形之真相大白篇 在以下内容中，我们将下面这段话作为所有乱码对应的简体中文，并存为lm.txt文本，用来分析下面九类乱码的特征与形式： 在人类历史上，从来没有一项技术及其应用像互联网一样发展那么快，对人们的工作、生活、消费和交往方式影响那么大，并且，随着高度信息化的网络社会的到来，人们在生产和生活方式、观念和意识等方面也必然会发生巨大的变化。 #1 1.Uuencode“乱码” 由于Uuencode编码的内部所用算法是Base64编码的算法，所以它的格式与Base64编码格式非常相似，差别仅仅在于“信头”部分不同。 Uuencode“乱码”的大体格式为: begin 666 lm.txt M（"`@（-3:R，O`X，#ZRK?）SZ.LM-/`M，.[T]#2N\_NO+S*];RPQN33IM/#S_＆[ MI<＆JS?C2N]＇YMZ+5N<3＇P[2_[*.LMM3（R\/＇M<2YI-?WH:+）^KONH:+/^[?1 2NLV]N\WYM[W*O=.PS^S$Q\.T ` end 我们可以看到Uuencode“乱码”的主要特征是：编码以“begin xxx”开头，后面紧接着编码之前原始文件的名称，接着是已经用Uuencode编码的邮件内容，在乱码内容的后面，即最后一行为“end”。此外，乱码内容基本上除了最后两行外每行都是以英文字母“M”开头。上面那段话中，“begin”至“end”之间的内容即为“在人类历史上，从来没有一项技术及...”这段话的Uuedncode编码。 　 如果我们所用的电子邮件软件不支持Uuencode解码，那么我们看到的就是这些Uuencode“乱码”。 #1 2.Base64 encode“乱码” 　 Base64是MIME标准编码之一，它的编码方式是将4个字节（8位）用3个字节（6位）表示，由于编码后的内容是6位的，因此可以避免第8位被截掉。一般以附件发出的各种文件都会使用这种编码，其内容往往是一大堆杂乱无章但都可以正常显示的ASCII码字符（其大小被限定在0-63之间， 分别用＇A＇-＇Z＇、＇a＇-＇z＇、＇0＇-＇9＇、＇+＇和＇/＇组成），同时邮件头上有“Content-Transfer-Encoding: base64”字样。 Base64 encode“乱码”的大体格式为: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ICAgINTayMvA4MD6yrfJz6OstNPAtMO709DSu8/uvLzK9bywxuTTptPDz/G7 pcGqzfjSu9H5t6LVucTHw7S/7KOsttTIy8PHtcS5pNf3oaLJ+rvuoaLP+7fR us29u835t73KvdOwz+zEx8O0 我们可以看到Base64 encode的标志头中影响编码的主要有三行（分号后的内容算上一行）：第一行表明是MIME编码；第二行是Content-Type（内容及类型），它说明邮件的内容类型是纯文本、图片还是压缩文件或是超文本文档（如text/plain表示普通文本文件、text/html表示超文本文件、application/x-zip-compressed表示zip压缩文件），至于charset（字符集）则是用来说明信中文字所用字符集的（通常有us-ascii、ISO-8859-1、GB2312等）；第三行为Content-Transfer-Encoding（内容传输编码方式），表示编码方式（如base64、qutoed Printable或7bit）；有的邮件最后一行还有Content-Disposition字样，它表示编码文件的位置。对应乱码的内容即是“在人类历史上，从来没有一项技术及...”这段话的Base64编码。 如果我们所用的电子邮件软件不支持Base64解码，那么我们看到的就是这些Base64 encode“乱码”。 #1 3.QP encode“乱码” 　 QP encode也是MIME标准编码之一，这种编码的全名之所以叫作“Quoted-Printable Content-Transfer-Encoding”，是因为用这种格式表示的信息其内容主要都是ASCII码字符集中可以打印的字符，因此名称中含有printable。QP编码的方式是将一个字节用两个16进制数值表示，然后在前面加“=”。 QP encode“乱码”的大体格式为: Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable =D4=DA=C8=CB=C0=E0=C0=FA=CA=B7=C9=CF=A3=AC=B4=D3=C0=B4=C3=BB=D3=D0=D2=BB=CF=EE=BC=BC=CA=F5=BC=B0=C6=E4=D3=A6=D3=C3=CF=F1=BB=A5=C1=AA=CD=F8=D2=BB=D1=F9=B7=A2=D5=B9=C4=C7=C3=B4=BF=EC=A3=AC=B6=D4=C8=CB=C3=C7=B5=C4=B9=A4=D7=F7=A1=A2=C9=FA=BB=EE=A1=A2=CF=FB=B7=D1=BA=CD=BD=BB=CD=F9=B7=BD=CA=BD=D3=B0=CF=EC=C4=C7=C3=B4 我们可以看到，QP encode编码将一个8位的字符表示为3个字符：一个“=”和两个16进制数。由于汉字编码一般以两个8位表示一个汉字，所以该编码中表示一个汉字需要6个字符，如此段中的“=C8=CB”表示“人”字，“=C0=E0”表示“类”字。采用QP编码方式的邮件很容易进行判别，因为它的内容通常含有很多等号“=”，即使不看“信头”我们也能非常容易的判断它是否为QP encode编码。在实际使用中，这种编码还有一种变形，即用“%”号代替“=”号。 如果我们的电子邮件软件不支持QP encode解码，那么我们看到的就是这些QP encode“乱码”。 #1 4.UTF-7“乱码” UTF-7“乱码”的大体格式为: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit +VyhOunx7U4ZT8k4K/wxOzmdlbKFnCU4AmHligGcvU8pRdl6UdShQz06SgFR/UU4AaDdT0VxVkKNOSF/r/wxb+U66Tux2hF3lT1wwAXUfbTswAW2IjTlUjE6kX4BluV8PX3FUzZCjTkhZJ/8MXnZOFP8Mlo93QJrYXqZP4WBvUxZ2hH9Rftx5Pk8adoRSMGdl/wxOuk7sVyh1H06nVIx1H207ZblfDzABicJf9VSMYQ+LxntJZbmXYk5fX8VxNk8aU9F1H13oWSd2hFPYUxYwAgA8- 我们可以看到这种乱码除了具有QP乱码的特征外，在开头和结尾分别有“+”和“-”符号。其信头下的内容即为“在人类历史上，从来没有一项技术及...”这段话的UTF-7编码。 #1 5.UTF-8“乱码” UTF-8“乱码”的大体格式为: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 鍦ㄤ汉绫诲巻鍙蹭笂锛屼粠鏉ユ病鏈変竴椤规妧鏈強鍏跺簲鐢ㄥ儚浜掕仈缃戜竴鏍峰彂灞曢偅涔堝揩锛屽浜轰滑鐨勫伐浣溿佺敓娲汇佹秷璐瑰拰浜ゅ線鏂瑰紡褰卞搷閭ｄ箞澶э紝骞朵笖锛岄殢鐫楂樺害淇℃伅鍖栫殑缃戠粶绀句細鐨勫埌鏉ワ紝浜轰滑鍦ㄧ敓浜у拰鐢熸椿鏂瑰紡銆佽蹇靛拰鎰忚瘑绛夋柟闈篃蹇呯劧浼氬彂鐢熷法澶х殑鍙樺寲銆? 我们可以看到这种乱码有点文字内码的特征，事实上它就是一种内码的变形。其信头下的内容即为“在人类历史上，从来没有一项技术及...”这段话的UTF-8编码。 #1 6.HZ“乱码” 常见的汉字乱码还有一种是HZ编码产生的乱码，它是一种屏蔽最高位的汉字表示方法，是在GB码和Big5码的基础上用额外的控制序列来控制字形的显示，通常用~{ 和 ~}括起汉字编码部分，但字母和数字不被编码。 HZ“乱码”的大体格式为: Mime-Version: 1.0 Content-Type: text/plain; charset="hz-gb-2312" Content-Transfer-Encoding: quoted-printable ~{TZHK@`@zJ7IO#，4S@4C;SPR;On<^4s5D1d;/!#~} 我们可以看到这种乱码除了具有QP乱码的特征外，首尾分别是~{ 和 ~}这种特殊的括号。其信头下的内容即为“在人类历史上，从来没有一项技术及...”这段话的HZ编码。如果我们使用Outlook Express撰写邮件，并选用HZ编码发送，而使用Eudora来接收和阅读邮件，则看到的就是这些乱码。 特别提示：通过对上面Base64、QP、UTF-7、UTF-8和HZ等MIME类编码邮件格式的认识，我们发现含有MIME编码的邮件的源码一般都含有：“This is a multi-part message in MIME format.”这样的句子，并且有如下几部分“信头”作为它的显著特征： （1）Content-Type（内容及类型） （2）Charset（字符集） （3）Content-Transfer-Encoding（内容传输编码方式）。 #1 7.半个汉字“乱码” 　 汉字邮件乱码的另一个常见形式是所谓的“半个汉字”乱码。这是因为很多英文编辑软件是以字符为单位来处理文本的，当双字节的汉字被删除一半后，剩余的部分就会和相邻的汉字重新组合，从而造成汉字文本面目全非的现象。特别是在英文字处理软件中输入、删除或使用“字符替换”功能时最容易出现这种情况，它往往会因为缺少汉字的前一个字符而把这个汉字的后一个字符与相邻汉字的前一个字符当作一个新的汉字来重新匹配。这种乱码的特征并不明显，看起来往往令人莫名其妙、不知所云。 如“在人类历史上，从来没有一项技术及...”这段话对应的半个汉字“乱码”就“有可能”是如下这段乱码（丢失第一个汉字“在”的前半个字符）： 谌死嗬飞希永疵挥幸幌罴际跫捌溆τ孟窕チ谎⒄鼓敲纯欤匀嗣堑墓ぷ鳌⑸睢⑾押徒煌绞接跋炷敲创螅⑶遥孀鸥叨刃畔⒒耐缟缁岬牡嚼矗嗣窃谏蜕罘绞健⒐勰詈鸵馐兜确矫嬉脖厝换岱⑸薮蟮谋浠 　 我们可以看到这种乱码之所以“乱”的原因在于汉字前后搭配错位，所以如果是在英文字处理软件中处理邮件，你应该首先联想到这类乱码。 #1 8.Big5“乱码” 我们知道，中国大陆使用简体中文Windows平台的汉字内码是GB2312，台湾地区使用繁体中文Windows平台的汉字内码是Big5；而香港、澳门地区比较复杂，有用上述两种平台的，也有用英文Windows加挂中文之星、四通利方等中文平台的，那么其汉字内码是则GB2312和Big5码兼有。 Big5“乱码”的大体格式为: 摸菌眖ㄓ⊿Τ兜м砃のㄤ莱ノ钩が羛呼妓祇甶êе癸ネ禣㎝ユ┕よΑ紇臫ê繦帝蔼獺て呼蹈穦ㄓネ玻㎝ネよΑ芠├㎝種醚单よゲ礛穦祇ネエ跑て 我们可以看到，由于字符编码位置上的巧合和汉字平均出现概率上的统计，在GB2312码环境下看Big5编码的文字，将有汉字显示成为日语的假名，这就是在GB环境下看到Big5码汉字的主要特征。 需要说明的是，简体和繁体这两个概念和GB、Big5码并没有任何逻辑上的联系，GB的定义是简体字，Big5采用的是繁体字，但是为了阅读的方便，它们在各自的编码中又做了一个内部字形或字体的映射，于是就形成了所谓GB简体或Big5繁体之类的概念。然而实际上GB和Big5码已经不能形成一一对应的关系了，因此它们之间的转换往往具有不可逆性。这倒不是说一段文字不能在GB和Big5 码之间互相转换，而是说一旦将它们转换错了，信息就不能复原。比如你将“在人类历史上，从来没有一项技术及...”这段本来是GB2312码的文字转换成Big5码，然后再实施Big5码到GB码的转换，你会发现信息损失掉了，这种逆变换将不能再完全得到原来的文字了。 #1 9.其它乱码 这类乱码主要指的是日文Shift-JIS、日文Shift-EUC、韩文KSC等语言的编码在GB环境下的显示，如果我们所用的操作系统是英文环境，而我们又没有外挂中文系统（如中文之星）或未切换为中文（如Richwin、四通利方或南极星等）编码方式 ，那么我们自然看不到简体中文，而只能看到各种语言的内码，它们对我们这些没有学过相应语言的人来说当然是乱码。我们作为例子的“在人类历史上，从来没有一项技术及...”这段简体中文就可以分别对应日文Shift-JIS、日文Shift-EUC和韩文KSC三段形状迥异的“乱码”。 在GB2312码环境下看其它双字节字符的邮件时只能看到乱码，这就是需要使用一些转码工具如Richwin、南极星等进行转码的原因。 #1 三、乱码消除之妙手回春篇 #1 （一）传输机制不同造成的乱码解决方法 　 一般来说，如果邮件未经过编码造成第8位字节被滤掉而成为死乱码文档，还原起来是比较麻烦的，一般只有对计算机编码研究比较深的高手才能通过编程的方法将第8位的0重新还原为1。显然，这种方法并不对大多数人有效，所以我们需要寻求更简单的方法。目前一些共享软件提供了这样的功能，在后续文字中将向大家介绍。除此之外，如果大家收到这样的邮件，可以尝试利用具有解码功能的Winzip（最好是7.0版以上）和Wincode进行解码尝试，虽然不是一定能破解出来，但也不失为一个好方法。 #1 （二）编码不同造成的乱码解决方法 对于因为编码不同而造成的乱码，我们首先应该尝试的是在电子邮件软件中转换编码（如果你的电子邮件软件不能自动解码）。由于这种编码大多出现在中文邮件的接收上，所以当乱码出现时，我们应当首先检查它的编码方式是否为“简体中文（GB2312）”，如果不是可在Outlook Express中单击菜单栏“查看”/“编码”选项，并选中“简体中文（GB2312）”编码方式；在Foxmail中单击菜单栏“邮件”/“字符转换”选项，并选中“简体中文（GB2312）”编码方式，如果不行，还可以切换成其它编码试试。如果问题是由于语言内码不同造成的，则调出南极星、Richwin、中文之星等内码转换工具来查看。如果这些尝试都告失败，则你需要根据各种乱码格式的特征判别到底是哪种编码，并针对给出的不同编码作出如下处理： 1.解决Uuencode“乱码”的方法 方法1：如果电子邮件软件不能自动解码，则可以将Uuencode“乱码”邮件转寄到自己的一个邮箱中，然后再使用能够支持UU编码的电子邮件软件（如OutLook Express、Foxmail、Eudora、Becky、Netscape mail等）来接收该邮件。如在OutLook Express中就可单击菜单栏“查看”/“编码”选项，并选中“简体中文（GB2312）”编码方式，此时，屏幕会出现一个对话框，单击“是”按钮则所有邮件主题中含有指定字符集的邮件将应用新的字符集。 方法2：将Uuencode“乱码”邮件存为一个.txt的文本文件，将文件名后缀改为.eml，由OutLook Express 5打开，就可以自动解码。 方法3：将Uuencode“乱码”邮件存为一个.txt的文本文件，并改文件名后缀为.uue，然后使用Winzip（推荐使用Winzip7.0或更高版本）来解码。 方法4：将Uuencode“乱码”邮件存为一个.txt的文本文件，然后在Windows下用Wincode程序解码，（Wincode程序除了支持UU编码外还支持MIME编码、BINHEX等编码格式，应用范围颇为广泛）。 方法5：将Uuencode“乱码”邮件存为一个.txt的文本文件，然后到DOS下用uudecode.exe程序将文件解码。如将邮件名命名为lm，然后就可以用“uudecode lm”将其解码了，解码后即可自动生成解码后的文件，解码后文件名和发邮件时的文件名相同。当然，你也可以通过查看邮件中“begin”后的字符串得到文件名。 2.解决Base64 encode“乱码”的办法 方法1：将Base64 encode“乱码”邮件转寄到自己的一个邮箱中，然后用支持Base64解码的电子邮件软件（如OutLook Express、Foxmail、Eudora、Becky、Netscape mail等）来接收该邮件。 方法2：将Base64 encode“乱码”邮件存为一个.txt的文本文件，将文件名后缀改为.eml，由OutLook Express打开，一般可以自动解码。如果邮件使用的是附件方式（或者不能直接由OutLook Express打开），则可将附件保存（或将信体保存）后再用OutLook Express打开查看。必要时可以剪贴下来存为.txt的文本文件，并加上如下信头： Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 保存为.eml的文本文件后一般就可以用OutLook Express解码查看了。另外，如果邮件乱码不是GB码汉字，而像是Big5码，则需将"gb2312" 改为"big5"试一试。如果你最终认定乱码不是中文文本，而是二进制文件；或者是明显的二进制文件，电子邮件软件却不能还原成附带（Attached）的文件，那么需要将信件中的“Content-Type: text/plain;”改为“Content-Type: application/x-download;”。 方法3：将Base64 encode“乱码”邮件存为一个.txt的文本文件，并改文件名后缀为.uue，然后使用Winzip来解码。如果不行，还可在这个文本文件的邮件信头处添加如下几行： Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 特别要注意的是信头中间不要空行，信头和信体之间却要留有一个空行，即在“Content-Transfer-Encoding: base64”下要留有一行空行。这样形成的文件名后缀依然要改为.uue，然后用Winzip打开，信体一般就会被正确解码。 方法4：将Base64 encode“乱码”邮件存为一个.txt的文本文件，然后在Windows下用Wincode程序解码。 3.解决QP encode“乱码”的方法 方法1：将QP encode“乱码”邮件转寄到自己的一个邮箱中，然后用支持QP解码的电子邮件软件（如OutLook Express、Foxmail、Eudora、Becky、Netscape mail等）来接收该邮件。 方法2：将QP encode“乱码”邮件存为一个.txt的文本文件，将文件名后缀改为.eml，由OutLook Express打开，就可以自动解码。如果邮件使用的是附件方式（或者不能直接由OutLook Express打开），则可将附件保存（或将信体保存）后再用OutLook Express打开查看。必要时可以剪贴下来存为.txt的文本文件，并加上如下信头： Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable 保存为.eml的文本文件后一般就可以用OutLook Express解码查看了。 方法3：将QP encode“乱码”邮件存为一个.txt的文本文件，并改文件名后缀为.uue，然后使用Winzip来解码。如果不行，还可在这个文本文件的邮件信头处添加如下几行： Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable 信头中间还是不要空行，信头和信体之间也一定要留有一个空行，这样形成的文件名后缀依然需要改为.uue，然后用Winzip打开，则信体就会被解码，甚至E-mail中的标题或收发信人等信头位置带有的quoted-printable编码都可以一起被解决。 此外，特别需要注意的是，与Base64编码不同的是QP编码不处理原邮件中的换行，因此要注意一个汉字是由两个字符组成的，它将会对应于Quoted-Printable编码的六个字符，如果经过重新编辑并且换行不当则又会造成“半个汉字”的乱码现象，你又需要相应作出调整。