首頁  >  文章  >  資料庫  >  Mysql中utf8_unicode_ci、utf8_general_ci有什麼差別?

Mysql中utf8_unicode_ci、utf8_general_ci有什麼差別?

不言
不言轉載
2019-03-27 10:04:093689瀏覽

這篇文章帶給大家的內容是關於Mysql中utf8_unicode_ci、utf8_general_ci有什麼差別?有一定的參考價值,有需要的朋友可以參考一下,希望對你有幫助。

Mysql中utf8_general_ci與utf8_unicode_ci有什麼差別呢?在程式語言中,通常用unicode對中文字元做處理,防止亂碼,那麼在MySQL裡,為什麼大家都用utf8_general_ci而不是utf8_unicode_ci呢?

花了這麼長時間,發現自己竟然不知道utf_bin和utf_general_ci這兩者到底有什麼差別。 。
ci是case insensitive, 即"大小寫不敏感", a 和A 會在字符判斷中會被當做一樣的;
bin 是二進制, a 和A 會別區別對待.
例如你運行:
SELECT * FROM table WHERE txt = 'a'
那麼在utf8_bin中你就找不到txt = 'A' 的那一行, 而utf8_general_ci 則可以.
utf8_general_ci 不區分大小寫,這個你在註冊用戶名和郵箱的時候就要使用。
utf8_general_cs 區分大小寫,如果使用者名稱和郵箱用這個 就會照成不良後果
utf8_bin:字串每個字串用二進位資料編譯儲存。區分大小寫,而且可以存二進位的內容

一、官方文件說明
#下面摘錄一下Mysql 5.1中文手冊中關於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,因為它比較準確。

如果你想使用gb2312編碼,那麼建議你使用latin1作為數據表的默認字符集,這樣就能直接用中文在命令行工具中插入數據,並且可以直接顯示出來.而不要使用gb2312或gbk等字元集,如果擔心查詢排序等問題,可以使用binary屬性約束,例如:

create table my_table ( name varchar(20) binary not null default '')type=myisam default charset latin1;

二、簡短總結
utf8_unicode_ci和utf8_general_ci對中、英文來說沒有實質的差別。
utf8_general_ci校對速度快,但準確度稍差。
utf8_unicode_ci準確度高,但校對速度稍慢。

如果你的應用程式有德語、法語或俄語,請一定使用utf8_unicode_ci。一般用utf8_general_ci就夠了,到現在也沒發現問題。 。 。

三、詳細總結

1、對於一種語言僅當使用utf8_unicode_ci排序做的不好時,才執行與具體語言相關的utf8字元集校對規則。例如,對於德語和法語,utf8_unicode_ci工作的很好,因此不再需要為這兩種語言創建特殊的utf8校對規則。
2、utf8_general_ci也適用與德語和法語,除了‘?'等於‘s',而不是‘ss'之外。如果你的應用能夠接受這些,那麼應該使用 utf8_general_ci,因為它速度快。否則,使用utf8_unicode_ci,因為它比較準確。

用一句話概況上面這段話:utf8_unicode_ci比較準確,utf8_general_ci速度比較快。通常情況下utf8_general_ci的準確性就夠我們用的了,在我看過很多程式原始碼後,發現它們大多也用的是utf8_general_ci,所以新建資料庫時一般選用utf8_general_ci就可以了

四、如何在M​​ySQL5.0中使用UTF8
在my.cnf中增加下列參數

[mysqld]
init_connect='SET NAMES utf8′
default-character-set=utf8
default-collation = utf8_general_ci

執行查詢mysql> show variables; 相關如下: 

character_set_client | utf8 
character_set_connection | utf8 
character_set_database | utf8 
character_set_results | utf8 
character_set_server | utf8 
character_set_system | utf8
collation_connection | utf8_general_ci 
collation_database | utf8_general_ci 
collation_server | utf8_general_ci

個人見解,對於資料庫的使用,utf8 - general 已經足夠的準確,並且相較與  utf8 - unicode速度上有優勢,固可放心採用之

附1:旧数据升级办法

以原来的字符集为latin1为例,升级成为utf8的字符集。原来的表: old_table (default charset=latin1),新表:new_table(default charset=utf8)。

第一步:导出旧数据

mysqldump --default-character-set=latin1 -hlocalhost -uroot -B my_db --tables old_table > old.sql

第二步:转换编码(类似unix/linux环境下)

iconv -t utf-8 -f gb2312 -c old.sql > new.sql

或者可以去掉 -f 参数,让iconv自动判断原来的字符集

iconv -t utf-8 -c old.sql > new.sql

在这里,假定原来的数据默认是gb2312编码。

第三步:导入

修改old.sql,在插入/更新语句开始之前,增加一条sql语句: "SET NAMES utf8;",保存。

mysql -hlocalhost -uroot my_db < new.sql

大功告成!!

附2:支持查看utf8字符集的MySQL客户端有
1.) MySQL-Front,据说这个项目已经被MySQL AB勒令停止了,不知为何,如果国内还有不少破解版可以下载(不代表我推荐使用破解版 :-P)。
2.) Navicat,另一款非常不错的MySQL客户端,汉化版刚出来,还邀请我试用过,总的来说还是不错的,不过也需要付费。
3.) PhpMyAdmin,开源的php项目,非常好。
4.) Linux下的终端工具(Linux terminal),把终端的字符集设置为utf8,连接到MySQL之后,执行 SET NAMES UTF8; 也能读写utf8数据了。

本篇文章到这里就已经全部结束了,更多其他精彩内容可以关注PHP中文网的MySQL视频教程栏目!

以上是Mysql中utf8_unicode_ci、utf8_general_ci有什麼差別?的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文轉載於:jb51.net。如有侵權,請聯絡admin@php.cn刪除