mysql c 中文字符串_MySQL字符集中文乱码终极解决方案和mysql查询中文问题解决方法...
開源數據庫MySQL從來都是中小企業構建web應用的首選，特別是和PHP配合簡直就是一 對黃金搭檔，深受web開發人員的喜愛。但自從4.1以來MySQL加入了多字符集的支持，很多MySQL使用者發現中文居然不能使用了，顯示變成了一堆 亂碼！以致于很多人還在使用3.24.58的老版本，最近上MySQL網站，發現居然不提供3.24版本的下載了，MySQL已經徹底放棄3.24版本 了。好在我還留有一份windows版的copy，就當作紀念吧。
怎么會產生亂碼現象的，怎么解決？只要翻下網上的解決方案，馬上就可以得出答案：“在獲得連接之后執行一句set names 'gb2312'”，但這樣做的原因是什么呢？總結一下我的經驗。
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
若設置set character_set_client = gb2312，那么至少connection的字符集要大于等于gb2312，否則就會丟失信息
4.
以上三步做正確的話，那么所有中文都被正確地轉換成utf8格式存儲進了數據庫，為了適應不同的瀏覽器，不同的客戶端，你可以修改
character_set_results來以不同的編碼顯示中文字體，由于utf8是大方向，因此web應用是我還是傾向于使用utf8格式顯示中文
的。
以上就是我的心得了。附上連接源碼，現行設置，程序中就可以不考慮字符集問題了
include "conf/system.php";
class Connection {
private $conn;
function __construct() {
global $mysql_ipaddr, $mysql_port, $mysql_db, $mysql_user, $mysql_pass;
try {
$this->conn = new PDO("mysql:host=$mysql_ipaddr;port=$mysql_port;dbname=$mysql_db", $mysql_user, $mysql_pass);
} catch (PDOException $e) {
print "MySQL服務器連接失敗: " . $e->getMessage() . "
";
die();
}
}
public function getConnection() {
if ($this->conn != null) {
$this->conn->query("set character_set_client = gb2312");??? //客戶端使用gb2312格式
$this->conn->query("set character_set_connection = utf8"); //連接字符集使用utf8格式
$this->conn->query("set character_set_results = utf8");??????//顯示字符集使用utf8格式
return $this->conn;
}
}
public function closeConnection() {
if ($this->conn != null) {
$this->conn = null;
}
}
}
我現在在mysql上遇到一個問題,我們的字符集是gb2312.在中文模糊查找時,會有不相關的結果集.
從問題的根本原因分析，還有下面的問題。
例：
漢字“不”的第1、2字節ascii值分別為：178與187
漢字“安”的第1、2字節ascii值分別為：176與178
漢字“花”的第1、2字節ascii值分別為：187與168
聰明的人已經看出來了：在字符串“安花”中模糊查找字符“不”字時，mysql系統也會認為兩者匹配!
出現這個問題的原因是：MySQL在查詢字符串時是大小寫不敏感的，在編繹MySQL時一般以ISO-8859字符集作為默認的字符集，因此在比較過程中中文編碼字符大小寫轉換造成了這種現象。
方法一:
解決方法是對于包含中文的字段加上"binary"屬性，使之作為二進制比較，例如將"name char(10)"改成"name char(10)binary"。
方法二:
如果你使用源碼編譯MySQL，可以編譯MySQL時使用--with--charset=gbk 參數，這樣MySQL就會直接支持中文查找和排序了。
方法三:
可以使用 Mysql 的 locate 函數來判斷。以上述問題為例,使用方法為:
SELECT * FROM table WHERE locate(field,'李') > 0;
本站使用的就是這種方法，感覺還不錯。:P
方法四:
把您的Select語句改成這樣,SELECT * FROM TABLE WHERE FIELDS LIKE BINARY '%FIND%'即可!
升級的根本，如果想使用“正確”的字符集，還是先用mysqldump導出成文件，然后導入。
===============================================================================
mysql查詢中文問題解決方法[轉貼]
原文：
http://blog.sina.com.cn/u/4909c13c010003va
Q:
我在寫一個查詢條件時的問題如下：
如我想寫一個字段中包含“李”字的所有記錄
$str="李";
select * from table where field like '%$str%' ;
顯示的記錄中除了包含”李”字的記錄，還有不包含“李”字的記錄。為什么？
A:
在MySQL中，進行中文排序和查找的時候，對漢字的排序和查找結果是錯誤的。這種情況在MySQL的很多版本中都存在。如果這個問題不解決，那么MySQL將無法實際處理中文。
出現這個問題的原因是：MySQL在查詢字符串時是大小寫不敏感的，在編繹MySQL時一般以ISO-8859字符集作為默認的字符集，因此在比較過程中中文編碼字符大小寫轉換造成了這種現象。
方法一:
解決方法是對于包含中文的字段加上"binary"屬性，使之作為二進制比較，例如將"name char(10)"改成"name char(10)binary"。
方法二:
如果你使用源碼編譯MySQL，可以編譯MySQL時使用--with--charset=gbk 參數，這樣MySQL就會直接支持中文查找和排序了。
方法三:
可以使用 Mysql 的 locate 函數來判斷。以上述問題為例,使用方法為:
SELECT * FROM table WHERE locate(field,'李') > 0;
本站使用的就是這種方法，感覺還不錯。:P
方法四:
把您的Select語句改成這樣,SELECT * FROM TABLE WHERE FIELDS LIKE BINARY '%FIND%'即可!
http://blog.sina.com.cn/u/4909c13c010003va
Q:
我在寫一個查詢條件時的問題如下：
如我想寫一個字段中包含“李”字的所有記錄
$str="李";
select * from table where field like '%$str%' ;
顯示的記錄中除了包含”李”字的記錄，還有不包含“李”字的記錄。為什么？
A:
在MySQL中，進行中文排序和查找的時候，對漢字的排序和查找結果是錯誤的。這種情況在MySQL的很多版本中都存在。如果這個問題不解決，那么MySQL將無法實際處理中文。
出現這個問題的原因是：MySQL在查詢字符串時是大小寫不敏感的，在編繹MySQL時一般以ISO-8859字符集作為默認的字符集，因此在比較過程中中文編碼字符大小寫轉換造成了這種現象。
方法一:
解決方法是對于包含中文的字段加上"binary"屬性，使之作為二進制比較，例如將"name char(10)"改成"name char(10)binary"。
方法二:
如果你使用源碼編譯MySQL，可以編譯MySQL時使用--with--charset=gbk 參數，這樣MySQL就會直接支持中文查找和排序了。
方法三:
可以使用 Mysql 的 locate 函數來判斷。以上述問題為例,使用方法為:
SELECT * FROM table WHERE locate(field,'李') > 0;
本站使用的就是這種方法，感覺還不錯。:P
方法四:
把您的Select語句改成這樣,SELECT * FROM TABLE WHERE FIELDS LIKE BINARY '%FIND%'即可!
===============================================================================
Mysql 字符集轉換及版本升級/降級的詳細教程 [轉貼]
MySQL
4.1開始，對多語言的支持有了很大變化 (這導致了問題的出現)。盡管大部分的地方 (包括個人使用和主機提供商)，MySQL 3、4.0
仍然占主導地位；但 MySQL 4.1 乃至5.0是 MySQL 官方推薦的數據庫，已經有主機提供商開始提供并將會越來越多；因為 latin1
在許多地方 (下邊會詳細描述具體是哪些地方) 作為默認的字符集，成功的蒙蔽了許多 PHP
程序的開發者和用戶，掩蓋了在中文等語言環境下會出現的問題。
MySQL 4.1開始把多國語言字符集分的更加詳細，所以導致數據庫遷移，或則dz論壇升級到4.0后(dz4.0開始使用gbk或utf-8編碼)出現亂碼問題。
MySQL
4.1的字符集支持(Character Set Support)有兩個方面：字符集(Character
set)和排序方式(Collation)。對于字符集的支持細化到四個層次:
服務器(server)，數據庫(database)，數據表(table)和連接(connection)。
查看系統的字符集和排序方式的設定可以通過下面的兩條命令：
引用:
mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)
mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)
MySQL 4.1 對于字符集的指定可以細化到一臺機器上安裝的
MySQL，其中的一個數據庫，其中的一張表，其中的一欄，應該用什么字符集。但是，傳統的 Web
程序在創建數據庫和數據表時并沒有使用那么復雜的配置，它們用的是默認的配置，那么，默認的配置從何而來呢？
編譯 MySQL 時，指定了一個默認的字符集，這個字符集是 latin1；
安裝 MySQL 時，可以在配置文件 (my.ini) 中指定一個默認的的字符集，如果沒指定，這個值繼承自編譯時指定的；
啟動 mysqld 時，可以在命令行參數中指定一個默認的的字符集，如果沒指定，這個值繼承自配置文件中的；
此時 character_set_server 被設定為這個默認的字符集；
當創建一個新的數據庫時，除非明確指定，這個數據庫的字符集被缺省設定為 character_set_server；
當選定了一個數據庫時，character_set_database 被設定為這個數據庫默認的字符集；
在這個數據庫里創建一張表時，表默認的字符集被設定為 character_set_database，也就是這個數據庫默認的字符集；
當在表內設置一欄時，除非明確指定，否則此欄缺省的字符集就是表默認的字符集；
這個字符集就是數據庫中實際存儲數據采用的字符集，mysqldump 出來的內容就是這個字符集下的；
當我們按照原來的方式通過PHP存取MySQL數據庫時，就算設置了表的默認字符集為utf8并且通過UTF-8編碼發送查詢，你會發現存入數據庫的仍然是亂碼。問題就出在這個connection連接層上。
想要進行“正確”的存儲和得到“正確”的結果，最方便的是在所有query開始之前執行一下：
SET NAMES 'gbk';
其中gbk是數據庫字符集。
它相當于下面的三句指令：
SET character_set_client = gbk;
SET character_set_results = gbk;
SET character_set_connection = gbk;
4.1和5.0默認使用的是latin1字符集(木頭:媽的,老外真霸道,妄想讓全世界都是使用瑞典字符集嗎)
如果我們只想使用gbk字符集存儲和獲取數據,
我們在編譯mysql 4.1和 5.0的時候，需要注意在my.ini或者my.cnf中添加兩處參數
CODE:
[mysqld]
default-character-set=utf8
CODE:
#settings for clients (connection, results, clients)
[mysql]
default-character-set=utf8
下面我們來說主題，如何轉換數據庫字符集
兩種方法，
引用:
第一種----更改存儲字符集
主要的思想就是把數據庫的字符集有latin1改為gbk，big5,或者utf8; 以下操作必須擁有主機權限。假設當前操作的數據庫名為：database
導出
首先需要把數據導為mysql4.0的格式，具體的命令如下：
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse > d4.sql
--default-characte-set 以前數據庫的字符集，這個一般情況下都是latin1的，
--set-charset 導出的數據的字符集，這個可以設置為gbk，utf8,或者big5
導入
首先使用下面語句新建一個GBK字符集的數據庫(test)
CREATE DATABASE `d4` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
然后把剛才導出的數據導入到當前的數據庫中就ok了。
mysql -uroot -p --default-character-set=gbk -f d4
通過以上的導出和導入就把數據庫的字符集改為正確的存儲方式了。
其中d4為新建庫的名稱，d4.sql為導出文件的名字
但是這種方法，發現數據庫數據存儲量無端變大30%，真是郁悶
引用:
另外一種其實原理相同，但是需要手動操作，一般用于第一種方法失敗后的選擇
不過這種方法如果數據庫很大，估計很難做，因為光打開文件就能讓你死機
首先還是用phpmyadmin或者用mysql本身的dump導出 .sql文件
然后用UltraEdit打開你備份的所有xxxx.sql文件，查找
CODE:
DEFAULT CHARSET=latin1
CODE:
CREATE TABLE cdb_sessions (
sid char(6) character set latin1 collate latin1_bin NOT NULL default '',
ip1 tinyint(3) unsigned NOT NULL default '0',
ip2 tinyint(3) unsigned NOT NULL default '0',
ip3 tinyint(3) unsigned NOT NULL default '0',
ip4 tinyint(3) unsigned NOT NULL default '0',
uid mediumint(8) unsigned NOT NULL default '0',
username char(15) NOT NULL default '',
groupid smallint(6) unsigned NOT NULL default '0',
styleid smallint(6) unsigned NOT NULL default '0',
invisible tinyint(1) NOT NULL default '0',
`action` tinyint(1) unsigned NOT NULL default '0',
lastactivity int(10) unsigned NOT NULL default '0',
fid smallint(6) unsigned NOT NULL default '0',
tid mediumint(8) unsigned NOT NULL default '0',
nickname char(15) NOT NULL default '',
UNIQUE KEY sid (sid)
) ENGINE=HEAP MAX_ROWS=1000;
CODE:
CREATE TABLE `cdb_sessions` (
`sid` char(6) binary NOT NULL default '',
`ip1` tinyint(3) unsigned NOT NULL default '0',
`ip2` tinyint(3) unsigned NOT NULL default '0',
`ip3` tinyint(3) unsigned NOT NULL default '0',
`ip4` tinyint(3) unsigned NOT NULL default '0',
`uid` mediumint(8) unsigned NOT NULL default '0',
`username` char(15) NOT NULL default '',
`groupid` smallint(6) unsigned NOT NULL default '0',
`styleid` smallint(6) unsigned NOT NULL default '0',
`invisible` tinyint(1) NOT NULL default '0',
`action` tinyint(1) unsigned NOT NULL default '0',
`lastactivity` int(10) unsigned NOT NULL default '0',
`fid` smallint(6) unsigned NOT NULL default '0',
`tid` mediumint(8) unsigned NOT NULL default '0',
`nickname` char(15) NOT NULL default '',
UNIQUE KEY `sid` (`sid`)
) TYPE=HEAP MAX_ROWS=2000;
用這兩種方法就可以很方便的把4.1和5.0的mysql數據庫降級到4.0
簡單的過程就是
A導出4.1/5.0的庫
B進行處理，轉換成gbk字符集
C徹底卸載4.1或者5.0
D安裝4.0.26
E然后導入處理完的庫
降級的時候導出庫可以用這個方法
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse --compatible=mysql40 > d4.sql
這樣導出的就是4.0的庫勒
至于mysql版本的升級，
如
果數據文件中有中文信息，那么將MySQL 4.0的數據文件，直接拷貝到MySQL
4.1中就是不可以的，即便在my.ini中設置了default-character-set為正確的字符集。雖然貌似沒有問題，但MySQL
4.1的字符集有一處非常惱人的地方，以gbk為例，原本MySQL
4.0數據中varchar,char等長度都會變為原來的一半，這樣存儲中文容量不變，而英文的存儲容量就少了一半。這是直接拷貝數據文件帶來的最大問
題。
所以，升級的根本，如果想使用“正確”的字符集，還是先用mysqldump導出成文件，然后導入。
轉自：http://www.sd9981.com/mysql/?p=22
===============================================================================
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的mysql c 中文字符串_MySQL字符集中文乱码终极解决方案和mysql查询中文问题解决方法...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python 判断时间是否大于6点_py
- 下一篇： linux cmake编译源码,linu