邮件乱码破解完全手册.docx
- 文档编号:4068008
- 上传时间:2022-11-27
- 格式:DOCX
- 页数:22
- 大小:39.91KB
邮件乱码破解完全手册.docx
《邮件乱码破解完全手册.docx》由会员分享,可在线阅读,更多相关《邮件乱码破解完全手册.docx(22页珍藏版)》请在冰豆网上搜索。
邮件乱码破解完全手册
邮件乱码破解完全手册
随着Internet的普及,在网上通过E-mail传递信息逐渐成为现代人生活的时尚,相信不久甚至还会成为一种生活的必需内容。
但我们在接收电子邮件的时候,不时会发现接收的邮件是些怪模怪样的乱码,根本无法阅读。
如果这些邮件的内容并不很重要,可能还不会有太大影响,可是假如是些紧急事件的通知或是生意场上的公函,则很可能就会给你带来不小的损失。
遇到这种情况,你打算怎么办呢?
把邮件丢进垃圾筒就当没收到,麻烦发信人再重发一次,还是自己找方法破译?
我们知道,计算机以及很多计算机网络协议的制定都是建立在ASCII码(美国国家标准信息交换码,它是一种最基本的字符表示方法)基础上的,但是随着信息内容的日益丰富,用ASCII码表示计算机信息开始暴露出很大的不足,这主要表现在表示多国文字、图形、声音等二进制文件和信息压缩、信息保密等诸多方面。
因此,在ASCII码和扩展ASCII码的基础上,用一定的规则定义一些新的信息表达形式就形成了信息传输和处理中的另一类概念和事物,这就是“编码”和“解码”。
当信息编码和解码能够统一的时候,信息无疑是可以交换和被理解的;反之,当信息编码和解码不能够得到统一的时候,信息就无法被用于交换和理解,于是就产生了所谓的“乱码”。
既然乱码的产生是由于信息编码和解码不能够得到统一,那么解决乱码的过程自然就是找到和编码相统一的解码方法,并对计算机软件不能全自动进行正确解码的信息进行重新处理和解码,最终使得所恢复的信息能被人们理解和交换,这就是所谓的“破解”。
可以说,常见的乱码都有这样一些共性:
(1)和汉字或其他语种的文字有关;
(2)最常发生在电子邮件的传输和阅读中;(3)和传送二进制文件有关;(4)和信息加密解密、编码解码有关。
而我们今天要讨论的电子邮件乱码的原因也正如前面所说,和相应的邮件发送系统、电子邮件软件以及操作系统平台本身,即它们用来自动识别和编码解码的协议规则,有着极为密切的关系。
本文以目前最常使用的电子邮件软件OutlookExpress和Foxmail为例(其它电子邮件软件有所提及),尽可能给出常见乱码的乱码原因、乱码现象、标志格式和解决方案,并为你提供一套经典的破解流程作为参考,只是希望对你破解邮件乱码DIY能有些许帮助。
一、乱码产生之来龙去脉篇
(一)邮件乱码产生的原因
事实上造成邮件乱码的具体原因是很多的,但最为常见的不外乎有三种情况:
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码的,由于操作系统汉字内码的差异,在收发邮件时遭遇到乱码也就不算奇怪了。
(二)E-mail中常见的编码标准
如上面我们所谈到的那样,现在传送电子邮件的关键在于编码。
只有经过编码,中文或非ASCII码格式的邮件才能正确通过Internet上那些不支持8位编码的邮件系统;只有电子邮件软件都完全支持,而且能正确识别编码的类别,电子邮件的内容才能为我们所阅读和理解。
那么,在电子邮件系统中究竟有哪些编码标准呢?
目前在E-mail中一般常用的编码标准有UU、MIME和BINHEX编码三种,其中MIME编码是目前应用最广泛的编码。
下面我们就来详细了解一下这几种编码:
1.UU编码(Unix-to-Unixencoding)
这是邮件传输早期传送非ASCII码文件时最常使用的编码方式,它主要使用在Unix环境下(邮件系统大多都建立在Unix操作系统上),但目前使用者已经越来越少。
UU编码实际上由Uuencode和Uudecode两部分组成,它们分别是Unix系统下的UU编码和解码程序,但其内部所用算法却是MIME编码中Base64编码的算法,后来被改写成为在DOS下运行的可执行程序。
UU编码传输邮件的原理是:
在进行邮件发送前,先在DOS方式下用Uuencode.exe程序将原文件编码成ASCII码文件,然后再进行发送,而收件人在接到文件后只需用Uudecode.exe程序将文件还原即可。
此外,UU编码并非只能对中文邮件进行编码,只要你寄出的文件包括.gif、.jpg、.exe、.zip等二进制文件,它都能按照编码、发送、收信、解码还原的步骤来予以传送。
这种编码方法现在虽已经不很常用了,但OutlookExpress、Foxmail等绝大多数电子邮件软件都支持它。
需要指出的是,UU编码是DOS系统下的编解码程序,在Windows系统中与之对应的编解码程序是Wincode(Winzip也采用了相似的原理)。
事实上,Wincode的使用原理同DOS下的Uuencode和Uudecode相同,只不过它是利用了Windows的界面,从而使相应的操作方式更为简便和灵活。
值得注意的是,Wincode程序除了支持UU编码外,还支持MIME、BINHEX等多种编码格式,故而应用范围相当广泛。
2.MIME编码(MultipurposeInternetMailExtentions)
虽然UU编码也能解决E-mail传送中文或非ASCII码文件的问题,但它的编解码方式在现在看来非常不方便,这就促使了MIME编码标准的产生。
Mimencode最早被称为Mmencode,之所以提出用Mimencode代替Uuencode,是因为Uuencode编码使用的一些字符在一些邮件网关(特别是那些转换ASCII码和EBCDIC码的网关)中会造成传输障碍。
另外,还有一些电子邮件软件不能对所有Uuencode码的算法进行正确解码而导致邮件的阅读困难,因此MIME编码就被设计用来替代Uuencode编码,但历史的结果是这些编码协议得到了共存。
MIME编码一般被译作“多媒体邮件传送模式”,它是可以传送多媒体文件,并在一封电子邮件中附加各种格式文件一起发送的编码标准。
我们现在最常使用的电子邮件软件OutlookExpress、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编码的这种便利性、可靠性,现在越来越多的电子邮件(几乎所有)都采用了这种编码方式,像我们国内用户最常使用的电子邮件软件OutlookExpress、FoxMail、Eudora、TheBat!
、NetscapeMail和InternetMail等都支持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中一类比较特别的编码。
特别提示:
对于上面提到的四类编码,最新的Foxmail3.1版支持Uuencode和MIME两种编码,但MIME编码只支持8位(8bit)编码方式(也有称作UTF-8编码的),另外它还支持us-ascii、ISO-8859-1、简体中文GB2312、日文Shift-JIS、韩文KSC、繁体中文Big5等多种字符集。
总的来说,它比较适合以纯文本方式传送正文。
而OutlookExpress5则支持Uuencode编码和MIME中的Base64以及QP两种编码方式以及UTF-7、UTF-8编码和多国文字字符集,除此之外它还支持邮件正文以HTML方式传送,这就是我们用OutlookExpress能看到有着漂亮背景的邮件的原因。
另外,我们上面提到的Windows下的Wincode解码程序也能支持Uuencode编码、MIME编码以及Binhex编码,但非常遗憾的是,对于MIME编码,Wincode只能处理Base64的编码,而没有QP编码的功能,实在是有些美中不足。
二、乱码现形之真相大白篇
在以下内容中,我们将下面这段话作为所有乱码对应的简体中文,并存为lm.txt文本,用来分析下面九类乱码的特征与形式:
在人类历史上,从来没有一项技术及其应用像互联网一样发展那么快,对人们的工作、生活、消费和交往方式影响那么大,并且,随着高度信息化的网络社会的到来,人们在生产和生活方式、观念和意识等方面也必然会发生巨大的变化。
1.Uuencode“乱码”
由于Uuencode编码的内部所用算法是Base64编码的算法,所以它的格式与Base64编码格式非常相似,差别仅仅在于“信头”部分不同。
Uuencode“乱码”的大体格式为:
begin666lm.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“乱码”的主要特征是:
编码以“beginxxx”开头,后面紧接着编码之前原始文件的名称,接着是已经用Uuencode编码的邮件内容,在乱码内容的后面,即最后一行为“end”。
此外,乱码内容基本上除了最后两行外每行都是以英文字母“M”开头。
上面那段话中,“begin”至“end”之间的内容即为“在人类历史上,从来没有一项技术及...”这段话的Uuedncode编码。
如果我们所用的电子邮件软件不支持Uuencode解码,那么我们看到的就是这些Uuencode“乱码”。
2.Base64encode“乱码”
Base64是MIME标准编码之一,它的编码方式是将4个字节(8位)用3个字节(6位)表示,由于编码后的内容是6位的,因此可以避免第8位被截掉。
一般以附件发出的各种文件都会使用这种编码,其内容往往是一大堆杂乱无章但都可以正常显示的ASCII码字符(其大小被限定在0-63之间,分别用'A'-'Z'、'a'-'z'、'0'-'9'、'+'和'/'组成),同时邮件头上有“Content-Transfer-Encoding:
base64”字样。
Base64encode“乱码”的大体格式为:
MIME-Version:
1.0
Content-Type:
text/plain;
charset="us-ascii"
Content-Transfer-Encoding:
base64
ICAgINTayMvA4MD6yrfJz6OstNPAtMO709DSu8/uvLzK9bywxuTTptPDz/G7
pcGqzfjSu9H5t6LVucTHw7S/7KOsttTIy8PHtcS5pNf3oaLJ+rvuoaLP+7fR
us29u835t73KvdOwz+zEx8O0
我们可以看到Base64encode的标志头中影响编码的主要有三行(分号后的内容算上一行):
第一行表明是MIME编码;第二行是Content-Type(内容及类型),它说明邮件的内容类型是纯文本、图片还是压缩文件或是超文本文档(如text/plain表示普通文本文件、text/html表示超文本文件、application/x-zip-compressed表示zip压缩文件),至于charset(字符集)则是用来说明信中文字所用字符集的(通常有us-ascii、ISO-8859-1、GB2312等);第三行为Content-Transfer-Encoding(内容传输编码方式),表示编码方式(如base64、qutoedPrintable或7bit);有的邮件最后一行还有Content-Disposition字样,它表示编码文件的位置。
对应乱码的内容即是“在人类历史上,从来没有一项技术及...”这段话的Base64编码。
如果我们所用的电子邮件软件不支持Base64解码,那么我们看到的就是这些Base64encode“乱码”。
3.QPencode“乱码”
QPencode也是MIME标准编码之一,这种编码的全名之所以叫作“Quoted-PrintableContent-Transfer-Encoding”,是因为用这种格式表示的信息其内容主要都是ASCII码字符集中可以打印的字符,因此名称中含有printable。
QP编码的方式是将一个字节用两个16进制数值表示,然后在前面加“=”。
QPencode“乱码”的大体格式为:
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
我们可以看到,QPencode编码将一个8位的字符表示为3个字符:
一个“=”和两个16进制数。
由于汉字编码一般以两个8位表示一个汉字,所以该编码中表示一个汉字需要6个字符,如此段中的“=C8=CB”表示“人”字,“=C0=E0”表示“类”字。
采用QP编码方式的邮件很容易进行判别,因为它的内容通常含有很多等号“=”,即使不看“信头”我们也能非常容易的判断它是否为QPencode编码。
在实际使用中,这种编码还有一种变形,即用“%”号代替“=”号。
如果我们的电子邮件软件不支持QPencode解码,那么我们看到的就是这些QPencode“乱码”。
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编码。
5.UTF-8“乱码”
UTF-8“乱码”的大体格式为:
Mime-Version:
1.0
Content-Type:
text/plain;
charset="utf-8"
Content-Transfer-Encoding:
8bit
鍦ㄤ汉绫诲巻鍙蹭笂锛屼粠鏉儐病鏈変竴椤规妧鏈強鍏跺簲鐢ㄥ儚浜掕仈缃戜竴鏍峰彂灞曢偅涔堝揩锛屽浜轰滑鐨勫伐浣溿€佺敓娲汇€佹秷璐瑰拰浜傘線鏂瑰紡褰卞搷閭d箞澶屽苟涓旓紝闅
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 邮件 乱码 破解 完全 手册
![提示](https://static.bdocx.com/images/bang_tan.gif)