本文系转载，不知道文章原始出处，有知道的还望告知~
ASCII及相关标准
地 球人都知道ASCII就是美国标准信息交换码的缩写，也知道ASCII规定用7位二进制数字来表示英文字符，ASCII被定为国际标准之后的代号为 ISO-646。由于ASCII码只使用了7个二进制位，也就是说一个字节可以表示的256个数字中，它仅使用了0~127这128个码位，剩下的128 个码位便可以用来做扩展，用来表示一些特定语言所独有的字符，因此对这多余的128个码位的不同扩展，就形成了一系列ISO-8859-*的标准。例如为 英语作了专门扩展的字符集编码标准编号为ISO-8859-1，也叫做Latin-1，为希腊语所作的扩展编号为ISO-8859-7等，完整的列表可以 参考《Java Internationalization》一书。
Unicode与UCS
整
个Unicode项目是由多家计算机软件公司，还包括一些出版行业的公司共同发起的，从上世纪八十年代就已经开始。地球人都知道，对于日文，汉字来
说，256个码位是远远不够用的（当然，在当时并不是地球人都知道，起码设计计算机的老美们就不知道，甚至直到今天，还有老美以为米国是世界上唯一的国
家）。解决方法很直观也很明显，那就是采用码位多到足够包含所需字符数量的编码方案（即俗话说的头痛医头，脚痛医脚嘛）。这也是Unicode的目标之
一，能够包含世界上所有语言的字符（包括汉字，日文，数学符号，音乐符号，还包括各种奇奇怪怪看也看不懂的东西比如象形文字，甲骨文
，三个代表，科学发展观等等，笑），这个理想，可以说很远大，但很快被发现仅靠Unicode原先的设计无法实现。Unicode的另一个设计目标，对今
天影响深远，那就是对所有字符都采用16位编码（即用一个大小不超过2的16次方的整数数字给每个字符编号，注意从这个意义上也可以看出，Unicode
是一种编码字符集，而非字符集编码）。说这个设计目标对现今影响深远，完全不是表扬，因为到后来连Unicode的设计者也发现，16位编码仅有
65536个码位，远远不能容纳世界上所有的字符，但当意识到这个问题的时候，Unicode大部分的规范已经制定完毕，也有相当程度的普及，完全推倒重
来是不现实的。这成了一个遗留问题，也是surrogate pair这种蹩脚解决方案的发端。
无
独有偶，在1984年，喜欢以繁多的编号糊弄群众的国际标准化组织ISO也开始着手制定解决不同语言字符数量太大问题的解决方案，这一方案被称为
Universal Character
Set（UCS），正式的编号是ISO-10646（记得么，ASCII是ISO-646，不知这种安排是否是故意的）。还是ISO高瞻远瞩，一开始就确
定了UCS是一个31位的编码字符集（即用一个大小不超过2的31次方的整数数字为每个字符编号），这回真的足以容纳古往今来所有国家，所有语言所包含的
字符了（是的，任何国家，任何小语种都包括，也不管这些国家是与台湾建交还是与中国大陆建交，是拥护民主制度还是实行恐怖主义，所以说科学无国界）。虽然
后来他们意识到，2的31次方个码位又实在太多了……
天
下大势，分久必合。无论Unicode还是UCS，最初的目的都是杜绝各种各样名目繁多形式各异互不兼容老死不相往来的私用扩展编码（好啰嗦的一句话），
结果两方确立标准的同时（最初时这两个标准是不兼容的），又形成了割据，这对建设和谐社会是不利的，违反当今世界和平与发展的主旋律，中国政府一向反对任
何形式的霸权主义和强权政治，对以米国为首的发达国家……扯远了扯远了。1991年，Unicode联盟与ISO的工作组终于开始讨论Unicode与
UCS的合并问题，虽然其后的合并进行了很多年，Unicode初版规范中的很多编码都需要被改写，UCS也需要对码空间的使用进行必要限制，但成果是喜
人的。最终，两者统一了抽象字符集（即任何一个在Unicode中存在的字符，在UCS中也存在），且最靠前的65535个字符也统一了字符的编码。对于
码空间，两者同意以一百一十万为限（即两者都认为虽然65536不够，但2的31次方又太大，一百一十万是个双方都可接受的码空间大小，也够用，当然，这
里说的一百一十万只是个约数），Unicode将码空间扩展到了一百一十万，而UCS将永久性的不使用一百一十万以后的码位。也就是说，现在再讲
Unicode只包含65536个字符是不对的。除了对已经定义的字符进行统一外，Unicode联盟与ISO工作组也同意今后任何的扩展工作两者均保持
同步，因此虽然从历史的意义上讲Unicode与UCS不是一回事（甚至细节上说也不是一回事），但现在提起Unicode，指代两者均无不妥。
需要再一次强调的是，无论历史上的UCS还是现如今的Unicode，两者指的都是编码字符集，而不是字符集编码。花费一点时间来理解好这件事，然后你会发现对所有网页的，系统的，编码标准之间的来回转换等等繁杂事务都会思路清晰，手到擒来。
首先说说最一般意义上的字符集。
一个抽象字符集其
实就是指字符的集合，例如所有的英文字母是一个抽象字符集，所有的汉字是一个抽象字符集，当然，把全世界所有语言的符号都放在一起，也可以称为一个抽象字
符集，所以这个划分是相当人为的。之所以说“抽象”二字，是因为这里所提及的字符不是任何具体形式的字符，拿汉字中的“汉”这个字符来说，您在这篇文章中
看到的这个“汉”其实是这个字符的一种具体表现形式，是它的图像表现形式，而且它是用中文（而非拼音）书写而成，使用宋体外观；而当人们用嘴发出“汉”这
个音的时候，他们是在使用“汉”的另一种具体表现形式——声音，但无论如何，两者所指的字符都是“汉”这个字。同一个字符的表现形式可能有无数种（点阵表
示，矢量表示，音频表示，楷体，草书等等等等），把每一种表现形式下的同一个字符都纳入到字符集中，会使得集合过于庞大，冗余高，也不好管理。因此抽象字
符集中的字符，都是指唯一存在的抽象字符，而忽略它的具体表现形式。
抽象字符集中的诸多字符，没有顺序之分，谁也不能说哪个字符在哪个字符前面，而且这种抽象字符只有人能理解。在给一个抽象字符集合中的每个字符都分配一个整数编号之后（注意这个整数并没有要求大小），这个字符集就有了顺序，就成为了编码字符集。
同时，通过这个编号，可以唯一确定到底指的是哪一个字符。当然，对于同一个字符，不同的字符集所制定的整数编号也不尽相同，例如“儿”这个字，在
Unicode中，它的编号是0x513F，（为方便起见，以十六进制表示，但这个整数编号并不要求必须是以十六进制表示）意思是说它是Unicode这
个编码字符集中的第0x513F个字符。而在另一种编码字符集比如Big5中，这个字就是第0xA449个字符了。这种情况的另一面是，许多字符在不同的
编码字符集中被分配了相同的整数编号，例如英文字母“A”，在ASCII及Unicode中，均是第0x41个字符。我们常说的Unicode字符集，指
的就是这种被分配了整数编号的字符集合，但要澄清的是，编码字符集中字符被分配的整数编号，不一定就是该字符在计算机中存储时所使用的值，计算机中存储的
字符到底使用什么二进制整数值来表示，是由下面将要说到的字符集编码决定的。
字
符集编码决定了如何将一个字符的整数编号对应到一个二进制的整数值，有的编码方案简单的将该整数值直接作为其在计算机中的表示而存储，例如英文字符就是这
样，几乎所有的字符集编码方案中，英文字母的整数编号与其在计算机内部存储的二进制形式都一致。但有的编码方案，例如适用于Unicode字符集的
UTF-8编码形式，就将很大一部分字符的整数编号作了变换后存储在计算机中。以“汉”字为例，“汉”的Unicode值为0x6C49，但其编码为
UTF-8格式后的值为0xE6B189（注意到变成了三个字节）。这里只是举个例子，关于UTF-8的详细编码规则可以参看《Mapping
codepoints to Unicode encoding forms》一文，URL为http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-AppendixA#sec3。
我
们经常听说的另一种编码方案UTF-16,则对Unicode中的前65536个字符编号都不做变换，直接作为计算机存储时使用的值（对65536以后的
字符，仍然要做变换），例如“汉”字的Unicode编号为0x6C49，那么经过UTF-16编码后存储在计算机上时，它的表示仍为0x6C49！。我
猜，正是因为UTF-16的存在，使得很多人认为Unicode是一种编码（实际上，是一个字符集，再次重申），也因此，很多人说Unicode的时候，
他们实际上指的是UTF-16。UTF-16提供了surrogate pair机制，使得Unicode中码位大于65536的那些字符得以表示。
Surrogate
pair机制在目前来说实在不常用，甚至连一些UTF-16的实现都不支持，所以我不打算在这里多加讨论，其基本的思想就是用两个16位的编码表示一个字
符（注意，只对码位超过65536的字符这么做）。Unicode如此死抱着16这个数字不放，有历史的原因，也有实用的原因。
当
然还有一种最强的编码，UTF-32,他对所有的Unicode字符均不做变换，直接使用编号存储！（俗称的以不变应万变），只是这种编码方案太浪费存储
空间（就连1个字节就可以搞定的英文字符，它都必须使用4个字节），因而尽管使用起来方便（不需要任何转换），却没有得到普及。
记
得当初Unicode与UCS还没成家之时，UCS也是需要人爱，需要人疼的，没有自己的字符集编码怎么成。UCS-2与UCS-4就扮演了这样的角色。
UCS-4与UTF-32除了名字不同以外，思想完全一样。而UCS-2与UTF-16在对前65536个字符的处理上也完全相同，唯一的区别只在于
UCS-2 不支持surrogate
pair机制，即是说，UCS-2只能对前65536个字符编码，对其后的字符毫无办法。不过现在再谈起字符编码的时候，UCS-2与UCS-4早已成为
计算机史学家才会用到的词汇，就让它们继续留在故纸堆里吧。
接 着上节的思路说，一个网页要想在浏览器中能够正确显示，需要在三个地方保持编码的一致：网页文件，网页编码声明和浏览器编码设置。首先是网页文件本身的编 码，即网页文件在被创建的时候使用什么编码来保存。这个完全取决于创建该网页的人员使用了什么编码保存，而进一步的取决于该人员使用的操作系统。例如我们 使用的中文版WindowsXP系统，当你新建一个文本文件，写入一些内容，并按下ctrl+s进行保存的那一刻，操作系统就替你使用GBK编码将文件进 行了保存（没有使用UTF-8，也没有使用UTF-16）。而使用了英文系统的人，系统会使用ISO-8859-1进行保存，这也意味着，在英文系统的文 件中如果输入一个汉字，是无法进行保存的（当然，你甚至都无法输入）。 一个在创建XML文件时（创建HTML的时候倒很少有人这么做）常见的误解是以为只要在页面的encoding部分声明了UTF-8，则文件就会被保存为 UTF-8格式。这实在是……怎么说呢，不能埋怨大家。实际上XML文件中encoding部分与HTML文件中的charset中一样，只是告诉“别 人”（这个别人可能是浏览你的页面的人，可能是浏览器，也可能是处理你页面的程序，别人需要知道这个，因为除非你告诉他们，否则谁也猜不出你用了什么编 码，仅通过文件的内容判断不出使用了什么编码，这是真的）这个文件使用了什么编码，唯独操作系统不会搭理，它仍然会按自己默认的编码方式保存文件（再一次 的，在我们的中文WindowsXP系统中，使用GBK保存）。至于这个文件是不是真的是encoding或者charset所声明的那种编码保存的呢？ 答案是不一定！例如新浪的页面就“声称”他是用GB2312编码保存的，但实际上却是GBK，也有无数的二把刀程序员用系统默认的GBK保存了他们的 XML文件，却在他们的encoding中信誓旦旦的说是UTF-8的。这就是我们所说的第二个位置，网页编码声明中的编码应该与网页文件保存时使用的编 码一致。而浏览器的编码设置实际上并不严格，就像我们第三节所说的那样，在浏览器中选择使用GB2312来查看，它实际上仍然会使用GBK进行。而且浏览 器还有这样一种好习惯，即它会尽量猜测使用什么编码查看最合适。我要重申的是，网页文件的编码和网页文件中声明的编码保持一致，这是一个极好的建议（值得 遵循，会与人方便，与己方便），但如果不一致，只要网页文件的编码与浏览器的编码设置一致，也是可以正确显示的。例如有这样一个页面，它使用GBK保存， 但声明自己是UTF-8的。这个时候用浏览器打开它，首先会看到乱码，因为这个页面“告诉”浏览器用UTF-8显示，浏览器会很尊重这个提示，于是乱码一 片。但当手工把浏览器设为GBK之后，显示正常。说了以上四节这么多，后面我们就来侃侃Java里的字符编码，你会发现有意思且挠头的事情很多，但一旦弄 通，天下无敌（不过不要像东方不败那样才好）。
原文：http://www.cnblogs.com/jiangbinb/p/5215640.html