mysql中文乱码的一些解决方案(2)_MySQL教程

推荐：sql写注册表语句例句
首先开启沙盘模式： exec master..xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0\Engines','SandBoxMode','REG_DWORD',1 读注册表 exec master..xp_regread 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon','Userinit

　　其他的，character_set_filesystem：把操作系统上的字符转换成此字符集，即把character_set_client转换成character_set_filesystem，默认为binary则不转换，character_set_system：此变量总是utf8，为存储系统元字符的字符集，如表名、列名、用户名等，character_set_dir：很明显是指示一个目录的变量，打开这个目录，里边存放的是mysql的各种用于编码字符集的xml格式文件。以上三个值在解决乱码问题时基本可忽视。

　　好，转换流程和各变量的含义清楚了，就要搞清楚哪些字符集编码之间可以转换，能转换可能也是在一定编码范围内的字符能转换，不至于出现乱码甚至损坏。损坏了就再也无法正确显示了，哪怕设置是正确的，还原是还原不回来的。当然关于字符之间的转化情况很多，字符集有那么多种，随便两个之间都可以转换一下试试，不能一一列举，可以参考这篇文章：http://www.imcjd.com/?p=1324，它针对经常用到的字符转换作了一些转换比较和测试。

　　其中，可以了解到，完全匹配的转换是肯定没有问题的，比如，gbk->gbk，utf8->utf8，latin1->latin1;转换为单字节编码的latin1也没问题，比如gbk->latin1、utf8->latin1;单字节编码(latin1)转为其他在某些编码某些范围内可能会出现转换不全，比如latin1->gbk(很特殊的中文)，或者编码长度改变，比如latin1->utf8，变为2、3等字节数。

　　下面引用另一篇文章(http://hi.baidu.com/cuttinger/item/f4e79726a60ab450c28d59da)中的一段。

　　【Latin1是一种很常见的字符集，这种字符集是单字节编码，向下兼容ASCII，其编码范围是0x00-0xFF，0x00-0x7F之间完全和ASCII一致，0x80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。很明显，Latin1覆盖了所有的单字节，因此，可以将任意字符串保存在latin1字符集中，而不用担心有内容不符合latin1的编码规范而被抛弃。——gbk和utf8是多字节编码，没有这种特性。

　　mysql使用者经常利用Latin1的这种全覆盖特性，将其它类型的字符串，gbk,utf8,big5等，保存在latin1列中。保存的过程中没有数据丢失，只要原样取出来，便又是合法的gbk/utf8/big字符串。如果将gbk字符串保存在utf8列中，则gbk字符串中那些不符合utf8编码格式的内容，会被抛弃，保存的内容无法原样取出，数据实际上遭到了破坏。

　　综上，如果我们看到一个字段的字符集是latin1的，那么，他保存的可能是任何编码的字符串;而一个字段的字符集是utf8或者gbk的，那么他保存的就应该是utf8或gbk的——除非数据库的使用者用错了。】

　　我没有深入学习过utf8、gbk编码的细节，极可能说的不准确，只知道简单的ASCII编码(-_-)，但是可以了解个全局情况。从上面来看，latin1的单字节编码方式很有用，其他的编码可以转换为它再转回去而不至于丢失内容。所谓单字节编码就是挨着一个个来，我理解是，比如圣诞节到了，你要送妹子一箱苹果，为制造浪漫，商铺提供两种包装方式，一是按个数来，即单个苹果包装进一个盒子，来一个包装一个，这样，妹子在拆完所有的盒子后完完整整的可以还原为一个个完整的和一箱完好无损的苹果，二是按重量来，每个盒子限重2两、3两、6两，这样在包装时，若刚好重3两的当然可以完整的放进一个盒子，但是若不够或者多了，勉不了要切开苹果，或者再往盒子中添加其他的部分苹果，这样的话，妹子再无论怎样拆开盒子，都会得到一箱残缺不堪的苹果了，因为你在按照这种包装方式进行时，已经破坏了单个苹果的完整性，现在还原不回来了~我们的字符集编码转换就是在做这种重新包装的工作，latin1恰好就像单个苹果包装，而utf8就像第二种方式。

　　而刚才说的完全匹配的情况是，你去买一箱苹果，箱子里边的所有苹果重量已经恰好要么是2两，要么是3两或6两的，这样再按重量包装时当然就恰好分配了，得到的仍然是完整的苹果。

　　所以说白了，两种可行的方式是：

　　1. 所有变量均设置成latin1(set names latin1;)，这样，即便我们所使用的编辑客户端编码多样(gbk或utf8)，最终可以得到正确结果;

　　2. 所有的设置成gbk或者gb2312(国标编码，只用于简体中文)，采用完全匹配;

　　3. 针对中间的转换过程，比如gbk输入，将character_set_client、character_set_connection视为latin1，character_set_database设为gb2312，建表时定字符集为gb2312，character_set_results也可以定为gb2312，当然这只是鸡肋，本质上还是用了latin1，gbk转latin1再转gb2312时只适用于简体。

　　最后，关于字符集校对规则，只了解一点。在我们设置mysql字符集时，mysql会自动给一个对应的校对规则，比如设置charset为utf8，默认的collation就是utf8_general_ci，gb2312字符集对应gb2312_chinese_ci，mysql命令查看所有校对规则是show collation，查看某一对应字符集的校对规就是show collation like 'utf8%'了。

　　字符集校对是一种对使用当前字符集时采用的排序、对比方式，即便同一种字符集，在不同的地区也是不同的对比方式，所以才有校对这么一说，比如utf8_general_ci，这个ci就是case insensitive，即大小写不敏感，采用它校对时，查询某字段值匹配时，大小写的记录都会出现，当然还有其他的规则，utf8打印出来一大坨，不细研究了~

分享：sql检测是否为SA权限语句
检测是否为SA权限 and 1=(select IS_SRVROLEMEMBER('sysadmin'));-- And char(124)%2BCast(IS_SRVROLEMEMBER(0x730079007300610064006D0069006E00) as varchar(1))%2Bchar(124)=1 --