Windows服务器MySQL中文乱码的解决方法

在配置文件中默认采用的字符集，因此如果指定了character_set_server默认就会采用它，这样其他层次都不指定的话依次继承。

其他的，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的——除非数据库的使用者用错了。】

 3/5   首页 上一页 1 2 3 4 5 下一页 尾页