數據庫中MySQL中文亂碼問(wèn)相關(guān)資料
下面要寫(xiě)的是一篇非常無(wú)聊的東西，充斥了大量各式各樣的編碼、轉換、客戶(hù)端、服務(wù)器端、連接……呃，我自己都不愿意去看它，但想一想，寫(xiě)下來(lái)還是有點(diǎn)意義 的，原因有四：
MySQL 4.1 對多語(yǔ)言的支持有了很大變化 (這導致了問(wèn)題的出現)；
盡管大部分的地方 (包括個(gè)人使用和主機提供商)，MySQL 3 仍然占主導地位；但 MySQL 4.1 是 MySQL 官方推薦的數據庫，已經(jīng)有主機提供商開(kāi)始提供并將會(huì )越來(lái)越多；
許多 PHP 程序以 MySQL 作為默認的數據庫管理軟件，但它們一般不區分 MySQL 4.1 與 4.1 以下版本的區別，籠統地稱(chēng)“MySQL 3.xx.xx 以上版本”就滿(mǎn)足安裝需求了；
因為 latin1 在許多地方 (下邊會(huì )詳細描述具體是哪些地方) 作為默認的字符集，成功的蒙蔽了許多 PHP 程序的開(kāi)發(fā)者和用戶(hù)，掩蓋了在中文等語(yǔ)言環(huán)境下會(huì )出現的問(wèn)題；
簡(jiǎn)單的說(shuō)，MySQL 自身的變化和使用 MySQL 的 PHP 程序對此忽略，導致了問(wèn)題的出現和復雜化，而由于大部分用戶(hù)使用的是英文，使這種問(wèn)題不被重視。這里提到的 PHP 程序，主要就 WordPress 而言。
MySQL 4.1 字符集支持的原理MySQL 4.1 對于字符集的指定可以細化到一臺機器上安裝的 MySQL，其中的一個(gè)數據庫，其中的一張表，其中的一欄，應該用什么字符集。但是，傳統的 Web 程序在創(chuàng )建數據庫和數據表時(shí)并沒(méi)有使用那么復雜的配置，它們用的是默認的配置，那么，默認的配置從何而來(lái)呢？
編譯 MySQL 時(shí)，指定了一個(gè)默認的字符集，這個(gè)字符集是 latin1；
安裝 MySQL 時(shí)，可以在配置文件 (my.ini) 中指定一個(gè)默認的的字符集，如果沒(méi)指定，這個(gè)值繼承自編譯時(shí)指定的；
啟動(dòng) mysqld 時(shí)，可以在命令行參數中指定一個(gè)默認的的字符集，如果沒(méi)指定，這個(gè)值繼承自配置文件中的；
此時(shí) character_set_server 被設定為這個(gè)默認的字符集；
當創(chuàng )建一個(gè)新的數據庫時(shí)，除非明確指定，這個(gè)數據庫的字符集被缺省設定為 character_set_server；
當選定了一個(gè)數據庫時(shí)，character_set_database 被設定為這個(gè)數據庫默認的字符集；
在這個(gè)數據庫里創(chuàng )建一張表時(shí)，表默認的字符集被設定為 character_set_database，也就是這個(gè)數據庫默認的字符集；
當在表內設置一欄時(shí)，除非明確指定，否則此欄缺省的字符集就是表默認的字符集；
這個(gè)字符集就是數據庫中實(shí)際存儲數據采用的字符集，mysqldump 出來(lái)的內容就是這個(gè)字符集下的；
簡(jiǎn)單的總結一下，如果什么地方都不修改，那么所有的數據庫的所有表的所有欄位的都用 latin1 存儲，不過(guò)我們如果安裝 MySQL，一般都會(huì )選擇多語(yǔ)言支持，也就是說(shuō)，安裝程序會(huì )自動(dòng)在配置文件中把 default_character_set 設置為 UTF-8，這保證了缺省情況下，所有的數據庫的所有表的所有欄位的都用 UTF-8 存儲。
當一個(gè) PHP 程序與 MySQL 建立連接后，這個(gè)程序發(fā)送給 MySQL 的數據采用的是什么字符集？MySQL 無(wú)從得知 (它最多只能猜測)，所以 MySQL 4.1 要求客戶(hù)端必須指定這個(gè)字符集，也就是 character_set_client，MySQL 的怪異之處在于，得到的這個(gè)字符集并不立即轉換為存儲在數據庫中的那個(gè)字符集，而是先轉換為 character_set_connection 變量指定的一個(gè)字符集；這個(gè) connection 層究竟有什么用我不大明白，但轉換為 character_set_connection 的這個(gè)字符集之后，還要轉換為數據庫默認的字符集，也就是說(shuō)要經(jīng)過(guò)兩次轉換；當這個(gè)數據被輸出時(shí)，又要由數據庫默認的字符集轉換為 character_set_results 指定的字符集。
一個(gè)典型的環(huán)境典型的環(huán)境以我自己的電腦上安裝的 MySQL 4.1 為例，我自己的電腦上安裝著(zhù) Apache 2，PHP 5 和 WordPress 1.5.1.3，MySQL 配置文件中指定了 default_character_set 為 utf8。于是問(wèn)題出現了：
WordPress 按照默認情況安裝，所以所有的表都用 UTF-8 存儲數據；
WordPress 默認采用的瀏覽字符集是 UTF-8 (Options->Reading 中設置)，因此所有 WP 頁(yè)面的 meta 中會(huì )說(shuō)明 charset 是 utf-8；
所以瀏覽器會(huì )以 utf-8 方式顯示所有的 WP 頁(yè)面；這樣一來(lái) Write 的所有 Post，和 Comment 都會(huì )以 UTF-8 格式從瀏覽器發(fā)送給 Apache，再由 Apache 交給 PHP；
所以 WP 從所有的表單中得到的數據都是 utf-8 編碼的；WP 不加轉換的直接把這些數據發(fā)送給 MySQL；
MySQL 默認設置的 character_set_client 和 character_set_connection 都是 latin1，此時(shí)怪異的事情發(fā)生了，實(shí)際上是 utf-8 格式的數據，被“當作 latin1”轉換成……居然還是轉換成 latin1，然后再由這個(gè) latin1 轉換成 utf-8，這么兩次轉換，有一部分 utf-8 的字符就丟失了，變成 ??，最后輸出的時(shí)候 character_set_results 默認是 latin1，也就輸出為奇怪的東西了。
最神奇的還不是這個(gè)，如果 WordPress 中設置以 GB2312 格式閱讀，那么 WP 發(fā)送給 MySQL 的 GB2312 編碼的數據，被“當作 latin1”轉換后，存進(jìn)數據庫的是一種奇怪的格式 (真的是奇怪的格式，mysqldump 出來(lái)就能發(fā)現，無(wú)論當作 utf-8 還是當作 gb2312 來(lái)讀都是亂碼)，但如果這種格式以 latin1 輸出出來(lái)，居然又能變回 GB2312！
這會(huì )導致什么現象呢？WP 如果使用 MySQL 4.1 數據庫，把編碼改用 GB2312 就正常了，可惜，這種正常只是貌似正常。
如何解決問(wèn)題如果你已經(jīng)不耐煩了 (幾乎是肯定的)，google 一下，會(huì )發(fā)現絕大部分的解答是，query 之前先執行一下：SET NAMES 'utf8'，沒(méi)錯，這是解決方案，但本文的目的是說(shuō)明，這為什么是解決方案。
要保證結果正確，必須保證數據表采用的格式是正確的，也就是說(shuō)，至少能夠存放所有的漢字，那么我們只有兩種選擇，gbk 或者 utf-8，下面討論 utf-8 的情況。
因為配置文件設置的 default_character_set 是 utf8，數據表默認采用的就是 utf-8 建立的。這也應該是所有采用 MySQL 4.1 的主機提供商應該采用的配置。所以我們要保證的只是客戶(hù)端與 MySQL 交互之間指定編碼的正確。
這只有兩種可能，客戶(hù)端以 gb2312 格式發(fā)送數據，或者以 utf-8 格式發(fā)送數據。
如果以 gb2312 格式發(fā)送:
SET character_set_client='gb2312'
SET character_set_connection='utf8' 或者
SET character_set_connection='gb2312'
都是可以的，都能夠保證數據在編碼轉換中不出現丟失，也就是保證存儲入數據庫的是正確的內容。
怎么保證取出的是正確的內容呢？考慮到絕大部分客戶(hù)端 (包括 WP)，發(fā)送數據的編碼也就是它所希望收到數據的編碼，所以:
SET character_set_results='gb2312'
可以保證取出給瀏覽器顯示的格式就是 gb2312。
如果是第二種情況，客戶(hù)端以 utf-8 格式發(fā)送 (WP 的默認情況)，可以采用下述配置:
SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'
這個(gè)配置就等價(jià)于 SET NAMES 'utf8'。
WP 應該作什么修改還是那句話(huà)，客戶(hù)端要發(fā)給數據庫什么編碼的數據，數據庫是不可能確切知道的，只能讓客戶(hù)端自己說(shuō)明白，所以，WP 是必須發(fā)送正確的 SET... 給 MySQL 的。怎么發(fā)送最合適呢？臺灣的 pLog 同仁給出了一些建議：
首先，測試服務(wù)器是否 >= 4.1，編譯時(shí)是否加入了 UTF-8 支持；是則繼續
然后測試數據庫以什么格式存儲 ($dbEncoding)；
SET NAMES $dbEncoding
對于第二點(diǎn)，WP 的情況是不同的，按照上面的典型配置，只要用 WP，肯定數據庫是用 UTF-8 存儲的，所以要根據用戶(hù)設置的以 GB2312 還是 UTF-8 瀏覽來(lái)判斷 (bloginfo('charset'))，但這個(gè)值是要連接數據庫以后才能得到的，所以效率最高的方式是連接數據庫之后，根據這個(gè)配置設置一次 SET NAMES，而不必每次查詢(xún)之前都設置一遍。
我的修改方式是這樣的，在 wp_includes/wp-db.php 中增加:
function set_charset($charset)
{
// check mysql version first.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] dbh);
if (mysql_num_rows($result) dbh);
}
在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:
$wpdb->set_charset(get_bloginfo('charset'));
----------------------------------------------------------------------
1. MySQL 4.1 在文字上有很大改進(jìn)，它有了 Character Set 與 Collation 的慨念。
2. 在 MySQL 4.0 ，一般的程式都會(huì )將文字以拉丁文 ( latin) 來(lái)儲存，就算我們輸入中文字，結果仍是放在以拉丁文設置的文字欄里頭，這對 MySQL 4.0 與以 MySQL 4.0 為基楚的程式來(lái)說(shuō)，并不會(huì )有問(wèn)題。
3. 可是 MySQL 4.1 的系統編碼是預設用 UTF-8 的，當要 restore MySQL 4.0 的 backup 檔到 MySQL 4.1 時(shí)，亂碼就出現了。原因在于 MySQL 4.1 將 latin 碼轉換過(guò)來(lái)，而后轉換是并不完全完美的，這導致了出現少量文字出現亂碼現象。
4. 要解決這亂碼問(wèn)題并不難。首先，在 MySQL 4.0 備份時(shí)，先將所有文字欄變成 binary 類(lèi)型，然后進(jìn)行正常備份。第二步，可在 MySQL 4.1 里將剛才的備份 restore。最后，將較早前所變更到 binay 類(lèi)型的文字欄，再次復原到文字類(lèi)型。這樣中文編碼的問(wèn)題就應該可以完全解決。
5. 將文字欄變更到 binay 類(lèi)型時(shí)，必需設定 binary 欄的長(cháng)度大過(guò)或等于 (>=) 文字欄的長(cháng)度，否則資料會(huì )失去。
6. 另外，經(jīng)這樣升級的 MySQL 數據庫，在 MySQL 4.1 里將會(huì )正常工作，就算是怎樣 backup 與 restore 都不會(huì )再有亂碼問(wèn)題。
作者: MySQL 發(fā)布日期: 2005-12-14
mysql4.1是比較煩人，支持多語(yǔ)言的細化設置，再加上phpmyadmin2.6也比較笨，默認就是改不動(dòng)的utf8，怎么弄都亂碼。
好了，廢話(huà)少說(shuō)，我們來(lái)一步步解決這個(gè)問(wèn)題：
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 重新啟動(dòng)mysql；
3.打開(kāi)phpmyadmin，選擇lang為"Chines simplifies(zh-utf-8)",選擇"MySQL 連接校對"為"utf8_general_ci "點(diǎn)“顯示 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了。
有人要問(wèn)，為什么都要改成utf8呢？改成GB2312不行嗎？
解釋如下：
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的時(shí)候只會(huì )用utf8，連其他頁(yè)面的charset也都是utf8，改成 gb2312一定會(huì )亂碼，我們只能湊phpmyadmin了。
只有在mysql3.23的時(shí)候，phpmyadmin才會(huì )多一個(gè)gb2312的頁(yè)面charset，這時(shí)候是正常的。
3.將以前的mysql3的庫文件導入mysql4.1的庫
有兩種情況：
一是從phpmyadmin上導入，這時(shí)候你要注意的是在選擇庫文件的頁(yè)面左下腳有個(gè)“文件的字符集：”，默認是utf8，要改成gb2312，否則導進(jìn) 去亂碼；
二是在linux下導入，這時(shí)候你需要先在庫文件的頭部加一行:
SET NAMES 'gb2312'; 注意最后也是;號，別漏了。
然后執行mysql -u用戶(hù)名 -p密碼 xxx.sql > 庫名
導入完成以后再用phpmyadmin打開(kāi)看，里面的中文字就是正確的。
4.從mysql4.1里導出庫文件
一.用phpmyadmin導出
導出倒是問(wèn)題不大，如果phpmyadmin的瀏覽頁(yè)面里顯示的中文是正常的，那么導出肯定也是正常的
二.在linux上導出
如果用mysqldump導出出現了亂碼也沒(méi)有關(guān)系，可以運行iconv來(lái)轉換一下
iconv -c -f UTF-8 -t GB2312 庫文件名 > 新的gb2312的庫文件名
綜上所述，你要注意：
1。盡量在需要導入的庫文件的開(kāi)頭加入SET NAMES 'gb2312';告訴mysql你要導入的是一個(gè)gb2312的文件；
2�？赡苣阈枰@個(gè)：
SET NAMES 'utf8';
在登陸到mysql后用，把character的一些默認參數改到utf8上，有時(shí)可以減少一些困擾，不過(guò)也不是必須的。
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用來(lái)查看當前的狀態(tài)。
3.如果出現亂碼也不要怕，一是你要注意留存原有的備份，二是用iconv來(lái)進(jìn)行轉化。
在正常使用之前注意做導入導出的測試，確保萬(wàn)無(wú)一失。
最后加一句：www.quicklinux.org原創(chuàng )文章，轉載請注明出處。呵呵
郵件：support@quicklinux.org
作者: MySQL 發(fā)布日期: 2005-12-14
我升級了MYSQL到4.1.2，phpmyadmin用的是2.6.2。數據表里面有中文的字段中文都變成了亂碼，導出數據也是亂碼。我用以前的 2.5.7沒(méi)有問(wèn)題，想問(wèn)一下，應該在phpmyadmin的那個(gè)文件里改哪個(gè)設置一下才能顯示出來(lái)的是正常的中文字？
和字符相關(guān)的變量中這幾個(gè)和sql很有關(guān)系：
character_set_client
character_set_connection
character_set_results
此外就是數據庫中對相應字段設置的charact set，如果沒(méi)有對字段設置，缺省是table的charact set，table也沒(méi)有指定則缺省使用database的。
上面3個(gè)變量的作用是這樣的，client表示客戶(hù)端發(fā)送過(guò)來(lái)的字符集，results表示發(fā)送到客戶(hù)端的字符集（這兩個(gè)分開(kāi)是因為發(fā)送過(guò)來(lái)和發(fā)送過(guò)去的 不一定是同一個(gè)客戶(hù)端），connection則在客戶(hù)端和數據庫起一個(gè)連接作用。
具體是這樣：比如我在mysql命令行設置client為gbk，connection為utf8，results為gbk，數據庫為big5，
當我發(fā)送一個(gè)insert語(yǔ)句的時(shí)候，這個(gè)語(yǔ)句作為gbk代碼，先轉為utf8代碼（connection），再轉為big5（database）插入數 據庫。
而運行一個(gè)select語(yǔ)句的時(shí)候，從數據庫得到的結果則相反的過(guò)程，由big5轉為utf8，再轉為gbk，你得到gbk的結果。
因此最主要的是讓client和results和你使用的客戶(hù)端一致。比如你的網(wǎng)頁(yè)是utf8編碼，你就要設置這兩個(gè)為utf8。
而在mysql命令行的時(shí)候，我用的是2000，需要設置為gbk
而我們用的set names XXX，實(shí)際上就是同時(shí)設置這3個(gè)變量為XXX。
在這樣的情況下，我們可以把一個(gè)數據庫中的不同表或不同字段設為不同的字符集，只要上面3個(gè)設置正確，就可以在數據庫中同時(shí)使用不同的字符集。
注意要保證你的數據庫中的字符已經(jīng)使用了正確的字符集，比如如果一開(kāi)始你設置錯誤，插入數據后，本身數據的編碼就是不正確的，然后即使設置改回來(lái)，也不可 能得到正確的顯示了。
還有一個(gè)是編碼互相之間的兼容性，如果一個(gè)字符在gbk中有，在utf8中沒(méi)有，那么在gbk－》utf8－》gbk的過(guò)程中，它就變成了“？”
再說(shuō)一下具體解決的辦法。
首先要指定你的升級后的database及table及field的character set，一般來(lái)說(shuō)我們用gb2312或者utf8的，如果不同時(shí)使用多種編碼，只要指定database就可以，可以在建庫的sql語(yǔ)句加上相應的 character set，在phpMyAdmin里也可以修改。
然后是導入舊數據。首先要確定自己的數據文件的編碼。如果用phpMyAdmin導入，在界面上有文件編碼的選項，一定要和數據文件的編碼一致。
如果從mysql的命令行導入，就要自己設置上面說(shuō)到的3個(gè)變量，set names xxx。
使用其它的客戶(hù)端程序一樣要注意。
這樣就可以讓舊數據轉入新數據庫后的編碼才是正確的，如果這一步錯了，后面不可能得到正確的顯示。
然后是自己的程序，在連接后就可以執行一次set names xxx，根據你的網(wǎng)頁(yè)編碼而定。
這樣基本就可以保證編碼正確了。
你很有可能是導入的數據編碼已經(jīng)不對了。
================================================================================
MYSQL數據庫默認語(yǔ)言為瑞典語(yǔ), 現有一GB2312字符的數據庫.
結構OK. 為什么內容是亂碼? 不重裝數據庫有辦法解決碼?
從MySQL 4.1開(kāi)始引入的多語(yǔ)言支持確實(shí)很棒，而且一些特性已經(jīng)超過(guò)了其他的數據庫系統。不過(guò)我在測試過(guò)程中發(fā)現使用適用于MySQL 4.1之前的PHP語(yǔ)句操作MySQL數據庫會(huì )造成亂碼，即使是設置過(guò)了表字符集也是如此。我讀了一下新的MySQL在線(xiàn)手冊中第十 章"Character Set Support"后終于找到了解決方法并測試通過(guò)。
MySQL 4.1的字符集支持(Character Set Support)有兩個(gè)方面：字符集(Character set)和排序方式(Collation)。對于字符集的支持細化到四個(gè)層次: 服務(wù)器(server)，數據庫(database)，數據表(table)和連接(connection)。
查看系統的字符集和排序方式的設定可以通過(guò)下面的兩條命令：
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的瑞典語(yǔ)排序方式)...
當我們按照原來(lái)的方式通過(guò)PHP存取MySQL數據庫時(shí)，就算設置了表的默認字符集為utf8并且通過(guò)UTF-8編碼發(fā)送查詢(xún)，你會(huì )發(fā)現存入數據庫的仍然 是亂碼。問(wèn)題就出在這個(gè)connection連接層上。解決方法是在發(fā)送查詢(xún)前執行一下下面這句：
SET NAMES 'utf8';
它相當于下面的三句指令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;
再試試看，正常了吧？^_^ Enjoy!
具體講
在你的查詢(xún)前加一行：
mysql_query("SET NAMES 'gb2312';",$this->con);
真應該把手冊仔細看一遍.
=========================================================================
服務(wù)器：Tomcat 5.0.28
JDK：1.4.1_02
數據庫：Mysql 4.1.12和5.0.18（現在）
JDBC版本：3.0.10
我用Myeclipse做了一個(gè)AddressBook(Struts + Hibernate)，能成功運行，英文數據庫讀寫(xiě)正常，但中文不管是往數據庫里寫(xiě)還是從數據庫里讀總是亂碼，以？？？？顯示。
我兩個(gè)版本的Mysql都裝過(guò)，字符集也從GBK，UTF8，latin1都試過(guò)，但還是不行，現在的版本是5.0.18，my.ini里的 default-character-set=utf8。借助第三方工具（mysql_front、mysql query browser)數據庫里直接寫(xiě)中文能正常顯示.
我把jdbc:mysql://localhost:3306/test?Unicode=true& characterEncoding=GBK
里的GBK改成UTF8，往數據庫里寫(xiě)中文結果顯示的不是？？？，但還是亂碼，讀到JSP頁(yè)面上也看不懂。
我在網(wǎng)上也查了很多資料,Matrix里關(guān)于Mysql亂碼的帖子我也看了，但還是沒(méi)解決，請指點(diǎn)。謝謝！
=========================================================
以前遇到JSP 處理MySQL數據庫時(shí)的中文問(wèn)題時(shí)，采取的是很笨的一種方法，直接用字符串編碼轉換函數進(jìn)行轉換，這次從網(wǎng)上搜了一下，找到了一個(gè)使用Filter的可 行方法。在Tomcat 5.5＋ MySQL4.0.16下通過(guò)。
filter類(lèi)源碼是從網(wǎng)上找的，如下
/**
*
*/
package com.lzy;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
/**
* @author lzy
*
*/
public class SetCharacterEncodingFilter implements Filter {
protected String encoding = null;
protected FilterConfig filterConfig = null;
protected boolean ignore = true;
/* (non-Javadoc)
* @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
*/
public void init(FilterConfig filterConfig) throws ServletException {
// TODO Auto-generated method stub
this.filterConfig = filterConfig;
this.encoding = filterConfig.getInitParameter("encoding");
String value = filterConfig.getInitParameter("ignore");
if (value == null)
this.ignore = true;
else if (value.equalsIgnoreCase("true"))
this.ignore = true;
else if (value.equalsIgnoreCase("yes"))
this.ignore = true;
else
this.ignore = false;
}
/* (non-Javadoc)
* @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse, javax.servlet.FilterChain)
*/
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
// TODO Auto-generated method stub
if (ignore || (request.getCharacterEncoding() == null)) {
String encoding = selectEncoding(request);
if (encoding != null)
request.setCharacterEncoding(encoding);
}
chain.doFilter(request, response);
}
/* (non-Javadoc)
* @see javax.servlet.Filter#destroy()
*/
public void destroy() {
// TODO Auto-generated method stub
this.encoding = null;
this.filterConfig = null;
}
protected String selectEncoding(ServletRequest request) {
return (this.encoding);
}
}
在web.xml 文件中作如下設置：（我使用的是Struts框架）
Encoding
com.lzy.SetCharacterEncodingFilter
encoding
GBK
Encoding
action
Encoding
*.jsp
最后，連接數據庫時(shí)，使用下面的url：
jdbc:mysql://localhost:3306/數據庫名?useUnicode=true& characterEncoding=GBK
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
