• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            兔子的技術博客

            兔子

               :: 首頁 :: 聯系 :: 聚合  :: 管理
              202 Posts :: 0 Stories :: 43 Comments :: 0 Trackbacks

            留言簿(10)

            最新評論

            閱讀排行榜

            評論排行榜

            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)

            上面列出的值就是系統的默認值。

            一般就算設置了表的默認字符集為utf8并且通過UTF-8編碼發送查詢,你會發現存入數據庫的仍然是亂碼。問題就出在這個connection連接層上。解決方法是在發送查詢前執行一下下面這句:

            SET NAMES 'utf8';

            它相當于下面的三句指令:
            SET character_set_client = utf8;
            SET character_set_results = utf8;
            SET character_set_connection = utf8;

            而MySQL數據庫的4.1是一個分水嶺,4.1直接支持Unicode,它以下版本支持的不好; 

            MySQL JDBC Driver的3.0.16也是一個分水嶺,3.0.16版本會取數據庫本身的編碼,然后按照該編碼轉換,這種方式和Oracle的JDBC Driver是一樣的。例如你的數據庫是GBK編碼的話,JDBC Driver就會把數據庫里面的取出來的字符串按照GBK往unicode轉換,送給JVM。因此正確的設置數據庫本身的編碼就尤為重要。 

            MySQL JDBC Driver3.0.16以下的版本則不然,它不會那么智能的根據數據庫編碼來確定如何轉換,它總是默認使用ISO8859-1,因此你必須使用 characterEncoding=GBK來強制他把數據庫中取出來的字符串按照GBK來往unicode轉換。 

            因此,使用什么數據庫版本,不管是3.x,還是4.0.x還是4.1.x,其實對我們來說不重要,重要的有二: 

            1) 正確的設定數據庫編碼,MySQL4.0以下版本的字符集總是默認ISO8859-1,MySQL4.1在安裝的時候會讓你選擇。如果你準備使用UTF- 8,那么在創建數據庫的時候就要指定好UTF-8(創建好以后也可以改,4.1以上版本還可以單獨指定表的字符集) 

            2) 使用3.0.16以上版本的JDBC Driver,那么你就不需要再寫什么characterEncoding=UTF-8


            轉自:

            http://www.blogjava.net/bonix/articles/159291.html
            posted on 2012-05-08 17:12 會飛的兔子 閱讀(619) 評論(0)  編輯 收藏 引用 所屬分類: 數據庫,MIS系統
            国内精品伊人久久久久AV影院| 情人伊人久久综合亚洲| 久久这里的只有是精品23| 久久久久亚洲AV成人网人人网站| 97久久婷婷五月综合色d啪蜜芽 | 久久乐国产综合亚洲精品| 精品久久久久久中文字幕大豆网| 久久国产欧美日韩精品| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 久久精品国产精品亚洲精品 | 人人狠狠综合88综合久久| 亚洲性久久久影院| 99久久人妻无码精品系列| 久久综合色之久久综合| 99精品国产在热久久无毒不卡| 久久久久久亚洲精品不卡| 无码国内精品久久人妻蜜桃| 精品国产婷婷久久久| 久久综合狠狠综合久久| 欧美精品丝袜久久久中文字幕| 91精品国产综合久久久久久| 无码国内精品久久综合88| 国产成人无码精品久久久免费| 99久久精品免费看国产一区二区三区| 国产99久久九九精品无码| 国产V综合V亚洲欧美久久| 香蕉久久夜色精品升级完成| 无码精品久久一区二区三区| 91精品国产高清久久久久久91| 国产成人久久精品区一区二区| 亚洲熟妇无码另类久久久| 欧美国产成人久久精品| 国产精品久久久香蕉| 中文字幕无码av激情不卡久久 | 综合久久精品色| 久久久久久青草大香综合精品| 色综合合久久天天综合绕视看 | 伊人久久五月天| 久久天天日天天操综合伊人av| 狠狠久久综合伊人不卡| 久久久久亚洲精品天堂久久久久久|