转自Q?a >http://blog.csdn.net/v_JULY_v/archive/2011/01/10/6127953.aspx
译者：(x)July 二零一一q一月十?/span>
------------------------------------
参考论文：(x)
The Best of the 20th Century: Editors Name Top 10 Algorithms?br />
By Barry A. Cipra?/p>
博主说明:
1、此20世纪的十大算法，除了快速排序算法，或者快速傅立叶变换Q其它算法只要稍作了解即可?br />
2、此文非最新文章，只是本h对算法比较感兴趣Q所以也做翻译，学习(fn)研究下?br />
3、本人喜好研I算法，写了一pdl典法研究的文章。详情，参考本文文末链接?/p>
===============================
一?946 蒙特卡洛Ҏ(gu)
[1946: John von Neumann, Stan Ulam, and Nick Metropolis, all at the Los Alamos Scientific Laboratory, cook up the Metropolis algorithm, also known as the Monte Carlo method.]
1946q_(d)国拉斯阿莫斯国家实验室的三位科学家John von Neumann,Stan Ulam ?Nick Metropolis
共同发明Q被UCؓ(f)蒙特卡洛Ҏ(gu)?/p>
它的具体定义是：(x)
在广ZM个边长一c的正方形，在正方Ş内部随意用粉W画一个不规则的ŞӞ
现在要计这个不规则囑Ş的面U，怎么计算?
蒙特卡洛(Monte Carlo)Ҏ(gu)告诉我们Q均匀的向该正方Ş内撒NQN 是一个很大的自然敎ͼ个黄豆，
随后数数有多个黄豆在这个不规则几何形状内部Q比如说有M个，
那么Q这个奇怪Ş状的面积便近gM/NQN大Q算出来的g精?br />
在这里我们要假定豆子都在一个^面上Q相互之间没有重叠?撒黄豆只是一个比喅R?
蒙特卡洛Ҏ(gu)可用于近D圆周率Q?br /> 让计机每次随机生成两个0?之间的数Q看q两个实数是否在单位圆内?br /> 生成一pd随机点，l计单位圆内的点Cȝ敎ͼ内接圆面U和正方形面U之比ؓ(f)PI:4QPI为圆周率?/p>
(多谢|友七里沌才指出，S内接圆：(x)S?PIQ?。具体，L(fng)文下W?9条评论?strong>十六日修?/strong>)Q?/p>
当随机点取得多Q但即?0?ơ方个随机点Ӟ其结果也仅在?位与圆周率吻合）Ӟ
其结果越接近于圆周率?/p>
二?947 单纯形法
[1947: George Dantzig, at the RAND Corporation, creates the simplex method for linear programming.]
1947q_(d)兰d公司的，Grorge DantzigQ发明了单纯形方法?br /> 单纯形法Q此后成ZU性规划学U的重要基石?br /> 所谓线性规划，单的_(d)是l定一l线性（所有变量都是一ơ幂Q约束条?br /> Q例如a1*x1+b1*x2+c1*x3>0)Q求一个给定的目标函数的极倹{?/p>
q么说似乎也太太太抽象了Q但在现实中能派上用场的例子可不|见——比如对于一个公司而言Q其能够?/p>
入生产的人力物力有限Q?#8220;U性约束条?#8221;Q，而公司的目标是利润最大化Q?#8220;目标函数取最大?#8221;Q，?/p>
Q线性规划ƈ不抽象吧Q?/p>
U性规划作{学(operation research)的一部分Q成为管理科学领域的一U重要工兗?br /> 而Dantzig提出的单UŞ法便是求解类似线性规划问题的一个极其有效的Ҏ(gu)?/p>
三?950 Krylov子空间P代法
[1950: Magnus Hestenes, Eduard Stiefel, and Cornelius Lanczos, all from the Institute for Numerical Analysis at the National Bureau of Standards, initiate the development of Krylov subspace iteration methods.]
1950q_(d)(x)国国家标准局数值分析研I所的，马格努斯HestenesQ爱德华施蒂费尔?br /> U尼利厄斯的LanczosQ发明了Krylov子空间P代法?/p>
Krylov子空间P代法是用来求解Ş如Ax=b 的方E，A是一个n*n 的矩阵，当n充分大时Q直接计变得非?/p>
困难Q而KrylovҎ(gu)则y妙地其变ؓ(f)Kxi+1=Kxi+b-Axi的P代Ş式来求解?br />
q里的K(来源于作者俄国hNikolai Krylov姓氏的首字母)是一个构造出来的接近于A的矩阵，
而P代Ş式的法的妙处在于，它将复杂问题化简为阶D|的易于计算的子步骤?/p>
四?951 矩阵计算的分解方?br />
[1951: Alston Householder of Oak Ridge National Laboratory formalizes the decompositional approach to matrix computations.]
1951q_(d)阿尔斯通橡?wi)岭国家实验室的Alston Householder提出Q矩阵计的分解Ҏ(gu)?/p>
q个法证明了Q何矩阵都可以分解Z角、对角、正交和其他Ҏ(gu)形式的矩阵，
该算法的意义使得开发灵zȝ矩阵计算软g包成为可能?/p>
五?957 优化的Fortran~译?br />
[1957: John Backus leads a team at IBM in developing the Fortran optimizing compiler.]
1957q_(d)(x)U翰巴库斯领导开发的IBM的团队，创造了Fortran优化~译器?/p>
FortranQ亦译ؓ(f)传Q是由Formula Translation两个字所l合而成Q意思是“公式译”?br /> 它是世界上第一个被正式采用q流传至今的高~程语言?br /> q个语言现在Q已l发展到了，Fortran 2008QƈZh们所熟知?/p>
六?959-61 计算矩阵特征值的QR法
[1959–61: J.G.F. Francis of Ferranti Ltd, London, finds a stable method for computing
eigenvalues, known as the QR algorithm.]
1959-61Qu敦费伦蒂有限公司的J.G.F. FrancisQ找C一U稳定的特征值的计算Ҏ(gu)Q?br /> q就是著名的QR法?/p>
q也是一个和U性代数有关的法Q学q线性代数的应该记得“矩阵的特征?#8221;Q计特征值是矩阵计算?/p>
最核心内容之一Q传l的求解Ҏ(gu)涉及(qing)到高?gu)ơ方E求根，当问题规模大的时候十分困难?/p>
QR法把矩阵分解成一个正交矩?希望L文的你，知道什么是正交矩阵?D?与一个上三角矩阵的积Q?/p>
和前面提到的Krylov Ҏ(gu)cMQ这又是一个P代算法，它把复杂的高?gu)ơ方E求栚w题化为阶D|的易于
计算的子步骤Q得用计算机求解大规模矩阵特征值成为可能?br /> q个法的作者是来自英国伦敦的J.G.F. Francis?/p>
七?962 快速排序算?br />
[1962: Tony Hoare of Elliott Brothers, Ltd., London, presents Quicksort.]
1962q_(d)(x)伦敦的，托尼埃利奥特兄弟有限公司Q霍?dng)提Z快速排序?/p>
哈哈Q恭喜你Q终于看C可能是你W一个比较熟(zhn)的法~?br /> 快速排序算法作为排序算法中的经典算法，它被应用的媄子随处可见?/p>
快速排序算法最早由Tony Hoare爵士设计Q它的基本思想是将待排序列分ؓ(f)两半Q?br /> 左边的一半L“的”Q右边的一半L“大的”Q这一q程不断递归持箋下去Q直到整个序列有序?br /> 说vq位Tony Hoare爵士Q快速排序算法其实只是他不经意间的小发现而已Q他对于计算A(ch)献主要包?/p>
形式化方法理论，以及(qing)ALGOL60 ~程语言的发明等Q他也因q些成就获得1980 q图灵奖?/p>
========
关于快速排序算法的具体认识与应用，可参考我写的一文章，
_N八大排序算法系列、一、快速排序算?/span>Q?/span>
http://blog.csdn.net/v_JULY_v/archive/2011/01/04/6116297.aspx
------------------------------------------------------------
快速排序的q_旉复杂度仅仅ؓ(f)O(Nlog(N))Q相比于普通选择排序和冒泡排序等而言Q?br /> 实在是历史性的创D?/p>
八?965 快速傅立叶变换
[1965: James Cooley of the IBM T.J. Watson Research Center and John Tukey of Princeton
University and AT&T Bell Laboratories unveil the fast Fourier transform.]
1965q_(d)(x)IBM 华生研究院的James CooleyQ和普林斯顿大学的John TukeyQ?br /> ATQT贝尔实验室共同推Z快速傅立叶变换?/p>
快速傅立叶法是离散傅立叶法Q这可是数字信号处理的基矻I的一U快速算法，其时间复杂度仅ؓ(f)O
(Nlog(N))Q比旉效率更ؓ(f)重要的是Q快速傅立叶法非常Ҏ(gu)用硬件实玎ͼ因此它在?sh)子技术领域得?/p>
极其q泛的应用?/p>
日后Q我?x)在我?strong>l典法研究pdQ着重阐q此法?/p>
?ji)?977 整数关系探测法
[1977: Helaman Ferguson and Rodney Forcade of Brigham Young University advance an integer
relation detection algorithm.]
1977q_(d)(x)Helaman Ferguson?伯明大学的Rodney ForcadeQ提ZForcade算法的整数关系?/p>
整数关系探测是个古老的问题Q其历史甚至可以q溯到欧几里L(fng)时代。具体的?
l定—组实数X1,X2,...,XnQ是否存在不全ؓ(f)零的整数a1,a2,...anQ?a1 x 1 +a2 x2 + . . . + an x
n Q??
q一qBrighamYoung大学的Helaman Ferguson 和Rodney Forcade解决了这一问题?br />
该算法应用于“化量子场Z的Feynman囄计算”。okQ它q不要你懂，了解卛_?D?/p>
十?987 快速多极算?br />
[1987: Leslie Greengard and Vladimir Rokhlin of Yale University invent the fast multipole algorithm.]
1987q_(d)(x)莱斯利的GreengardQ和耉大学的Rokhlin发明了快速多极算法?/p>
此快速多极算法用来计?#8220;l由引力或静?sh)力怺作用的N 个粒子运动的_计算——例如银河系中的星体Q?br />
或者蛋白质中的原子间的怺作用”。okQ了解即可?br />
完?/p>
]]>
转蝲自：(x)http://hi.baidu.com/baiduqa/blog/item/5c937b418264581f73f05d20.html
1. 字符~码基础知识
1.1. 字符~码基本概念
C~码模型的编码思想包括Q有什么字W、他们的~号、这些编号如何编码成一pd的码元，以及(qing)最后这些单元如何编码ؓ(f)8位字节流。对应于如下术语Q?br style="line-height: normal" />
1Q字W表 一个系l所支持的所有抽象字W的d?br style="line-height: normal" />
2Q编码字W集 定义了如何用称为码点的非负整数集表CZ个字W集Q一个整数对应一个抽象的字符?br style="line-height: normal" />
3Q字W编码Ş?定义编码字W集的整C码{换成有限大小整数代码g利于使用固定位的二进制表C数字的形式的系l存储。例如?位或16位单元存储数字信息。字W编码Ş式定义了如何用单个或多个码DC码点的Ҏ(gu)。例如utf8是一U编码Ş式，utf-16则是另一U编码Ş式?br style="line-height: normal" />
4Q字W编码机?定义固定大小的整C码如何映到Z8位字节数据的文gpȝ存储或者基?位字节网l传输。在多数使用unicode的场合，一个简单的字符~码机制用来指定每个整数的字节顺序是大字节在先顺序还是小字节在先序。还有其他复杂的字符~码机制?br />
1.2. 字符~码发展
字符~码的历史大致可以分Z个阶D：(x)
1Qascii阶段
刚开始只支持pQ其他语a不能够在计算Z存储和显C。用一个字节来存一个字W?br style="line-height: normal" />
2Qansi~码Q本地化Q?br style="line-height: normal" />
Z计算机支持更q语aQ通过使用0x80~0xFF范围?个字节来表示1个字W。不同的国家和地区制定了不同的标准，由此产生了各U各L(fng)~码标准Q如gb2312、big5、jis{。这些用两个字节来表示一个字W的各种汉字延~码方式Q称为ansi~码?br style="line-height: normal" />
3QUnicode阶段Q国际化Q?br style="line-height: normal" />
Z使国际间信息交流更加方便Q国际组l制定了unicode字符集，为各U语a中的每一个字W设定了l一q且唯一的数字编P以满语言、跨q_q行文本转换、处理的要求。Unicode仅仅制定了字W集Q用来给unicode~码的标准有utf-7、utf-8、utf-16、unicodeLittle、unicodebig{?br />
1.3. 主要~码
1.3.1. Ascii
ascii全称国信息互换标准代码Qamerican standard code for information interchageQ。主要用于显C现代英语和其他西欧语言Q是C最通用的单字节~码Q等于国标标准iso 646。包含控制字W?2个和可打印字W?4个。编码单元ؓ(f)8位，取值单位从0x00-0x7FQ最高ؓ(f)0?br />
1.3.2. 汉字~码
汉字~码均采用双字节~码Q编码单元ؓ(f)8位?br />
1.3.2.1. Gb2312-80
Gb2312是对ascii的中文扩展，是中华h民共和国国家标准汉字信息交换用编码。收录简化汉字及(qing)一般符受序受数字、拉丁字母、日文假名、希腊字母、俄文字母等?445个图形字W。其中汉字以外的囑Ş字符682个，汉字6763个。ؓ(f)了与pȝ中基本的ascii字符集区分开Q所有汉字编码的每个字节的第一位都??br style="line-height: normal" />
Gb2312的汉字编码规则是Q第一个字节的值在0xB0?xF7之间Q第二个字节的值在0xA0?xFE之间。但是gb2312收录的汉字太，以致很多常用字都没有收录Q如朱鎔基的“?#8221;字。ؓ(f)了解册些问题，以及(qing)配合unicode的实施，全国信息技术化技术委员会(x)制定了gb13000Q即gbk。Gbk向下与gb2312完全兼容Q向上支持iso-10646国际标准?/span>
1.3.2.2. Gbk
Gbk包含?0902个汉字，其编码范围是0x8140-0xfefeQ剔除高?x80的字位。收录汉字包括：(x)
1Qgb2312中全部汉字、非汉字字符
2Qbig5中的全部汉字
3Q与iso-10646相应的国家标准gb13000中的其他cjk汉字
4Q其他汉字、部首、符L(fng)?br />
其编码区分成三个部分Q?br style="line-height: normal" />
1Q汉字区 包括
a) Gbk/2Q?xb0a1-f7feQ收录gb2312汉字6763个，按原序排列，0xd7fa-0xd7fe为空z?br style="line-height: normal" />
b) Gbk/3Q?x8140-a0feQ收录cjk汉字6080个，0x817f-0xa07f为空z?br style="line-height: normal" />
c) Gbk/4Q?xaa40-fea0Q收录cjk汉字和增补汉?160个，0xaa7f-0xfe7f为空z?br style="line-height: normal" />
2Q图形符号区 包括
a) Gbk/1Q?xa1a1-0xa9feQ除gb2312的符号外Q还增补了其他符?br style="line-height: normal" />
b) Gbk/5Q?xa840-0xa9a0Q扩充非汉字?br style="line-height: normal" />
3Q用戯定义?br />
1.3.2.3. Gb18030-2000
GB18030-2000?000q推出的国家标准。它可以视ؓ(f)GBK的升U，因ؓ(f)它主要增加了Unicode 3.0中新增的一些字W。除了GBK的字W，它能表示UNICODE中所有的字符。中国出售的所有Y件品都要求支持GB18030?br style="line-height: normal" />
GB18030与GBK完全兼容Q除了欧元符?Q在GB18030中是A2E3Q在GBK中是0x80?br style="line-height: normal" />
采用单字节、双字节和四字节三种方式对字W编码，~码范围如下Q?br style="line-height: normal" />
1Q单字节: 0x00-0x7f
2Q双字节: 0x81-0xfe + 0x40-0x7e, 0x80-0xfe
3Q四个字? 0x81-0xfe + 0x30-0x39 + 0x81-0xfe + 0x30-0x39
1.3.2.4. Big5
Big5又称五大码，是用繁体中文字C众最常用的计机汉字字符集标准，由台?家大公司的方案拼凑而成?br style="line-height: normal" />
Big5共收?3053个中文字Q其中有两个字重码，为兀Q?xa461?xc94aQ和嗀Q?xdcd1-0xddfcQ?br style="line-height: normal" />
Big5使用双八码存储方式，以两个字节来安放一个字。高位字节用了0xa1-0xf9Q低位字节用了0x40-0x7e?xa1-0xfe?br style="line-height: normal" />
原始的BIG-5 只包括一些常用的字，甚至不包括日文的假名{，在实际的应用中很多系l给BIG-5加上了自q扩展。例如，MS code page 950Q欧元符号A3E1?br />
1.3.3. Unicode
Unicode是一个大一l的Ҏ(gu)Q它?/span>http://www.unicode.org制定的编码机Ӟ要将全世界常用文字都函括q去。它为每U语a中的每个字符讑֮了统一q且唯一的二q制~码Q以满跨语a、跨q_q行文本转换、处理的要求?990q开始研发，1994q正式公布。随着计算机工作能力的增强QUnicode也在面世以来的十多年里得到普?qing)?br style="line-height: normal" />
但自从unicode2.0开始，unicode采用了与ISO 10646-1相同的字库和字码QISO也承诺ISO10646不?x)给?x10FFFF的UCS-4~码赋|使得两者保持一致?nbsp;
Unicode的编码方式与ISO 10646的通用字符?Universal Character SetQUCS)概念相对应，目前的用于实用的Unicode版本对应于UCS-2Q?6位的~码I间。也是每个字符占用2个字节，基本满各种语言的用。实际上目前版本的Unicode未填充满这16位编码，保留了大量空间作为特D用或来扩展?nbsp;
Unicode和ucs只是分配整数l字W的~码表，卛_是一个编码字W集合。现在存在好几种一个字W表CZؓ(f)若干个字节的Ҏ(gu)。最显而易见的Ҏ(gu)是将unicode文本存储?个或4个字节序列的丌Ӏ这两种Ҏ(gu)的正式名UCؓ(f)ucs-2和ucs-4?br style="line-height: normal" />
但是在unix下用ucs-2或ucs-4?x)导致非怸重的问题。用q些~码的字W串?x)包含一些特D的字符Q比?#8217;\0’?#8217;/’Q他们在文g名和其他c库函数里都有特别的含义。另外，大多C用ascii文g的unix下的工具Q如果不q行重大修改是无法读?6位的字符的。基于这些原因，在文件名Q文本文件、环境变量等地方Qucs-2不适合作ؓ(f)unicode的外部编码?br style="line-height: normal" />
因此需要一U新的编码方案称为utfQunicode transfer formatQ运用在unix/linux环境中。Utf-7Qutf-8Qutf-16都是q泛接受的方案。Rfc2781和rfc3629定义了utf-8和utf-16的编码方式?/span>
1.3.3.1. Utf-8
Utf-8是?位ؓ(f)单元对ucs-2q行~码。从ucs-2到utf-8的编码方式如下：(x)
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
Utf-8有如下特性：(x)
1QUCS 字符 U+0000 ?U+007F (ASCII) 被编码ؓ(f)字节 0x00 ?0x7F (ASCII 兼容)。这意味着只包?7 ?ASCII 字符的文件在 ASCII ?UTF-8 两种~码方式下是一L(fng)?br style="line-height: normal" />
2Q所?>U+007F ?UCS 字符被编码ؓ(f)一个多个字节的? 每个字节都有标记位集。因? ASCII 字节 (0x00-0x7F) 不可能作ZQ何其他字W的一部分.
3Q表C非 ASCII 字符的多字节串的W一个字节L?0xC0 ?0xFD 的范围里, q指个字W包含多个字节。多字节串的其余字节都在 0x80 ?0xBF 范围里。这使得重新同步非常Ҏ(gu)Qƈ使编码无国界, 且很受丢失字节的媄?
4Q可以编入所有可能UCS 代码
5QUTF-8 ~码字符理论上可以最多到 6 个字节长, 然?16 ?BMP 字符最多只用到 3 字节ѝ?br style="line-height: normal" />
6QBigendian UCS-4 字节串的排列序是预定的.
7Q字?0xFE ?0xFF ?UTF-8 ~码中从未用?
1.3.3.2. Uft-16
Utf-16是以16位ؓ(f)~码单元的，在范围u+0000到u+ffff间的码点使用一个单一?6位编码单元表C；而在范围u+10000到u+10FFFF间的码点则用一?6位编码单元表C，UC代理寏VUtf-16优化了基本多语言q面QbmpQ中字符的表C，即位于u+0000到u+FFFF范围内的字符。该范围包含了目前世界上所使用的书写系l中的绝大数字符Q每个字W只需要一?6位的~码单元。对于基本多语言q面Qutf-16可作为固定宽度的~码格式来有效用。但是对于增补字W，utf-16需要两?6位的~码单元Q意味着正式的utf-16是一个变宽的~码格式。Utf-16是早期unicode遗留下的历史产物Q原本被设计成具有固定宽度的16位编码格式，为支持超qu+ffff的增补字W，讄了代理机制?/span>
1.3.3.3. Utf-32
Utf-32是一U最单的unicode~码格式。每个unicode码点直接被表CZؓ(f)一?2位的~码单元。Utf-32是一U固定宽度的字符~码格式。每个utf-32~码单元的gunicode码点的值完全相同?/span>
1.4. Tips
1.4.1. ~码字节?br style="line-height: normal" />
Big endian和Little endian是CPU处理多字节数的不同方式。例?#8220;?#8221;字的Unicode~码?C49。那么写到文仉ӞI竟是将6C写在前面Q还是将49写在前面Q如果将6C写在前面Q就是big endian。如果将49写在前面Q就是little endian?br style="line-height: normal" />
“endian”q个词出自《格列佛(jng)游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开q是从小?Little-Endian)敲开Q由此曾发生q六ơ叛乱，一个皇帝送了命，另一个丢了王位?br style="line-height: normal" />
我们一般将endian译?#8220;字节?#8221;Q将big endian和little endianUC“大尾”?#8220;尾”?br style="line-height: normal" />
对于M字符~码Q编码单元的序是由~码Ҏ(gu)指定的，与endian无关。例如gbk的编码单元是字节Q用两个字节表示一个汉字，q两个字节的序是固定的Q不受cpu字节序的影响。Utf-16的编码单元是wordQword之间的顺序是~码Ҏ(gu)指定的，word内部的字节排列才?x)收到endian的媄响。Utf-8也是以字节ؓ(f)~码单元Q没有字节序的问题?br style="line-height: normal" />
一个用utf-16~码的文件如何进行解释呢Q以一个例子来说明Q打开C本，写上一D|字，然后另存Q在保存的对话框中可以看到有四种~码方式可以选择Q分别是QansiQunicodeQunicode big endian和utf-8?br style="line-height: normal" />
Ansi是默认编码方式，也是pȝ的默认编码方式，q省代码页军_?br style="line-height: normal" />
Utf-8不用解释了?br style="line-height: normal" />
Unicode和unicode big endian都是utf-16~码的两U，区别在于前者采用little endianQ后者采用big endian。还有一U方式采用bom标记字节序列Qbom?#8220;byte order mark”Q是一个有点小聪明的想法。在ucs~码中有一个叫?#8220;zero width no-break space”的字W，他的~码是feff。而feff在ucs中是不存在的字符Q所以不应该出现在实际传输中。Ucs规范我们在传输字节流前，西安传输字符“zero width no-break space”。这样如果接受者收到fefQ就表明q个字节是big-endianQ如果fffeQ就表明q个字节是little-endian的?br style="line-height: normal" />
“ABC”q三个字W用各种方式~码后的l果如下Q?br style="line-height: normal" />
utf-16be 00 41 00 42 00 43
utf-16le 41 00 42 00 43 00
utf-16(bom be) fe ff 00 41 00 42 00 43
utf-16(bom le) ff fe 41 00 42 00 43 00
utf-16(不带bom) 00 41 00 42 00 43
1.4.2. Windows代码?br style="line-height: normal" />
Unicode推出后，microsoftwindows的内栔RҎ(gu)支持unicode字符集。但是由于现有的大量E序和文档都采用了某U特定语a的编码，例如gbkQwindows不可能不支持现有的编码而全部改用unicode。Windows使用代码|适应各个国家和地区。Gbk对应的code page是cp936Qgb18030的code page为cp54936。但是由于gb18030有一部分四字节编码，而windows的代码页只支持单字节和双字节~码Q故cp54936是无法真正用的?br style="line-height: normal" />
Windows可以同时支持多个代码，只要文g能够说明自己使用什么编码，用户又安装了对应的代码页Qwindowsp正确昄Q例如在html文g中指定charset?br style="line-height: normal" />
Windows中有~省代码늚概念Q可以通过控制面板的区域选项讄Q其作用是缺省用什么编码来解释字符。Windows的记事本的存储格式有一Ҏ(gu)ansiQ其实就是按照缺省代码页的编码方式保存?br />
2. |页~码方式
2.1. url~码基础知识
一个httph需要经q如下几个环节：(x)
1Q浏览器把url以及(qing)提交的内容经q编码后发送给服务?br style="line-height: normal" />
2Q服务器处理完毕后将l果~码q回l浏览器
3Q浏览器按照指定的编码显C网?br style="line-height: normal" />
一个完整的url由如下方式组成：(x)
域名Q端?contextPath/servletPath/pathInfo?queryString
其中pathInfo和queryString是需要编码的部分?br style="line-height: normal" />
Rfc1738中定义了url的语法语义，限制了url中可以出现的字符。对于不可在url中出现的字符需要按照一定的方式q行~码Q叫做url encode。需要进行encode的符号包括如下：(x)
1Qascii中的控制字符Q原因很单，因ؓ(f)他们是不可见的，范围?0-1F?FQ?br style="line-height: normal" />
2Q非ascii字符Q比如中文字W等Q这是因为url中没有安全的办法指定字符集（rfc2396Q；
3Q保留字W，url语法中用到的字符Q?&+,/:;=?@
4Q不安全字符Q空?%<>{}I\~^[]`Q出于各U原因；
url encode采用%XX方式QXX为字W的十六q制~码?br style="line-height: normal" />
但是在实际应用中Q浏览器是否q行url encodeQ采用何U字W集q行url encodeQ与览器和服务器的讄都有关系Q分析如下，以下分析均在windows中文环境中：(x)
1Q对用户在地址栏中直接输入的urlQ编码方式与览器的讄有关
览器（模式Q?PathInfo QueryString
IeQutf-8模式Q默认） Utf8~码Q无url encode Gbk~码Q无urlencode
IeQansi模式Q?Gbk~码Q无urlencode Gbk~码Q无urlencode
FirefoxQutf8模式Q?Utf8~码Qurlencode Utf8~码Qurlencode
FirefoxQansi模式Q默认） Gbk~码Qurlencode Gbk~码Qurlencode
OperaQutf8模式Q默认） Utf8~码Qurlencode Utf8~码Qurlencode
2Q对|页中的链接Q与该网|w的~码方式有关?br />
在不改变?gu)览器默认选项的情况下Q各个浏览器的编码方式如?br style="line-height: normal" />
览器（|页~码方式Q?PathInfo QueryString
IeQutf8|页Q?UTF-8~码、urlencode UTF-8~码、无urlencode
IeQgbk|页Q?UTF-8~码、urlencode GBK~码、无urlencode
FirefoxQutf8|页Q?UTF-8~码、urlencode UTF-8~码、urlencode
FirefoxQgbk|页Q?GBK~码、urlencode GBK~码、urlencode
3Q对用户提交的数据，不论是get方式q是post方式Q其~码方式q中的编码方式和相关调用有关?br style="line-height: normal" />
面的编码方式由http头指定或|页的meta标记指定。http头中含有content-type参数Q其中指定了charsetQ?br style="line-height: normal" />
Content-type:text/html;charset=gb2312
Meta标记的方式如下：(x)
<meta http-eq后台v=”content-type” content=”text/html;charset=gb2312”/>
不同的浏览器处理方式也会(x)不同Qie可能通过文g内容识别Qfirefox偏向meta标签识别?br style="line-height: normal" />
对于传统的表单提交，其编码方式是由页面的~码方式军_的；而ajax提交的数据则与其调用方式有关Q如果采用了escapecM的编码函敎ͼ则编码成utf-8q行发送?br />
2.2. 服务器对~码的处?br />
假设后端均采用gbk存储数据Q那么对提交的数据需q行~码识别q进行相应的~码转换Q主要针对两U情况：(x)
1Qurl路径部分Q?br style="line-height: normal" />
׃需要支持中文，q部分是不可控的Q取决于操作pȝ和浏览器Q因此需要进行判别到底是什么编码，然后再进行编码{换?br style="line-height: normal" />
2Q提交数据部分：(x)
提交的数据也既有可能是utf-8~码也有可能是gbk~码。一U办法是判断是否是utf-8~码Q但q种判断存在一定的p|率；q有一U办法从面上控Ӟ提交时强制增加一个字D表C是否是utf-8~码Qapache无需考虑其他的，只根据该字段判断是否需要做utf-8到gbk的编码{化，q个办法是不?x)出现误伤的?br style="line-height: normal" />
判断是否是utf-8~码有一定的p|率，有如下几U情况：(x)
1Q判断错误?br style="line-height: normal" />
主要发生在utf8与gbk~码重叠的部分，需Ҏ(gu)实际应用q行处理?br style="line-height: normal" />
2Q判断成功，但是转换p|?br style="line-height: normal" />
没有对应的gbk~码?x)导致{换失败，例如韩文字符Q在q种情况下可转成实体?br style="line-height: normal" />
3Q判断是否是utf-8时判断错误，q且转换p|Q这U情况下不会(x)出现问题?br style="line-height: normal" />
~码的识别和转换完成后，后端的模块也需要根据实际应用进行各U各L(fng)处理Q如Q控制字W过滤、繁转换、全半角转换、半个汉字处理、字W集qo(h){等?br style="line-height: normal" />
当获取到数据l装要q回的页面时Q对出现在页面上的信息需q行一定的转义Q比如对于一些由html标签l成的文本，如果不进行特D处理，那么览器会(x)当做标签来进行解析，从而引起页面展现错误?br />
3. ~码问题分类
3.1. gbk字符集中的特D字W?br />
1Q?0x80Ƨ元W号
【分析?br style="line-height: normal" />
数据库支持有问题Q会(x)自动截断Qgbk对其~码与其他编码方式不兼容。非必要条g下徏议过滤掉?br style="line-height: normal" />
【Bad case?br style="line-height: normal" />
我们在进行编码设计时包含欧元符L(fng)信息插入数据库，因ؓ(f)数据库将Ƨ元W号以后的部分截断，记录的信息的长度与实际长度不一致从而引起下游模块的逻辑错误?br style="line-height: normal" />
2Q?0x00-0x31控制字符部分
【分析?br style="line-height: normal" />
控制字符无法打印?br style="line-height: normal" />
【bad case?br style="line-height: normal" />
当用h造了由控制字W组成的信息Q这部分信息昄在页面上Q会(x)佉K面上本应出现文字的地方出现空白，q且如果q部分文字存在链接会(x)使得链接失效从而导致不可点凅R?br style="line-height: normal" />
3Q?0x7F I白Z
【分析】如果输入会(x)是不可见字符Q徏议过滤掉?br style="line-height: normal" />
4Q?0x5C反斜?br style="line-height: normal" />
【分析?br style="line-height: normal" />
它的Ҏ(gu)性在于两个原因：(x)1、它作ؓ(f)转义W标C的Ҏ(gu)用法Q?、它~码区间
落在GBK字符集的后半个汉字允许的~码区间内。由于这两个原因Q再l合GBK字符集本w存在雪崩问题的隐?zhn)Q当末尾存在半个汉字Q和0x5C字符l合可能导致{义符h效，裔R出后l的’{，D转义W号实效Q带来一些安全问题和js失效{问题。或者和半个汉字l合Dmysql转义处理失效?br style="line-height: normal" />
5Q?I洞区：(x)0xd7fa-0xd7feQ?x817f-0xa07fQ?xaa7f-0xfe7f
【分析?br style="line-height: normal" />
GBK前半个汉字的范围?x81-0xfe之间Q不?xffQ如果用h造了0xffq样的半个汉字上来，׃部分览器支持的问题Q例如ieQ就?x)?xFF字符当作GBK的前半个汉字和后l字W结合?br style="line-height: normal" />
除此之外Q码区的中间也有一些空z?br style="line-height: normal" />
【bad case?br style="line-height: normal" />
如果黑客构?xff 0x5c 0x27q样的字W串Q?x5C是\Q作{义标C符P0x27是单引号’Q，那么0xff?x5cl合成ؓ(f)一个不可见字符Q导致原本\’的{义失效，’暴露出来造成安全漏洞?br style="line-height: normal" />
6Q?Sql语句中的Ҏ(gu)字符Q?#8217;、\
【分析?br />
mysql对于Ҏ(gu)字符?\"{需要处理后才能存储Q采用的函数是mysql_real_escapeQ）Q将其中的特D字W{义成/*Q对q个函数的要求是面必须存在一个可用的mysqlq接?br style="line-height: normal" />
7Q?字符外Ş和全角英文字W完全一致的字符Q?xA6A2?xA7A2Q?xA976?xA3A8
8Q?全角I格Q?xA1A1
9Q?扩展汉字区域Q主要是非汉字区域和Ҏ(gu)字符
10QCp936和其它码表定义不一致的地方
11QGBK~码中和其他~码方式有冲H或者有处理方式不一L(fng)个别字符
12Q可以构成强制{义字W的字符Q?#
13Q字W串l束W：(x)\0
14Q可能被作ؓ(f)数据l构分隔W的字符
15Q边界字W：(x)?(0x8140)Q亐 (0x8180)Q儈 (0x837E)Q凗 (0x83FE)Q狛 (0xA0FE)Q癄 (0XAFA0)Q?(0xFE7E)Q鳌 (0xF7A1)Q?0XFEA0)Q齄 (0XF7FE)?br style="line-height: normal" />
16QTrailing byte ?low-ansi 范围?(4 个例?
腀 (0xC440 / 0x8140) ?(0x83A0 / 0x512c)
?(0xA07C / 0x7218) ?(0xA086 / 0x7222)
17QLeading ?trailing byte 大小写是相同的表C?(3 个例?
'C' / 'c' ?(0x8143) / ?(0x8163)
'M' / 'm' ?(0xF74D) / ?(0xF76D)
'S' / 's' S (0XA053) / s (0XA073)
18QTrailing byte ?Leading byte 范围相同 (4 个例?
?(0x8181) ?(0xBABA)
?(0xA0A0) ?(0xF7F7)
19Qleading ?trailing byte ?0xAA, 0xAE or 0xBF, Ҏ(gu)变成q(3 个例? ?(0x9FAA) ?(0x81AE) ?(0XF7BF)
20Q以下特D字W的unicode 和汉字的 byte是一L(fng)Q在解码的时候容易出错，应该?0个左叻I只列?2?á (U+00EA) (0xA8A2) à (U+00E0) (0xA8A4) é (U+00E9) (0xA8A6) è (U+00E8) (0xA8A8) ì (U+00EC) (0xA8AC) í (U+00ED) (0xA8AA) ó (U+00F3) (0xA8AE) ò (U+00F2) (0xA8B0) ú (U+00FA) (0xA8B2) ù (U+00F9) (0xA8B4) ü (U+00FC) (0xA8B9) ê (U+00EA) (0xA8BA)
3.2. utf8与gbk~码冲突部分
utf8与gbk~码冲突部分Q会(x)D~码识别p|Q从而在展现面时出现问题。utf8与gbk?27个重叠的~码?br style="line-height: normal" />
【bad case 1?br style="line-height: normal" />
“璎玥“q个用户名，此用L(fng)正确的GBK是E8ACAB68Q最后一个字节就是ascii?#8216;h‘。例如当用户在ff讉Khttp://www.test.com/璎玥 ӞE8ACAB 是utf8~码?#8221;?#8221;Q?8?#8216;h’Q所以看到的是讉K用户”h”。在ie下是正常的utf8~码字符Q所以无问题?br style="line-height: normal" />
【bad case 2?br style="line-height: normal" />
~码0xc2b7Q在gbk中表C?#8220;?#8221;q个字，在uft8中表CZؓ(f)“•”q个字符。如果用L(fng)url中含有maria•sharapovaQ当以utf8~码发送时Q被优先判断为gbk~码Q则服务器识别ؓ(f)maria路sharapova?br style="line-height: normal" />
重叠部分的编码既需要在不同的浏览器中测试，也需要在url路径和提交的数据中测试?br />
3.3. Gbk中不存在的编?br />
1Q韩语字W?br style="line-height: normal" />
2Q其他少数语U?br style="line-height: normal" />
3QGB18030相对GBK增加的字W?br />
3.4. 盔R字节l合部分
1Q?内容qo(h)中相d节组合：(x)哈林
【bad case?br style="line-height: normal" />
汉字“哈林”相连?个字节被识别?#8220;?#8221;Q正好是个过滤词Q导致正怿息被qo(h)?br style="line-height: normal" />
2Q?面展现中相d节组合：(x)牛肩猪肉
面上如果存?#8220;牛肩猪肉”的文字则Zؕ码的现象Q原因在于牛的第二个字节和肩的第一个字节正好构成了全角?#8216;>’字符Q后台对q类字符q行了{义?br style="line-height: normal" />
3Q?Sql语句中相d节组合成\Q?br style="line-height: normal" />
当用戯入字W?#243;' {一些字W时Q出Cl装SQL语句旉误。这cdW的特点? 一个大于ascii128~码的字W加上一?Q在GBK~码q程中会(x)被解析成为\?,然后造成SQL语句的错误?#243;字符为ASCII码的243Q可以用键盘敲入。此Ӟl过mysql的{码，被{义成?#243;\', 而汉字编码会(x)?#243;\形成一个汉字笈'Q这时就?x)出现mysql错误的问题?/span>
作者：(x)qabloger
]]>