mysql 惊魂记

前几天配置好开发环境后 先写了一个很简单的登陆界面 依次出现了如下问题：

（1）request接受到的中文参数都是乱码：

原因以及解决办法：参见网页http://lavasoft.blog.51cto.com/62575/274527/     可知默认表单传递使用的编码方式为ISO-8859-1 

因此解析的时候要进行一次编码转换    

                String param = request.getParameter("param");
                String x = new String(param.getBytes("ISO-8859-1"),"GBK");

（2）解决了以上问题之后

    虽然接受的参数是中文，但是进行验证的时候就是只有英文能通过，但是中文怎么都验证不过，查询不到结果

    更神奇的是select 语句在phpmyadmin中执行query都有结果

    因此怀疑是mysql数据库字符编码的问题：

   以下两篇博文是我见到的介绍非常好的：

   http://www.cnblogs.com/discuss/articles/1862248.html

   http://blog.csdn.net/ithomer/article/details/5130789

  现将重点摘录如下：

基本概念

• 字符(Character)是指人类语言中最小的表义符号。例如’A'、’B'等；
• 给定一系列字符，对每个字符赋予一个数值，用数值来代表对应的字符，这一数值就是字符的编码(Encoding)。例如，我们给字符’A'赋予数值0，给字符’B'赋予数值1，则0就是字符’A'的编码；
• 给定一系列字符并赋予对应的编码后，所有这些字符和编码对组成的集合就是字符集(Character Set)。例如，给定字符列表为{’A',’B'}时，{’A'=>0, ‘B’=>1}就是一个字符集；
• 字符序(Collation)是指在同一字符集内字符之间的比较规则；
• 确定字符序后，才能在一个字符集上定义什么是等价的字符，以及字符之间的大小关系；
• 每个字符序唯一对应一种字符集，但一个字符集可以对应多种字符序，其中有一个是默认字符序(Default Collation)；
• MySQL中的字符序名称遵从命名惯例：以字符序对应的字符集名称开头；以_ci(表示大小写不敏感)、_cs(表示大小写敏感)或_bin(表示按编码值比较)结尾。例如：在字符序“utf8_general_ci”下，字符“a”和“A”是等价的；

MySQL字符集设置

• 系统变量：
– character_set_server：默认的内部操作字符集
– character_set_client：客户端来源数据使用的字符集
– character_set_connection：连接层字符集
– character_set_results：查询结果字符集
– character_set_database：当前选中数据库的默认字符集
– character_set_system：系统元数据(字段名等)字符集
– 还有以collation_开头的同上面对应的变量，用来描述字符序。

• 用introducer指定文本字符串的字符集：
– 格式为：[_charset] ’string’ [COLLATE collation]
– 例如：
       SELECT _latin1 ’string’;
       SELECT _utf8 ‘你好’ COLLATE utf8_general_ci;
– 由introducer修饰的文本字符串在请求过程中不经过多余的转码，直接转换为内部字符集处理。

MySQL中的字符集转换过程

1. MySQL Server收到请求时将请求数据从character_set_client转换为character_set_connection；
2. 进行内部操作前将请求数据从character_set_connection转换为内部操作字符集，其确定方法如下：
       - 使用每个数据字段的CHARACTER SET设定值；
       - 若上述值不存在，则使用对应数据表的DEFAULT CHARACTER SET设定值(MySQL扩展，非SQL标准)；
       - 若上述值不存在，则使用对应数据库的DEFAULT CHARACTER SET设定值；
       - 若上述值不存在，则使用character_set_server设定值。

3. 将操作结果从内部操作字符集转换为character_set_results。

 
  我们现在回过头来分析下我们产生的乱码问题：
          a 我们的字段没有设置字符集，因此使用表的数据集
          b 我们的表没有指定字符集，默认使用数据库存的字符集
          c 我们的数据库在创建的时候没有指定字符集，因此使用character_set_server设定值
          d 我们没有特意去修改character_set_server的指定字符集，因此使用mysql默认
          e mysql默认的字符集是latin1，因此，我们使用了latin1字符集，而我们character_set_connection的字符集是UTF-8，插入中文乱码也再所难免了。

常见问题解析
• FAQ-1 向默认字符集为utf8的数据表插入utf8编码的数据前没有设置连接字符集，查询时设置连接字符集为utf8
     – 插入时根据MySQL服务器的默认设置，character_set_client、character_set_connection和character_set_results均为latin1；
     – 插入操作的数据将经过latin1=>latin1=>utf8的字符集转换过程，这一过程中每个插入的汉字都会从原始的3个字节变成6个字节保存；
     – 查询时的结果将经过utf8=>utf8的字符集转换过程，将保存的6个字节原封不动返回，产生乱码。参考下图： 
• 向默认字符集为latin1的数据表插入utf8编码的数据前设置了连接字符集为utf8（我们遇到的错误就是属于这一种）
     – 插入时根据连接字符集设置，character_set_client、character_set_connection和character_set_results均为utf8；
     --插入数据将经过utf8=>utf8=>latin1的字符集转换，若原始数据中含有\u0000~\u00ff范围以外的Unicode字符，会因为无法在latin1字符集中表示而被转换为“?”(0×3F)符号，以后查询时不管连接字符集设置如何都无法恢复其内容了。转换过程如下图： 

 
检测字符集问题的一些手段
    • SHOW CHARACTER SET;
    • SHOW COLLATION;
    • SHOW VARIABLES LIKE ‘character%’;
    • SHOW VARIABLES LIKE ‘collation%’;
    • SQL函数HEX、LENGTH、CHAR_LENGTH
    • SQL函数CHARSET、COLLATION

MySQL处理连接时，外部连接发送过来的SQL请求会根据以下顺序进行转换：
character_set_client           //客户连接所采用的字符集
|
character_set_connection  //MySQL连接字符集
|
character_set_database    //数据库所采用的字符集（表，列）
|
character_set_results        //客户机显示所采用的字符集


一. 产生乱码的根本原因在于：
1.客户机没有正确地设置client字符集，导致原先的SQL语句被转换成connection所指字符集，而这种转换，是会丢失信息的，如果client是utf8格式，那么如果转换成gb2312格式，这其中必定会丢失信息，反之则不会丢失。一定要保证connection的字符集大于client字符集才能保证转换不丢失信息。
2. 数据库字体没有设置正确，如果数据库字体设置不正确，那么connection字符集转换成database字符集照样丢失编码，原因跟上面一样。

二.为什么set names 'gb2312'就可以了呢
set names 'gb2312'相当于这三条语句:
set character_set_client = gb2312;
set character_set_connection = gb2312;
set character_set_results = gb2312;
这样做的话，上述产生乱码的原因1就不存在了，因为编码格式都统一了，但是这样做并不是万金油。原因有：
1.你的client不一定是用gb2312编码发送SQL的，如果编码不是gb2312那么转换成gb2312就会产生问题。
2.你的数据库中的表不一定是gb2312格式，如果不是gb2312格式而是其他的比如说latin1，那么在存储字符集的时候就会产生信息丢失。

综上，终极解决方案如下:
1.首先要明确你的客户端时候何种编码格式，这是最重要的（IE6一般用utf8，命令行一般是gbk，一般程序是gb2312)
2.确保你的数据库使用utf8格式，很简单，所有编码通吃。
3.一定要保证connection字符集大于等于client字符集，不然就会信息丢失，比如： latin1 < gb2312 < gbk < utf8，若设置set character_set_client = gb2312，那么至少connection的字符集要大于等于gb2312，否则就会丢失信息
4.以上三步做正确的话，那么所有中文都被正确地转换成utf8格式存储进了数据库，为了适应不同的浏览器，不同的客户端，你可以修改character_set_results来以不同的编码显示中文字体，由于utf8是大方向，因此web应用是我还是倾向于使用utf8格式显示中文的。

但是以上文章介绍的修改my.cnf的方法都不是很好，这个下一节再细表。

我找到的最好的配制方法是：

http://stackoverflow.com/questions/3513773/change-mysql-default-character-set-to-utf-8-in-my-cnf

[client]default-character-set=utf8[mysql]default-character-set=utf8[mysqld]collation-server = utf8_unicode_ciinit-connect='SET NAMES utf8'character-set-server = utf8

（3）修改了my.cnf 之后对mysql进行重启 结果居然重启失败！@！！！！！

查看了以下错误日志

作为mysql新手，再查资料中学到的一些小知识包括（mysql的错误日志的位置/var/log/mysql/error.log中）

得到的错误信息如下：

InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.

141013 20:49:37 [ERROR] Plugin 'InnoDB' init function returned error.
141013 20:49:37 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
141013 20:49:37 [ERROR] Unknown/unsupported storage engine: InnoDB
141013 20:49:37 [ERROR] Aborting

mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

查了将近三个小时的资料，试了无数的方法都没有效果，试过的方法包括：

（1）杀死mysql进程重启 无效

（2）传闻说因为空间小。。。。

（3）使用/usr/local/mysql/bin/mysql_install_db --user=mysql  初始化mysql

（4）还有说重装mysql的  我居然信了～～～对了 提一下http://www.blogjava.net/yjhmily/articles/336926.html 介绍的卸载mysql方法非常不错

  重装后还是不行～～～我也是醉了。。。

（5）.。。

总之试了很多方法 后来看了将近300页的mysql的文档  才意识到问题可能是配置文件的问题 

我是apt-get方式安装的mysql  my.cnf默认的配置里没有配置InnoDB存储引擎 

所以会造成无法使用

因此需要修改 my.cnf 增加对InnoDB的支持

我的配置如下：

innodb_data_home_dir = /var/lib/mysql
innodb_data_file_path = ibdata1:12M:autoextend
innodb_log_group_home_dir = /var/lib/mysql
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 56M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

没有配置的情况下innodb_data_home_dir默认为/

所以会造成以上的错误

配置后出现了错误：log file /var/lib/mysql/ib_logfile0 is of different size 0 5242880 bytes

解决办法：参见http://www.linuxidc.com/Linux/2012-05/61192.htm

在你修改my.cnf的innodb_log_file_size参数前，请先停止mysql服务程序的运行（mysql的停止没有出现任何错误），并把/var/lib/mysql目录下的ib_logfile0、ib_logfile1、ib_logfile2等之类的文件移除到一个安全的地方（旧日志文件的保留是为了防止意外的出现），以便Mysql重启后可以将新的ib_logfile0之类日志文件生成到/var/lib/mysql目录下。如果没有什么意外，旧的日志文件可以删除。

按此办法处理后，重启成功。

登陆程序验证成功！！！！

六个小时的奋战啊。。。。。。。。。。。。