先按以前的經驗，
[MYSQL] 三步解決MysSQL中文問題 。
修改pom.xml：
<jdbc.url><![CDATA[jdbc:mysql://localhost/reda?createDatabaseIfNotExist=true&characterEncoding=gbk]]></jdbc.url>
修改taglibs.jsp：
<%@ page language="java" errorPage="/error.jsp" pageEncoding="GBK" contentType="text/html;charset=GBK" %>
修改web.xml：
<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
<init-param>
<param-name>forceEncoding</param-name>
<param-value>true</param-value>
</init-param>
</filter>
結果，查詢顯示正確，但是更新和插入都出現亂碼。
反復折騰了好久，更新和插入還是亂碼，估計是AppFuse里哪部分代碼做了字符轉行，現在對AppFuse還不是很熟悉，也不知道該從哪里下手。
上網查了查，說UTF-8編碼是一種兼容所有語言的編碼方式，所以UTF-8才是王道。又繞回到UTF-8上來，既然AppFuse默認就是UTF-8，那問題就應該不是出在AppFuse上，應該是在MySQL上。
把數據庫全都切換到utf8上，數據庫和表的DDL都加上字符集設置：
CHARACTER SET utf8 COLLATE utf8_general_ci
修改MySQL的配置文件my.ini：
default-character-set=utf8
可以通過下面的命令查看字符集：
mysql> show variables like 'character_set_%';
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | D:\Dev\MySQL\MySQL Server 5.0\share\charsets\ |
+--------------------------+-----------------------------------------------+
經過上面的修改，中文問題就解決了，AppFuse的CRUD都正常了。
如果使用MySQL Command Line Client，我們查看數據庫看到是還是亂碼，執行插入時還會報錯：“ Data too long for column 'type_name' at row 1”。可以在執行前，先執行：set names gbk，這樣就可以了。
mysql> set names utf8;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from company_type;
+---------+-----------+--------+
| type_id | type_name | status |
+---------+-----------+--------+
| 1 | 嫻嬭瘯 | |
| 2 | 鍑洪敊 | |
+---------+-----------+--------+
2 rows in set (0.00 sec)
mysql> insert into company_type(type_name,status) values('出錯',1);
ERROR 1406 (22001): Data too long for column 'type_name' at row 1
mysql> set names gbk;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into company_type(type_name,status) values('出錯',1);
Query OK, 1 row affected (0.03 sec)
mysql> select * from company_type;
+---------+-----------+--------+
| type_id | type_name | status |
+---------+-----------+--------+
| 1 | 測試 | |
| 2 | 出錯 | |
| 3 | 出錯 | |
+---------+-----------+--------+
3 rows in set (0.00 sec)
附一：Mysql中校對集utf8_unicode_ci與utf8_general_ci的區別
當前，utf8_unicode_ci校對規則僅部分支持Unicode校對規則算法。一些字符還是不能支持。并且，不能完全支持組合的記號。這主要影響越南和俄羅斯的一些少數民族語言，如：Udmurt 、Tatar、Bashkir和Mari。
utf8_unicode_ci的最主要的特色是支持擴展，即當把一個字母看作與其它字母組合相等時。例如，在德語和一些其它語言中‘?’等于‘ss’。
utf8_general_ci是一個遺留的 校對規則，不支持擴展。它僅能夠在字符之間進行逐個比較。這意味著utf8_general_ci校對規則進行的比較速度很快，但是與使用utf8_unicode_ci的 校對規則相比，比較正確性較差）。
例如，使用utf8_general_ci和utf8_unicode_ci兩種 校對規則下面的比較相等：
? = A
? = O
ü = U
兩種校對規則之間的區別是，對于utf8_general_ci下面的等式成立：
? = s
但是，對于utf8_unicode_ci下面等式成立：
? = ss
對于一種語言僅當使用utf8_unicode_ci排序做的不好時，才執行與具體語言相關的utf8字符集 校對規則。例如，對于德語和法語，utf8_unicode_ci工作的很好，因此不再需要為這兩種語言創建特殊的utf8校對規則。
utf8_general_ci也適用與德語和法語，除了‘?’等于‘s’，而不是‘ss’之外。如果你的應用能夠接受這些，那么應該使用utf8_general_ci，因為它速度快。否則，使用utf8_unicode_ci，因為它比較準確。
附二：
使用MySQL的命令終端時，如果輸入SQL有誤，將有beep聲。若要關閉該功能，根據mysql --help，使用mysql --no-beep即可。
修改my.ini
在[mysql] 下加入一行 ：
no-beep
文章來源:
http://heyday.blogcn.com/diary,15090253.shtml