《Mysql學習MySQL中文亂碼問題的解決第1/2頁》要點:
本文介紹了Mysql學習MySQL中文亂碼問題的解決第1/2頁,希望對您有用。如果有疑問,可以聯系我們。
編譯 MySQL 時,指定了一個默認的字符集,這個字符集是 latin1;
安裝 MySQL 時,可以在配置文件 (my.ini) 中指定一個默認的的字符集,如果沒指定,這個值繼承自編譯時指定的;
啟動 mysqld 時,可以在命令行參數中指定一個默認的的字符集,如果沒指定,這個值繼承自配置文件中的;
此時 character_set_server 被設定為這個默認的字符集;
當創建一個新的數據庫時,除非明確指定,這個數據庫的字符集被缺省設定為 character_set_server;
當選定了一個數據庫時,character_set_database 被設定為這個數據庫默認的字符集;
在這個數據庫里創建一張表時,表默認的字符集被設定為 character_set_database,也就是這個數據庫默認的字符集;
當在表內設置一欄時,除非明確指定,否則此欄缺省的字符集就是表默認的字符集;
這個字符集就是數據庫中實際存儲數據采用的字符集,mysqldump 出來的內容就是這個字符集下的;
_baidu_page_break_tag_
1. MySQL 4.1 在文字上有很大改進,它有了 Character Set 與 Collation 的慨念.
2. 在 MySQL 4.0 ,一般的程式都會將文字以拉丁文 ( latin) 來儲存,就算我們輸入中文字,結果仍是放在以拉丁文設置的文字欄里頭,這對 MySQL 4.0 與以 MySQL 4.0 為基楚的程式來說,并不會有問題.
3. 可是 MySQL 4.1 的系統編碼是預設用 UTF-8 的,當要 restore MySQL 4.0 的 backup 檔到 MySQL 4.1 時,亂碼就出現了.原因在于 MySQL 4.1 將 latin 碼轉換過來,而后轉換是并不完全完美的,這導致了出現少量文字出現亂碼現象.
4. 要解決這亂碼問題并不難.首先,在 MySQL 4.0 備份時,先將所有文字欄變成 binary 類型,然后進行正常備份.第二步,可在 MySQL 4.1 里將剛才的備份 restore.最后,將較早前所變更到 binay 類型的文字欄,再次復原到文字類型.這樣中文編碼的問題就應該可以完全解決.
5. 將文字欄變更到 binay 類型時,必需設定 binary 欄的長度大過或等于 (>=) 文字欄的長度,否則資料會失去.
6. 另外,經這樣升級的 MySQL 數據庫,在 MySQL 4.1 里將會正常工作,就算是怎樣 backup 與 restore 都不會再有亂碼問題.
作者: MySQL 發布日期: 2005-12-14
mysql4.1是比較煩人,支持多語言的細化設置,再加上phpmyadmin2.6也比較笨,默認就是改不動的utf8,怎么弄都亂碼.
好了,廢話少說,我們來一步步解決這個問題:
1.修改/etc/my.cnf文件,改成這樣:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
注意:就是加入了一句default-character-set=utf8.
2./etc/init.d/mysqld restart 重新啟動mysql;
3.打開phpmyadmin,選擇lang為"Chines simplifies(zh-utf-8)",選擇"MySQL 連接校對"為"utf8_general_ci "點“顯示 MySQL 的運行信息”--“變量”,可以看到:
character set client utf8 utf8
character set connection utf8 utf8
character set database utf8 utf8
character set results utf8 utf8
character set server utf8 utf8
character set system utf8 utf8
collation connection utf8_general_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci
從這里可以看到character全部變成utf8了.
有人要問,為什么都要改成utf8呢?改成GB2312不行嗎?
解釋如下:
我也不想改成utf8,只是phpmyadmin2.6在mysql4.1的時候只會用utf8,連其他頁面的charset也都是utf8,改成gb2312一定會亂碼,我們只能湊phpmyadmin了.
只有在mysql3.23的時候,phpmyadmin才會多一個gb2312的頁面charset,這時候是正常的.
3.將以前的mysql3的庫文件導入mysql4.1的庫
有兩種情況:
一是從phpmyadmin上導入,這時候你要注意的是在選擇庫文件的頁面左下腳有個“文件的字符集:”,默認是utf8,要改成gb2312,否則導進去亂碼;
二是在linux下導入,這時候你需要先在庫文件的頭部加一行:
SET NAMES 'gb2312'; 注意最后也是;號,別漏了.
然后執行mysql -u用戶名 -p密碼 xxx.sql > 庫名
導入完成以后再用phpmyadmin打開看,里面的中文字就是正確的.
4.從mysql4.1里導出庫文件
一.用phpmyadmin導出
導出倒是問題不大,如果phpmyadmin的瀏覽頁面里顯示的中文是正常的,那么導出肯定也是正常的
二.在linux上導出
如果用mysqldump導出出現了亂碼也沒有關系,可以運行iconv來轉換一下
iconv -c -f UTF-8 -t GB2312 庫文件名 > 新的gb2312的庫文件名
綜上所述,你要注意:
1.盡量在需要導入的庫文件的開頭加入SET NAMES 'gb2312';告訴mysql你要導入的是一個gb2312的文件;
2.可能你需要這個:
SET NAMES 'utf8';
在登陸到mysql后用,把character的一些默認參數改到utf8上,有時可以減少一些困擾,不過也不是必須的.
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用來查看當前的狀態.
3.如果出現亂碼也不要怕,一是你要注意留存原有的備份,二是用iconv來進行轉化.
在正常使用之前注意做導入導出的測試,確保萬無一失.
最后加一句:www.quicklinux.org原創文章,轉載請注明出處.呵呵
郵件:support@quicklinux.org
作者: MySQL 發布日期: 2005-12-14
我升級了MYSQL到4.1.2,phpmyadmin用的是2.6.2.數據表里面有中文的字段中文都變成了亂碼,導出數據也是亂碼.我用以前的2.5.7沒有問題,想問一下,應該在phpmyadmin的那個文件里改哪個設置一下才能顯示出來的是正常的中文字?
和字符相關的變量中這幾個和sql很有關系:
character_set_client
character_set_connection
character_set_results
此外就是數據庫中對相應字段設置的charact set,如果沒有對字段設置,缺省是table的charact set,table也沒有指定則缺省使用database的.
上面3個變量的作用是這樣的,client表示客戶端發送過來的字符集,results表示發送到客戶端的字符集(這兩個分開是因為發送過來和發送過去的不一定是同一個客戶端),connection則在客戶端和數據庫起一個連接作用.
具體是這樣:比如我在mysql命令行設置client為gbk,connection為utf8,results為gbk,數據庫為big5,
當我發送一個insert語句的時候,這個語句作為gbk代碼,先轉為utf8代碼(connection),再轉為big5(database)插入數據庫.
而運行一個select語句的時候,從數據庫得到的結果則相反的過程,由big5轉為utf8,再轉為gbk,你得到gbk的結果.
因此最主要的是讓client和results和你使用的客戶端一致.比如你的網頁是utf8編碼,你就要設置這兩個為utf8.
而在mysql命令行的時候,我用的是2000,需要設置為gbk
而我們用的set names XXX,實際上就是同時設置這3個變量為XXX.
在這樣的情況下,我們可以把一個數據庫中的不同表或不同字段設為不同的字符集,只要上面3個設置正確,就可以在數據庫中同時使用不同的字符集.
注意要保證你的數據庫中的字符已經使用了正確的字符集,比如如果一開始你設置錯誤,插入數據后,本身數據的編碼就是不正確的,然后即使設置改回來,也不可能得到正確的顯示了.
還有一個是編碼互相之間的兼容性,如果一個字符在gbk中有,在utf8中沒有,那么在gbk-》utf8-》gbk的過程中,它就變成了“?”
再說一下具體解決的辦法.
首先要指定你的升級后的database及table及field的character set,一般來說我們用gb2312或者utf8的,如果不同時使用多種編碼,只要指定database就可以,可以在建庫的sql語句加上相應的character set,在phpMyAdmin里也可以修改.
然后是導入舊數據.首先要確定自己的數據文件的編碼.如果用phpMyAdmin導入,在界面上有文件編碼的選項,一定要和數據文件的編碼一致.
如果從mysql的命令行導入,就要自己設置上面說到的3個變量,set names xxx.
使用其它的客戶端程序一樣要注意.
這樣就可以讓舊數據轉入新數據庫后的編碼才是正確的,如果這一步錯了,后面不可能得到正確的顯示.
然后是自己的程序,在連接后就可以執行一次set names xxx,根據你的網頁編碼而定.
這樣基本就可以保證編碼正確了.
你很有可能是導入的數據編碼已經不對了.
轉自:http://www.zhaodaola.org/blog/p/mysql-luanma.php
MYSQL數據庫默認語言為瑞典語, 現有一GB2312字符的數據庫.
結構OK. 為什么內容是亂碼? 不重裝數據庫有辦法解決碼?
從MySQL 4.1開始引入的多語言支持確實很棒,而且一些特性已經超過了其他的數據庫系統.不過我在測試過程中發現使用適用于MySQL 4.1之前的
PHP語句操作MySQL數據庫會造成亂碼,即使是設置過了表字符集也是如此.我讀了一下新的MySQL在線手冊中第十章"Character Set Support"后終于找到了解決方法并測試通過.
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)
上面列出的值就是系統的默認值.(很奇怪系統怎么默認是latin1的瑞典語排序方式)...
當我們按照原來的方式通過PHP存取MySQL數據庫時,就算設置了表的默認字符集為utf8并且通過UTF-8編碼發送查詢,你會發現存入數據庫的仍然是亂碼.問題就出在這個connection連接層上.解決方法是在發送查詢前執行一下下面這句:
SET NAMES 'utf8';
它相當于下面的三句指令:
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;
再試試看,正常了吧?^_^ Enjoy!
具體講
在你的查詢前加一行:
????????????????????????mysql_query("SET NAMES 'gb2312';",$this->con);
真應該把手冊仔細看一遍.
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/2689.html