• <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>

            c++實(shí)例研究

            從0開始

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              104 隨筆 :: 0 文章 :: 20 評(píng)論 :: 0 Trackbacks

            MySQL 的 collation 收藏
            先轉(zhuǎn)一別人的學(xué)習(xí)文章做個(gè)引子和基礎(chǔ)
            http://logzgh.itpub.net/post/3185/467401

            在以前用oracle的時(shí)候,很少關(guān)于它的collation方法,但是在mysql中,這點(diǎn)不加注意的話,卻有可能會(huì)出現(xiàn)問題。

            問題是這樣的:
            一張test的表,字符集采用的latin1。

            select to_id from test where to_id='cn象_王';
            +---------------+
            | to_id |
            +---------------+
            | cn陶_陶 |
            | cn象_王 |
            +---------------+
            2 rows in set (0.00 sec)


            取cn象_王的數(shù)據(jù),居然把cn陶_陶的數(shù)據(jù)也取回來了。


            這顯然是不允許的。


            查看它們的編碼:

            (root@im_offlog1a)[test]> select hex('cn陶_陶');
            +----------------+
            | hex('cn陶_陶') |
            +----------------+
            | 636ECCD55FCCD5 |
            +----------------+
            1 row in set (0.00 sec)

            (root@im_offlog1a)[test]> select hex('cn象_王');
            +----------------+
            | hex('cn象_王') |
            +----------------+
            | 636ECFF35FCDF5 |
            +----------------+
            1 row in set (0.00 sec)

            編碼的確是不一樣的,但是為什么mysql會(huì)認(rèn)為這兩條記錄是一樣的呢?

            一開始我們就把問題定位于collation引起的問題。

            show variables查看
            | collation_connection | latin1_swedish_ci
            | collation_database | latin1_swedish_ci
            | collation_server | latin1_swedish_ci


            手工把這些參數(shù)修改為latin1_bin,結(jié)果居然一樣。這下感覺真是奇怪了。

            這里先解釋一下mysql collation的命名規(guī)則:
            它們以其相關(guān)的字符集名開始,通常包括一個(gè)語言名,并且以_ci(大小寫不敏感)、_cs(大小寫敏感)或_bin(二元)結(jié)束

            比如latin1字符集有以下幾種校正規(guī)則:

            校對(duì)規(guī)則 含義
            latin1_german1_ci 德國(guó)DIN-1
            latin1_swedish_ci 瑞典/芬蘭
            latin1_danish_ci 丹麥/挪威
            latin1_german2_ci 德國(guó) DIN-2
            latin1_bin 符合latin1編碼的二進(jìn)制
            latin1_general_ci 多種語言(西歐)
            latin1_general_cs 多種語言(西歐ISO),大小寫敏感
            latin1_spanish_ci 現(xiàn)代西班牙


            最后我們將表格重建,手工指定表格級(jí)別的collation為latin1_bin。
            這個(gè)問題就得到了解決。


            那么問題又來了,為什么我前面手工測(cè)試latin1_bin時(shí)不生效呢?

            原來MySQL按照下面的方式選擇表字符集和 校對(duì)規(guī)則:
            如果指定了CHARACTER SET X和COLLATE Y,那么采用CHARACTER SET X和COLLATE Y。
            如果指定了CHARACTER SET X而沒有指定COLLATE Y,那么采用CHARACTER SET X和CHARACTER SET X的默認(rèn)校對(duì)規(guī)則。
            否則,采用服務(wù)器字符集和服務(wù)器校對(duì)規(guī)則。

            而我們?cè)诮ū淼臅r(shí)候指定了character set,所以它永遠(yuǎn)是采用對(duì)應(yīng)的默認(rèn)的校對(duì)規(guī)則。

            當(dāng)然我們其實(shí)也沒必要重建表格,只需要alter table db_allot CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin這樣轉(zhuǎn)換即可。

            另外建議collation都盡量采用字符集相應(yīng)的bin類型的校對(duì)規(guī)則,這樣不容易出錯(cuò)。


            再說說我自己的體會(huì)

            覺得 character set latin1 collate latin1_bin 就是老版的 VARCHAR BINARY 的改進(jìn),只是新版的先用 character set 定字符集,再用此字符集名字加 _bin 定校對(duì)規(guī)則為二進(jìn)制的,從而確保中文查詢正確。
            再測(cè)試了一下,把此字段屬性改為不帶 BINARY 的
            ALTER TABLE `comment_content_1_01` CHANGE `thread` `thread` VARCHAR( 50 ) DEFAULT NULL
            然后再看表結(jié)構(gòu)確實(shí)變成   `thread` varchar(50) default NULL, 即不帶 character set latin1 collate latin1_bin 了,可見character set latin1 collate latin1_bin 就是老版的 VARCHAR BINARY 的改進(jìn)。

            此外還讀到更方便的做法,不用逐個(gè)改字段屬性,而只要表格級(jí)別的collation為latin1_bin就行了。
            測(cè)試:
            alter table  comment_content_1_01 CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin
            后,

            再導(dǎo)出表結(jié)構(gòu)


            CREATE TABLE comment_content_1_01 (
              content_id int(11) NOT NULL auto_increment,
              thread varchar(50) collate latin1_bin default NULL,
              uname varchar(100) collate latin1_bin default NULL,
              nick varchar(100) collate latin1_bin default NULL,
              uid int(11) unsigned default NULL,
              content text collate latin1_bin,
              post_time datetime default NULL,
              post_ip int(10) unsigned default NULL,
              `status` enum('unaudit','normal','deleted') collate latin1_bin NOT NULL default 'unaudit',
              PRIMARY KEY  (content_id)
            ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_bin;

             

            即便原來沒定各字段的 collate,現(xiàn)在也全都是 collate latin1_bin 了。


            本文來自CSDN博客,轉(zhuǎn)載請(qǐng)標(biāo)明出處:http://blog.csdn.net/xfsnow/archive/2008/09/05/2885948.aspx

            posted on 2010-06-20 11:36 elprup 閱讀(194) 評(píng)論(0)  編輯 收藏 引用 所屬分類: web開發(fā)
            亚洲国产成人久久综合碰| 国内精品久久国产| 久久久久久久免费视频| 少妇人妻综合久久中文字幕| 久久久久香蕉视频| 影音先锋女人AV鲁色资源网久久| 久久91综合国产91久久精品| 99久久国产综合精品五月天喷水 | 999久久久免费国产精品播放| 国产精品美女久久久网AV| 综合人妻久久一区二区精品| 久久久婷婷五月亚洲97号色| 亚洲一级Av无码毛片久久精品| 777午夜精品久久av蜜臀| 欧美777精品久久久久网| 久久精品国产亚洲AV无码娇色| 精品久久久久久无码免费| 久久99精品久久久久久噜噜| 亚洲精品国精品久久99热一| 欧美国产成人久久精品| 国产精品久久久久影院嫩草| 久久久亚洲欧洲日产国码二区| 久久高潮一级毛片免费| 精品国产福利久久久| 伊人久久无码中文字幕| 久久精品国产精品亚洲| 91精品国产综合久久久久久| AV无码久久久久不卡蜜桃| 精品国产青草久久久久福利| 久久精品国产一区二区三区日韩| 欧美牲交A欧牲交aⅴ久久| 精品蜜臀久久久久99网站| 国产精品久久久久9999| 亚洲国产精品无码成人片久久| 思思久久好好热精品国产| 久久人人爽人人精品视频| 色播久久人人爽人人爽人人片AV| 久久久精品国产Sm最大网站| 99久久精品免费看国产一区二区三区 | 欧美精品久久久久久久自慰| 亚洲va久久久噜噜噜久久男同|