完全解決mysql中文亂碼

mysql是咱們項目中很是經常使用的數據型數據庫。可是由於咱們須要在數據庫保存中文字符，因此常常遇到數據庫亂碼狀況。下面就來介紹一下如何完全解決數據庫中文亂碼狀況。

1、中文亂碼

1.1、中文亂碼

 create table user(name varchar(11));    # 建立user表
 insert into table user("carl");         # 添加數據
 select * from user;


insert into user value("哈哈");
1
沒法插入中文字符：


1.2、查看錶字符編碼

mysql> show create table user \G;
*************************** 1. row ***************************
       Table: user
Create Table: CREATE TABLE `user` (
  `name` varchar(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

咱們能夠看到表的默認字符集是latin1. 
因此咱們在建立表的時候就須要指定表的字符集:

 create table user(name varchar(11)) default charset=utf8; 
1
這樣在Linux裏面能夠訪問而且能夠插入與訪問這個表了。



1.3、數據庫與操做系統編碼

雖然在服務器端能夠顯示中文正常，可是在客戶端可能會顯示亂碼。由於咱們的服務器是UTF8。


並且數據庫的編碼也存在問題。



這裏咱們能夠看character_sert_database與character_set_server的字符集都是latin1.那麼在mysql數據庫中，server,database,table的字符集都默認是latin1.下面咱們就來看看如何解決mysql亂碼狀況。

2、mysql設置變量的範圍

2.1、session範圍

查看數據庫編碼：

show variables like '%char%';


修改字符編碼：

set character_set_server=utf8;
set character_set_database=utf8;
show variables like '%char%';

咱們能夠看到字符集已經修改爲都是utf8了。可是這裏有一個問題，那就是咱們從新打開一個命令窗口而後查看數據編碼就會出現下面的畫面：



2.2、global範圍

mysql設置變量的範圍默認是session範圍。若是設置多個會話的字符集那麼須要設置global範圍:Set [global|session] variables …

set global character_set_database=utf8;
set global character_set_server=utf8;
show variables like '%char%';

當咱們跨會話查看mysql字符集都會看到都是utf8。若是你覺得萬事大吉了的話，那麼你就大錯特錯了。

2.3、設置數據全局範圍

當咱們數據庫重啓的時候，大家發現設置global範圍的值又變成latin1了。

service mysqld restart
mysql -uroot -pyourpassword
show variables like '%char%';


不要怕，下面就教你終極大招：

修改mysql配置文件/etc/my.cnf。

[mysqld]
character-set-server=utf8 
[client]
default-character-set=utf8 
[mysql]
default-character-set=utf8

請注意這幾個參數配置的位置，否則可能會啓動不起來mysql服務：



OK。這下若是你重啓mysql服務也會發現它的字符集是utf8.



並且咱們建立表的時候不須要指定字符編碼,它默認就是utf8;

drop database test;
create database test;
use test;
create table user(name varchar(11));
show create table user \G;
3、總結

我看網上不少答案都是直接在session級別設置mysql的字符編碼，這是治標不治本的方法。咱們仍是要從源頭上解決這個問題。那就是修改mysql默認的配置文件，把它的字符集修改爲可以使用中文字符的UTF8就OK了。

 from:http://blog.csdn.net/u012410733/article/details/61619656