一、 什么是字符集?什么是编码?
字符(Character)是文字与符号的总称，包括文字、图形符号、数学符号等。
一组抽象字符的集合就是字符集(Charset)。
字符集常常和一种具体的语言文字对应起来，该文字中的所有字符或者大部分常用字符就构成了该文字的字符集，比如英文字符集。
一组有共同特征的字符也可以组成字符集，比如繁体汉字字符集、日文汉字字符集。
字符集的子集也是字符集。
计算机要处理各种字符，就需要将字符和二进制内码对应起来，这种对应关系就是字符编码(Encoding)。
制定编码首先要确定字符集，并将字符集内的字符排序，然后和二进制数字对应起来。根据字符集内字符的多少，会确定用几个字节来编码。
每种编码都限定了一个明确的字符集合，叫做被编码过的字符集(Coded Character Set)，这是字符集的另外一个含义。通常所说的字符集大多是这个含义。
二、有哪些字符集?
1. ASCII:
American Standard Code for Information Interchange，美国信息交换标准码。
目前计算机中用得最广泛的字符集及其编码，由美国国家标准局(ANSI)制定。
它已被国际标准化组织(ISO)定为国际标准，称为ISO 646标准。
ASCII字符集由控制字符和图形字符组成。
我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。
在计算机的存储单元中，一个ASCII码值占一个字节(8个二进制位)，其最高位(b7)用作奇偶校验位。
所谓奇偶校验，是指在代码传送过程中用来检验是否出现错误的一种方法，一般分奇校验和偶校验两种。
奇校验规定:正确的代码一个字节中1的个数必须是奇数，若非奇数，则在最高位b7添1。
偶校验规定:正确的代码一个字节中1的个数必须是偶数，若非偶数，则在最高位b7添1。
ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。
在C#中如果你想看看某个字母的ASCII码是多少，可以使用表示字符编码的类Encoding ，代码如下：
string s = “a”;
byte[] ascii = Encoding.ASCII.GetBytes(s);
我们通过调试器可以看到ascii中为97，也就是说a的ASCII码为97（01100001）
2. ISO 8859-1:
ISO 8859，全称ISO/IEC 8859，是国际标准化组织(ISO)及国际电工委员会(IEC)联合制定的一系列8位字符集的标准，现时定义了15个字符集。
英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的é的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。
但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel (ג)，在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0—127表示的符号是一样的，不一样的只是128—255的这一段。
除了使用拉丁字母的语言外，使用西里尔字母的东欧语言、希腊语、泰语、现代阿拉伯语、希伯来语等，都可以使用这个形式来储存及表示。
很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。
但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。
而且在很多协议上，默认使用该编码。
3. UCS:
通用字符集(Universal Character Set，UCS)是由ISO制定的ISO 10646(或称ISO/IEC 10646)标准所定义的字符编码方式，采用4字节编码。
UCS包含了已知语言的所有字符。
除了拉丁语、希腊语、斯拉夫语、希伯来语、阿拉伯语、亚美尼亚语、格鲁吉亚语，还包括中文、日文、韩文这样的象形文字，UCS还包括大量的图形、印刷、数学、科学符号。
4. Unicode:
Unicode(统一码、万国码、单一码)是一种在计算机上使用的字符编码。
它是http://www.unicode.org/制定的编码机制， 要将全世界常用文字都函括进去。
它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。
1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode也在面世以来的十多年里得到普及。
但自从unicode2.0开始，unicode采用了与ISO 10646-1相同的字库和字码，ISO也承诺ISO10646将不会给超出0x10FFFF的UCS-4编码赋值，使得两者保持一致。
Unicode的编码方式与ISO 10646的通用字符集(Universal Character Set，UCS)概念相对应，目前的用于实用的Unicode版本对应于UCS-2，使用16位的编码空间。
也就是每个字符占用2个字节，基本满足各种语言的使用。实际上目前版本的Unicode尚未填充满这16位编码，保留了大量空间作为特殊使用或将来扩展。
Unicode当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表（http://www.chi2ko.com/tool/CJK.htm）。
英文的Unicode范围是0×0000-0x007F，中文的Unicode范围是0x4E00-0x9F**
C#中如果你想看看某个汉字的Unicode编码可以使用如下代码：
string s = “梁”;
byte[] unicode = Encoding.Unicode.GetBytes(s);
这时unicode中有两个数字129（10000001），104（1101000）
Unicode的问题
需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。
比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。
这里就有两个严重的问题，第一个问题是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。
它们造成的结果是：1）出现了unicode的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示unicode。2）unicode在很长一段时间内无法推广，直到互联网的出现。
5. UTF:
Unicode 的实现方式不同于编码方式。
一个字符的Unicode编码是确定的，但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。
Unicode的实现方式称为Unicode转换格式(Unicode Translation Format，简称为 UTF)。
5.1 UTF-8
互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种unicode的实现方式。其他实现方式还包括UTF-16和UTF-32，不过在互联网上基本不用。重复一遍，这里的关系是，UTF-8是Unicode的实现方式之一。
UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单，只有二条：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的unicode码。
下表总结了编码规则，字母x表示可用编码的位。
Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
——————–+———————————————
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
下面，还是以汉字“严”为例，演示如何实现UTF-8编码。
已知“严”的unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。
C#代码如下：
string s = “严”;
byte[] unicode = Encoding.Unicode.GetBytes(s);
byte[] utf8 =Encoding.UTF8.GetBytes(s);
这里在内存中的数据是由高到低排列的，37十六进制为25，78十六进制为4E，也就是说”严”的unicode是十六进制为4E25，二进制为100111000100101，我们从上边的表中可以查到，4E25应该属于地三行（800-FFFF），因此”严”的UTF-8编码需要三个字节即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“梁”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“梁”的UTF-8编码是“11100100 10111000 10100101”，按没8位转换成十进制就是228，184，165。正好和上图中utf8中的值一样。
5.2 Unicode与UTF-8之间的转换
通过上一节的例子，可以看到“严”的Unicode码是4E25，UTF-8编码是E4B8A5，两者是不一样的。它们之间的转换可以通过程序实现。
在Windows平台下，有一个最简单的转化方法，就是使用内置的记事本小程序Notepad.exe。打开文件后，点击“文件”菜单中的“另存为”命令，会跳出一个对话框，在最底部有一个“编码”的下拉条。
里面有四个选项：ANSI，Unicode，Unicode big endian 和 UTF-8。
1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。
2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
3）Unicode big endian编码与上一个选项相对应。我在下一节会解释little endian和big endian的涵义。
4）UTF-8编码，也就是上一节谈到的编码方法。
选择完“编码方式”后，点击“保存”按钮，文件的编码方式就立刻转换好了。
6. 汉字编码:
6.1 GB2312字集是简体字集
全称为GB2312(80)字集，共包括国标简体汉字6763个。
一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，我们还把数学符号、罗马希腊的字母、日文的假名们都编进去了，连在 ASCII 里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的”全角”字符，而原来在127号以下的那些就叫”半角”字符了
6.2 BIG5字集是台湾繁体字集
共包括国标繁体汉字13053个。
6.3 GBK字集是简繁字集
包括了GB字集、BIG5字集和一些符号，共包括21003个字符。
中国的汉字太多了，我们很快就就发现有许多人的人名没有办法在这里打出来，特别是某些很会麻烦别人的国家领导人。于是我们不得不继续把 GB2312 没有用到的码位找出来老实不客气地用上。
后来还是不够用，于是干脆不再要求低字节一定是127号之后的内码，只要第一个字节是大于127就固定表示这是一个汉字的开始，不管后面跟的是不是扩展字符集里的内容。结果扩展之后的编码方案被称为 GBK 标准，GBK 包括了 GB2312 的所有内容，同时又增加了近20000个新的汉字（包括繁体字）和符号。
6.4 GB18030是国家制定的一个强制性大字集标准
全称为GB18030-2000，它的推出使汉字集有了一个“大一统”的标准。
后来少数民族也要用电脑了，于是我们再扩展，又加了几千个新的少数民族的字，GBK 扩成了 GB18030。从此之后，中华民族的文化就可以在计算机时代中传承了。
中国的程序员们看到这一系列汉字编码的标准是好的，于是通称他们叫做 “DBCS”（Double Byte Charecter Set 双字节字符集）。在DBCS系列标准里，最大的特点是两字节长的汉字字符和一字节长的英文字符并存于同一套编码方案里，因此他们写的程序为了支持中文处理，必须要注意字串里的每一个字节的值，如果这个值是大于127的，那么就认为一个双字节字符集里的字符出现了。那时候凡是受过加持，会编程的计算机僧侣们都要每天念下面这个咒语数百遍：
“一个汉字算两个英文字符！一个汉字算两个英文字符……”
在C#中如果你想看看某个汉字的GB2312编码可以使用如下代码：
string s = “梁”;
System.Text.Encoding GB2312 = System.Text.Encoding.GetEncoding(“GB2312″);
byte[] gb = GB2312.GetBytes(s);
这时gb中有两个数字193（11000001），186（10111010）
7 ANSI和Unicode big endia:
我们在Windows系统中保存文本文件时通常可以选择编码为ANSI、Unicode、Unicode big endian和UTF-8，这里的ANSI和Unicode big endia是什么编码呢?
ANSI:
使用2个字节来代表一个字符的各种汉字延伸编码方式，称为ANSI编码。
在简体中文系统下，ANSI编码代表GB2312编码，在日文操作系统下，ANSI编码代表JIS编码。
Unicode big endia:
UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。
Unicode规范中推荐的标记字节顺序的方法是BOM(即Byte Order Mark)。
为什么会有字节顺序呢？说道这里，就要补一补基本知识了。现代的计算机系统一般采用字节(Octet, 8 bit Byte)作为逻辑寻址单位。当物理单位的长度大于1个字节时，就要区分字节顺序(Byte Order, or Endianness)。
上一节已经提到，Unicode码可以采用UCS-2格式直接存储。以汉字“严”为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。
这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。
因此，第一个字节在前，就是“大头方式”（Big endian），第二个字节在前就是“小头方式”（Little endian）。
那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？
在UCS编码中有一个叫做ZERO WIDTH NO-BREAK SPACE的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。
UCS规范建议我们在传输字节流前，先传输字符ZERO WIDTH NO-BREAK SPACE。
这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。
因此字符ZERO WIDTH NO-BREAK SPACE又被称作BOM。
Windows就是使用BOM来标记文本文件的编码方式的。
如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。
三、编程语言与编码
C、C++、Python2内部字符串都是使用当前系统默认编码
Python3、Java、C#内部字符串用Unicode保存
四、为什么会乱码?
乱码是个老问题，从上面我们知道，字符在保存时的编码格式如果和要显示的编码格式不一样的话，就会出现乱码问题。
我们的Web系统，从底层数据库编码、Web应用程序编码到HTML页面编码，如果有一项不一致的话，就会出现乱码。
所以，解决乱码问题说难也难说简单也简单，关键是让交互系统之间编码一致。
1. 容易产生的误解
误解一
对编码的误解在将“字节串”转化成“UNICODE 字符串”时，比如在读取文本文件时，或者通过网络传输文本时，容易将“字节串”简单地作为单字节字符串，采用每“一个字节”就是“一个字符”的方法进行转化。
而实际上，在非英文的环境中，应该将“字节串”作为 ANSI 字符串，采用适当的编码来得到 UNICODE 字符串，有可能“多个字节”才能得到“一个字符”。
通常，一直在英文环境下做开发的程序员们，容易有这种误解。
误解二
在 DOS，Windows 98 等非 UNICODE 环境下，字符串都是以 ANSI 编码的字节形式存在的。这种以字节形式存在的字符串，必须知道是哪种编码才能被正确地使用。这使我们形成了一个惯性思维：“字符串的编码”。
当 UNICODE 被支持后，Java 中的 String 是以字符的“序号”来存储的，不是以“某种编码的字节”来存储的，因此已经不存在“字符串的编码”这个概念了。只有在“字符串”与“字节串”转化时，或者，将一个“字节串”当成一个 ANSI 字符串时，才有编码的概念。
不少的人都有这个误解。第一种误解，往往是导致乱码产生的原因。第二种误解，往往导致本来容易纠正的乱码问题变得更复杂。
在这里，我们可以看到，其中所讲的“误解一”，即采用每“一个字节”就是“一个字符”的转化方法，实际上也就等同于采用 iso-8859-1 进行转化。因此，我们常常使用 bytes = string.getBytes(“iso-8859-1″) 来进行逆向操作，得到原始的“字节串”。然后再使用正确的 ANSI 编码，比如 string = new String(bytes, “GB2312″)，来得到正确的“UNICODE 字符串”。
2. 非 UNICODE 程序在不同语言环境间移植时的乱码
非 UNICODE 程序中的字符串，都是以某种 ANSI 编码形式存在的。如果程序运行时的语言环境与开发时的语言环境不同，将会导致 ANSI 字符串的显示失败。
比如，在日文环境下开发的非 UNICODE 的日文程序界面，拿到中文环境下运行时，界面上将显示乱码。如果这个日文程序界面改为采用 UNICODE 来记录字符串，那么当在中文环境下运行时，界面上将可以显示正常的日文。
由于客观原因，有时候我们必须在中文操作系统下运行非 UNICODE 的日文软件，这时我们可以采用一些工具，比如，南极星，AppLocale 等，暂时的模拟不同的语言环境。
3. 网页乱码问题
3.1 提交字符串
当页面中的表单提交字符串时，首先把字符串按照当前页面的编码，转化成字节串。然后再将每个字节转化成 “%XX” 的格式提交到 Web 服务器。比如，一个编码为 GB2312 的页面，提交 “中” 这个字符串时，提交给服务器的内容为 "%D6%D0"。
在服务器端，Web 服务器把收到的 "%D6%D0" 转化成 [0xD6, 0xD0] 两个字节，然后再根据 GB2312 编码规则得到 “中” 字。
在 Tomcat 服务器中，request.getParameter() 得到乱码时，常常是因为前面提到的“误解一”造成的。默认情况下，当提交 "%D6%D0" 给 Tomcat 服务器时，request.getParameter() 将返回 [0x00D6, 0x00D0] 两个 UNICODE 字符，而不是返回一个 “中” 字符。因此，我们需要使用 bytes = string.getBytes(“iso-8859-1″) 得到原始的字节串，再用 string = new String(bytes, “GB2312″) 重新得到正确的字符串 “中”。
3.2 页面乱码
检查你的文件存储编码是否和 meta 声明的一致，假如你的文件是按照 utf-8 编码存储，但是 meta 却声明为 gb2312 ，将导致乱码。
解决办法：将页面存储编码和 meta 声明保持一致。用记事本打开文件，“另存为”，下面有个选项是“编码”，选择和 meta 声明一致的编码方式。(提示：meta 的编码声明要放在 title 标签前面，否则容易导致页面空白。)
4. 数据库读乱码问题
通过数据库客户端（比如 ODBC 或 JDBC）从数据库服务器中读取字符串时，客户端需要从服务器获知所使用的 ANSI 编码。当数据库服务器发送字节流给客户端时，客户端负责将字节流按照正确的编码转化成 UNICODE 字符串。
如果从数据库读取字符串时得到乱码，而数据库中存放的数据又是正确的，那么往往还是因为前面提到的“误解一”造成的。解决的办法还是通过 string = new String( string.getBytes(“iso-8859-1″), “GB2312″) 的方法，重新得到原始的字节串，再重新使用正确的编码转化成字符串。
4.1 MySQL乱码问题深层分析
概述
MySQL 的乱码问题(不仅仅包括中文乱码，也包括其它语言的乱码，以下称之为乱码问题)只存在于4.1及其以上版本。4.1之前的 MySQL 不支持多语言，所以它会将你给它的数据“原封不动”地保存，再“原封不动”地读出来。从字节的角度来看，数据在这一过程中不会产生任何变化，因此不会有乱码。
4.1及以后的版本开始支持多语言，这个所谓的多语言，就是在输入输出时 MySQL 会替你做编码转换。而这个转换规则就是由客户端编码和服务器端编码来决定的。
编码转换的规则就是，在输入数据时将编码由“客户端编码”转换为“服务器端编码”，输出时将数据由“服务器端编码”转换为“客户端编码”。
乱码产生原因
MySQL 字符编码是版本4.1引入的，支持多国语言，而且一些特性已经超过了其它大多数数据库管理系统。正因为这一特性才导致 MySQL 的乱码问题。
字符集是一套符号和编码。校对规则是在字符集内用于比较字符的一套规则。让我们使用一个假想字符集的例子来区别清楚。
假设我们有一个字母表使用了四个字母：‘A’、‘B’、‘a’、‘b’。我们为每个字母赋予一个数值：‘A’=0，‘B’= 1，‘a’= 2，‘b’= 3。字母‘A’是一个符号，数字0是‘A’的编码，这四个字母和它们的编码组合在一起是一个字符集。
假设我们希望比较两个字符串的值(在if……else语句中我们经常做值的比较)：‘A’和‘B’。比较的最简单的方法是查找编码：‘A’为0，‘B’为1。因为0 小于1，我们可以说‘A’小于‘B’。我们做的仅仅是在我们的字符集上应用了一个校对规则。校对规则是一套规则(在这种情况下仅仅是一套规则)：“对编码进行比较。”我们称这种全部可能的规则中的最简单的校对规则为一个binary(二元)校对规则。
但是，如果我们希望小写字母和大写字母是等价的，应该怎样?那么，我们将至少有两个规则：(1)把小写字母‘a’和‘b’视为与‘A’和‘B’等价;(2)然后比较编码。我们称这是一个大小写不敏感的校对规则。比二元校对规则复杂一些。
在实际生活中，大多数字符集有许多字符：不仅仅是‘A’和‘B’，而是整个字母表，有时候有许多种字母表，或者一个东方的(比如中文、日文、韩文、藏文、泰文等等)使用上千个字符的书写系统，还有许多特殊符号和标点符号。并且在实际生活中，大多数校对规则有许多个规则：不仅仅是大小写不敏感，还包括重音符不敏感(“重音符” 是附属于一个字母的符号，象德语的‘?’符号)和多字节映射(例如，作为规则‘?’=‘OE’就是两个德语校对规则的一种)。
(以上摘自MySQL 5.1 手册。更多内容可参见：http://dev.mysql.com/doc/refman/5.1/zh/charset.html)
MySQL 4.1.x开始支持以下这些事情
使用多种字符集(Character Set)来存储字符
使用多种校对规则(Collation)来比较字符串
在同一台服务器、同一个数据库或甚至在同一个表中使用不同字符集或校对规则来混合字符串
允许定义任何级别的字符集和校对规则
MySQL 4.1及以上版本的字符集支持(Character Set Support)有两个方面：字符集(Character Set)和校对规则(Collation)。 字符集和校对规则有4个级别的默认设置：服务器(server)，数据库(database)，数据表(table)和连接(connection)。
MySQL 中是根据下面几个变量确定服务器端和客户端用的什么字符集：
character_set_client 客户端字符集
character_set_connection 客户端与服务器端连接采用的字符集
character_set_results SELECT查询返回数据的字符集
character_set_database 数据库采用的字符集
MySQL的字符集处理是这样的：
1、发送请求。
1)客户端发送请求到服务器端。
2)服务器端会把请求的数据从客户端字符集(character_set_client)转成服务器连接字符集(character_set_connection)。
3)然後服务器会检测存储区域(table，column)的字符集，然后把数据从连接字符集(character_set_connection)转为存储区域(table，column)的字符集，然後再存储或者查询。
2、返回请求。
1)服务器将存储区域(table，column)的字符集转换成服务器连接字符集(character_set_connection)。
2)将服务器连接字符集(character_set_connection)转换成结果字符集(character_set_results)，再发送到客户端。
例如，我建立一个字符集为 gbk 的数据库(服务器端)。(MySQL 4.1 开始，在建立数据库时要指定它的字符集和校对规则，不指定就用默认的字符集和校对规则。)
连接数据库的程序(客户端)使用 gb2312 字符集(如 windows 命令行下使用 MySQL ，或者 PHP 连接MySQL )，那么在执行 insert 命令时，insert 的字符串将做一个 gb2312 到 gbk 的转换。而 select 时，数据库中保存的数据会先经过 gbk 到 gb2312 的转换之后再给你(结果集)。
好，那么为什么升级3.23(或4.0)到4.1时会乱码?举个例子说明。
例如3.23的数据库中保存的是gbk编码的数据。升级之前我将这些数据导出保存到文件里，这个文件的编码当然也是gbk的(因为3.23不支持多语言，不会对数据进行转换，也就是前面说的“原封不动地保存，原封不动地读出”)。
然后我在4.1中建立一个数据库，字符集为A;客户端字符集为B。将刚才的gbk数据导入。
1)A=gbk，B=gbk
导入数据时数据不会被转换;读出时需要set names gbk(set name命令下面将讲解)。
2)A=latin1，B=gbk
导入数据会进行gbk->latin1的转换，可能会丢失数据，产生乱码。
3)A=gbk，B=latin1
导入数据会进行latin1->gbk转换，可能会产生乱码。
4)A=latin1，B=latin1
导入数据时不会进行转换;读出时不需要set names gbk 。
大家可以看到，上面1)、4)才是正确的做法，即让A和B使用同样的字符集才不会乱码。
解决方案
了解了 MySQL 4.1.x 以上版本字符集处理的过程，我们就知道了怎么从原理上解决这个问题。
思路：让服务器端和客户端的字符集保持一致。
服务器端的编码是由字符集(Character Set)和校对规则(Collation)决定的。
上面提到，MySQL 中是根据下面几个变量确定服务器端和客户端用的什么字符集：
character_set_client 客户端字符集
character_set_connection 客户端与服务器端连接采用的字符集
character_set_results SELECT查询返回数据的字符集
character_set_database 数据库采用的字符集
也就是说，只要保证这几个变量采用一致的字符集，就不会出现乱码问题了。
查看系统的字符集用下面的命令：
1 mysql> SHOW VARIABLES LIKE ‘character_set_%’;
2 +————————–+—————————————–+
3 | Variable_name | Value |
4 +————————–+—————————————–+
5 | character_set_client | utf8 |
6 | character_set_connection | utf8 |
7 | character_set_database | utf8 |
8 | character_set_filesystem | binary |
9 | character_set_results | utf8 |
10 | character_set_server | utf8 |
11 | character_set_system | utf8 |
12 | character_sets_dir | E:\usr\MySQL Server 5.0\share\charsets\ |
13 +————————–+—————————————–+
14 8 rows in set (0.00 sec)
15
可以看到，我的这几个变量都是一致的。但如果不一致呢?网上许多教程告诉你“你set names下就解决了”。
那么set names是什么呢? set names实际上就是同时设置了 character_set_client ，character_set_connection和 character_set_results 这三个系统变量。
例如在mysql命令行上输入 set names ‘gbk’ 命令等同于：
SET character_set_client = gbk;
SET character_set_connection = gbk;
SET character_set_results = gbk;
很多情况下，这样设置了之后就能把乱码问题解决了。但是还是不能完全避免出现乱码的可能，为什么呢?
因为character_set_client ，character_set_connection 这两个变量仅用于保证与 character_set_database 编码的一致，而 character_set_results 则用于保证 SELECT 返回的结果与程序的编码一致。
例如，你的数据库(character_set_database)用的是 utf8 的字符集，那么你就要保证 character_set_client ，character_set_connection 也是utf8的字符集。
而你的程序也许采用的并不是utf8 ，比如你的程序用的是gbk ，那么你若把 character_set_results 也设置为 utf8 的话就会出现乱码问题。此时你应该把 character_set_results 设置为gbk。这样就能保证数据库返回的结果与你的程序的编码一致。
到此应该就可以解决绝大多数我们遇到的乱码问题了，另外还必须强调的是，有时候乱码的出现有可能是以上几种原因混合造成的。
总而言之，我们应当尽量的保证数据库中的数据是正确的，就是客户端到服务器端或者服务器端到客户端转换的过程中不要产生乱码，那么问题处理起来就相对简单了。
总结
为便于大家记忆，总结为以下四点：
1、要保证发送的数据与数据库的字符集一致，即 character_set_client，character_set_connection 与character_set_database 一致。
2、要保证数据库中存储的数据与数据库编码一致，即数据的编码与character_set_database一致。
3、要保证 SELECT 的返回与程序的编码一致，即 character_set_results 与程序(PHP、Java等)编码一致。
4、要保证程序编码与浏览器编码一致，即程序编码与一致。
4.2 例子解析
错误读出
现象：一个已经存在数据的MySQL数据库，该数据库的数据用系统中其它软件、网页查看均正常，使用MySQLcc之类的客户端查看也正常，可是在新写的网页中总是显示乱码。
分析：其它系统都可以正常查看数据，说明数据本身是没有问题的。在网页中显示乱码，一定是网页的编码字符集和获取到的数据的编码字符集不一至。比如数据库的字符集是UTF8的，而网页的字符集是gb2312的，那么网页就会把UTF8编码的字体串当作gb2312的来处理，结果产生乱码。
解决办法：在连接数据库时，设定连接字符集，使连接字符集和当前网页或客户端程序使用的字符集一致。可以使用MySQL的Set Names指令设定连接字符集。假设网页的字体集为gb2312。在连接MySQL后，在连接上执行如下SQL语句：
Set Names ‘gb2312’
在以后所有这个连接上的查询，MySQL都会自动把数据库中的数据转换成gb2312编码格式传过来。
错误写入
现象：一个网页或程序向一个MySQL数据库中写数据，写完后，这个网页或程序自己可以正常读取数据，而从其它客户端或网页中读取数据都是乱码。
分析：其它的正常的客户端出现乱码，说明数据库中的字符编码不对。写数据的那个网页能正常读取，是因为写和读都用了错误的编码格式，将错就错，反而能读出正确的数据了。比如数据库中设定的字符集为UTF8，而网页使用gb2312编码执行了插入数据的SQL，那么MySQL就会把这些gb2312的编码当成是UTF8的编码写进数据库。当其它客户端访问数据时，会按系统的设定，以UTF8 格式读取数据，而数据其实是使用gb2312编码的，结果就出现了乱码。只有写数据的那个网页会把这些数据当成gb2312的，也只有那个网页能正常显示数据。
解决办法：同第一条，即：使用Set Names指令设定连接字符集。
在设定了连接字符体的连接上执行数据操作，所有的数据都将被MySQL自动、正确地转换为数据库中设定的编码格式保存。
通过以上两点，我们可以看到，只要在连接MySQL时，正确地设定了字符集，无论数据库本身是使用什么格式编码的，都能得到正确的结果。也许有人会以为写数据时设定的字符集必需和读数据时一致，事实上完全没有必要。程序所要做的只是告诉 MySQL，目前操作MySQL使用的是什么字符集即可。因为MySQL会自动完成如下的转换工作：
写数据库时用的字符集–>存诸数据的字符集–>读取数据的字符集。
笔者以为MySQL对多语言字符集的处理是非常优秀的，并且每次建立到MySQL的连接都会立刻使用Set Names设定字符集，然而最近还是出现了一回乱码，如下面所述。
无知的程序包
现象：使用C#编程，使用MySQL提供的连接程序库包访问数据库，使用 MySqlConnection类连接数据库，连接之后立刻调用Set Names设定连接字符串，然后使用MySqlCommand类执行SQL，并使用MySqlDataReader读取数查询结果。然而，当我调用 MySqlDataReader的成员方法GetString获取数据的时候，发现得到的全是乱码。百思不得其解。
分析：经仔细检查，确信问题没有出在MySQL连接上面，这时我想到了C#中对 string类型的处理。在C#中字符串和C/C++中有很大不同。在C/C++中一个字符就是一个字节，而在C#中，按不同的编码格式，一个字符也可以是多个字节的。比如”啊”就是一个字符，如果一个字符串s=”啊”; 那么s的Length属性为1，而不是C/C++中的2。我想MySQL程序包也许并不知道连接上传过来的字符是什么编码的，它因为无知，所以只是按单字节字符把这些数据组织成一个string，这个生成的string就是我得到的乱码。事实上也的确是这样。
解决办法：把这些数据重新组织起来，然后使用正确的编码方法重新生成string。C#中System.Text包内的Encoding类提供了字符集的编/解码方法。
1）首先还是设定连接字符集，以确认收到的字符的编码方式。
2）把GetString得到的字符串转换到byte数组中。
3）使用Systec.Text.Encoding包中相应字符集的解码方法GetString得到新的字符串。
为了通用性，我们使用System.Text.Encoding的默认字符集。连接数据库时，设置数据库连接字符集使用的SQL指令strSetCharset为如下值：
string strSetCharset = “Set Names ” + System. Text. Encoding .Default. HeaderName;
在获取数据时，使用下面的函数得到真正的字符串：
private string DBStringToNormal(string dbStr)
{
byte[] str = new byte[dbStr.Length];
for (int i = 0; i < dbStr.Length; ++i)
str[i] = (byte)(dbStr[i]);
return System.Text.Encoding.Default.GetString(str, 0, dbStr.Length);
}
5 电子邮件乱码问题
当一段 Text 或者 HTML 通过电子邮件传送时，发送的内容首先通过一种指定的字符编码转化成“字节串”，然后再把“字节串”通过一种指定的传输编码（Content-Transfer-Encoding）进行转化得到另一串“字节串”。比如，打开一封电子邮件源代码，可以看到类似的内容：
| Content-Type: text/plain; charset=”gb2312″ Content-Transfer-Encoding: base64 sbG+qcrQuqO17cf4yee74bGjz9W7 EDQoNCg== |
最常用的 Content-Transfer-Encoding 有 Base64 和 Quoted-Printable 两种。在对二进制文件或者中文文本进行转化时，Base64 得到的“字节串”比 Quoted-Printable 更短。在对英文文本进行转化时，Quoted-Printable 得到的“字节串”比 Base64 更短。
邮件的标题，用了一种更简短的格式来标注“字符编码”和“传输编码”。比如，标题内容为 “中”，则在邮件源代码中表示为：
| // 正确的标题格式 Subject: =?GB2312?B?1tA=?= |
其中，
第一个“=?”与“?”中间的部分指定了字符编码，在这个例子中指定的是 GB2312。
“?”与“?”中间的“B”代表 Base64。如果是“Q”则代表 Quoted-Printable。
最后“?”与“?=”之间的部分，就是经过 GB2312 转化成字节串，再经过 Base64 转化后的标题内容。
如果“传输编码”改为 Quoted-Printable，同样，如果标题内容为 “中”：
| // 正确的标题格式 Subject: =?GB2312?Q?=D6=D0?= |
如果阅读邮件时出现乱码，一般是因为“字符编码”或“传输编码”指定有误，或者是没有指定。比如，有的发邮件组件在发送邮件时，标题 “中”：
| // 错误的标题格式 Subject: =?ISO-8859-1?Q?=D6=D0?= |
这样的表示，实际上是明确指明了标题为 [0x00D6, 0x00D0]，即 “ÖД，而不是 “中”。
五、有没有万金油?
在如此多种编码和字符集弄的我们眼花缭乱的情况下，我们只需选择一种兼容性最好的编码方式和字符集，让它成为我们程序子系统之间交互的编码契约，那么从此恼人的乱码问题即将远离我们而去 — 这种兼容性最好的编码就是UTF-8!
毕竟GBK/GB2312是国内的标准，当我们大量使用国外的开源软件时，UTF-8才是编码界最通用的语言。
我们来总结一下这几种编码格式所需要的字节个数以及各自的优缺点。
| 编码范围 | UTF-8 | UTF-16 | UTF-32 | GB18030 * |
| U+000000 – U+00007F | 1 | 2 | 4 | 1 |
| U+000080 – U+00009F U+0000A0 – U+0003FF U+000400 – U+0007FF | 2 | 2 | 4 | 2 |
| U+000800 – U+003FFF U+004000 – U+00FFFF | 3 | 2 | 4 | 2 |
| U+010000 – U+03FFFF U+040000 – U+10FFFF | 4 | 4 | 4 | 4 |
备注：GB18030并不是真正意义上的Unicode编码，仅作参考
UTF-8、UTF-16和UTF-32都可以表示有效编码空间(U+000000-U+10FFFF)内的所有Unicode字符。
使用UTF-8编码时ASCII字符只占1个字节，存储效率比较高，适用于拉丁字符较多的场合以节省空间。
对于大多数非拉丁字符（如中文和日文）来说，UTF-16所需存储空间最小，每个字符只占2个字节。
Windows NT内核是Unicode（UTF-16），采用UTF-16编码在调用系统API时无需转换，处理速度也比较快。
采用UTF-16和UTF-32会有LE和BE之分，而UTF-8则没有字节顺序问题，所以UTF-8适合传输和通信。
UTF-32采用4字节编码，一方面处理速度比较快，但另一方面也浪费了大量空间，影响传输速度，因而很少使用。
六、实例
下面，举一个实例。
打开“记事本”程序Notepad.exe，新建一个文本文件，内容就是一个“严”字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8编码方式保存。
然后，用文本编辑软件UltraEdit中的“十六进制功能”，观察该文件的内部编码方式。
1）ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。
2）Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。
3）Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。
4）UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。
七、参考文档
http://webcenter.hit.edu.cn/articles/2009/04-01/04193356.htm
http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html
http://www.regexlab.com/zh/encoding.htm
http://tech.ddvip.com/2008-11/122794544296212.html
http://www.cnblogs.com/baoquan/archive/2007/12/04/981721.html
字符集和编码的历史：http://www.javaeye.com/topic/398782
http://hi.baidu.com/xlnan/blog/item/612c0250f968bd6b853524ad
http://hi.baidu.com/hailwater/blog/item/85ea38e7636de325b93820ab
转载请注明来源：http://www.madcn.net/?p=604
1828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
