推薦：sql寫(xiě)注冊(cè)表語(yǔ)句例句
首先開(kāi)啟沙盤(pán)模式： exec master..xp_regwrite 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Jet\4.0\Engines','SandBoxMode','REG_DWORD',1 讀注冊(cè)表 exec master..xp_regread 'HKEY_LOCAL_MACHINE','SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon','Userinit

　　其他的，character_set_filesystem：把操作系統(tǒng)上的字符轉(zhuǎn)換成此字符集，即把character_set_client轉(zhuǎn)換成character_set_filesystem，默認(rèn)為binary則不轉(zhuǎn)換，character_set_system：此變量總是utf8，為存儲(chǔ)系統(tǒng)元字符的字符集，如表名、列名、用戶(hù)名等，character_set_dir：很明顯是指示一個(gè)目錄的變量，打開(kāi)這個(gè)目錄，里邊存放的是mysql的各種用于編碼字符集的xml格式文件。以上三個(gè)值在解決亂碼問(wèn)題時(shí)基本可忽視。

　　好，轉(zhuǎn)換流程和各變量的含義清楚了，就要搞清楚哪些字符集編碼之間可以轉(zhuǎn)換，能轉(zhuǎn)換可能也是在一定編碼范圍內(nèi)的字符能轉(zhuǎn)換，不至于出現(xiàn)亂碼甚至損壞。損壞了就再也無(wú)法正確顯示了，哪怕設(shè)置是正確的，還原是還原不回來(lái)的。當(dāng)然關(guān)于字符之間的轉(zhuǎn)化情況很多，字符集有那么多種，隨便兩個(gè)之間都可以轉(zhuǎn)換一下試試，不能一一列舉，可以參考這篇文章：http://www.imcjd.com/?p=1324，它針對(duì)經(jīng)常用到的字符轉(zhuǎn)換作了一些轉(zhuǎn)換比較和測(cè)試。

　　其中，可以了解到，完全匹配的轉(zhuǎn)換是肯定沒(méi)有問(wèn)題的，比如，gbk->gbk，utf8->utf8，latin1->latin1;轉(zhuǎn)換為單字節(jié)編碼的latin1也沒(méi)問(wèn)題，比如gbk->latin1、utf8->latin1;單字節(jié)編碼(latin1)轉(zhuǎn)為其他在某些編碼某些范圍內(nèi)可能會(huì)出現(xiàn)轉(zhuǎn)換不全，比如latin1->gbk(很特殊的中文)，或者編碼長(zhǎng)度改變，比如latin1->utf8，變?yōu)?、3等字節(jié)數(shù)。

　　下面引用另一篇文章(http://hi.baidu.com/cuttinger/item/f4e79726a60ab450c28d59da)中的一段。

　　【Latin1是一種很常見(jiàn)的字符集，這種字符集是單字節(jié)編碼，向下兼容ASCII，其編碼范圍是0x00-0xFF，0x00-0x7F之間完全和ASCII一致，0x80-0x9F之間是控制字符，0xA0-0xFF之間是文字符號(hào)。很明顯，Latin1覆蓋了所有的單字節(jié)，因此，可以將任意字符串保存在latin1字符集中，而不用擔(dān)心有內(nèi)容不符合latin1的編碼規(guī)范而被拋棄。——gbk和utf8是多字節(jié)編碼，沒(méi)有這種特性。

　　mysql使用者經(jīng)常利用Latin1的這種全覆蓋特性，將其它類(lèi)型的字符串，gbk,utf8,big5等，保存在latin1列中。保存的過(guò)程中沒(méi)有數(shù)據(jù)丟失，只要原樣取出來(lái)，便又是合法的gbk/utf8/big字符串。如果將gbk字符串保存在utf8列中，則gbk字符串中那些不符合utf8編碼格式的內(nèi)容，會(huì)被拋棄，保存的內(nèi)容無(wú)法原樣取出，數(shù)據(jù)實(shí)際上遭到了破壞。

　　綜上，如果我們看到一個(gè)字段的字符集是latin1的，那么，他保存的可能是任何編碼的字符串;而一個(gè)字段的字符集是utf8或者gbk的，那么他保存的就應(yīng)該是utf8或gbk的——除非數(shù)據(jù)庫(kù)的使用者用錯(cuò)了�！�

　　我沒(méi)有深入學(xué)習(xí)過(guò)utf8、gbk編碼的細(xì)節(jié)，極可能說(shuō)的不準(zhǔn)確，只知道簡(jiǎn)單的ASCII編碼(-_-)，但是可以了解個(gè)全局情況。從上面來(lái)看，latin1的單字節(jié)編碼方式很有用，其他的編碼可以轉(zhuǎn)換為它再轉(zhuǎn)回去而不至于丟失內(nèi)容。所謂單字節(jié)編碼就是挨著一個(gè)個(gè)來(lái)，我理解是，比如圣誕節(jié)到了，你要送妹子一箱蘋(píng)果，為制造浪漫，商鋪提供兩種包裝方式，一是按個(gè)數(shù)來(lái)，即單個(gè)蘋(píng)果包裝進(jìn)一個(gè)盒子，來(lái)一個(gè)包裝一個(gè)，這樣，妹子在拆完所有的盒子后完完整整的可以還原為一個(gè)個(gè)完整的和一箱完好無(wú)損的蘋(píng)果，二是按重量來(lái)，每個(gè)盒子限重2兩、3兩、6兩，這樣在包裝時(shí)，若剛好重3兩的當(dāng)然可以完整的放進(jìn)一個(gè)盒子，但是若不夠或者多了，勉不了要切開(kāi)蘋(píng)果，或者再往盒子中添加其他的部分蘋(píng)果，這樣的話(huà)，妹子再無(wú)論怎樣拆開(kāi)盒子，都會(huì)得到一箱殘缺不堪的蘋(píng)果了，因?yàn)槟阍诎凑者@種包裝方式進(jìn)行時(shí)，已經(jīng)破壞了單個(gè)蘋(píng)果的完整性，現(xiàn)在還原不回來(lái)了~我們的字符集編碼轉(zhuǎn)換就是在做這種重新包裝的工作，latin1恰好就像單個(gè)蘋(píng)果包裝，而utf8就像第二種方式。

　　而剛才說(shuō)的完全匹配的情況是，你去買(mǎi)一箱蘋(píng)果，箱子里邊的所有蘋(píng)果重量已經(jīng)恰好要么是2兩，要么是3兩或6兩的，這樣再按重量包裝時(shí)當(dāng)然就恰好分配了，得到的仍然是完整的蘋(píng)果。

　　所以說(shuō)白了，兩種可行的方式是：

　　1. 所有變量均設(shè)置成latin1(set names latin1;)，這樣，即便我們所使用的編輯客戶(hù)端編碼多樣(gbk或utf8)，最終可以得到正確結(jié)果;

　　2. 所有的設(shè)置成gbk或者gb2312(國(guó)標(biāo)編碼，只用于簡(jiǎn)體中文)，采用完全匹配;

　　3. 針對(duì)中間的轉(zhuǎn)換過(guò)程，比如gbk輸入，將character_set_client、character_set_connection視為latin1，character_set_database設(shè)為gb2312，建表時(shí)定字符集為gb2312，character_set_results也可以定為gb2312，當(dāng)然這只是雞肋，本質(zhì)上還是用了latin1，gbk轉(zhuǎn)latin1再轉(zhuǎn)gb2312時(shí)只適用于簡(jiǎn)體。

　　最后，關(guān)于字符集校對(duì)規(guī)則，只了解一點(diǎn)。在我們?cè)O(shè)置mysql字符集時(shí)，mysql會(huì)自動(dòng)給一個(gè)對(duì)應(yīng)的校對(duì)規(guī)則，比如設(shè)置charset為utf8，默認(rèn)的collation就是utf8_general_ci，gb2312字符集對(duì)應(yīng)gb2312_chinese_ci，mysql命令查看所有校對(duì)規(guī)則是show collation，查看某一對(duì)應(yīng)字符集的校對(duì)規(guī)就是show collation like 'utf8%'了。

　　字符集校對(duì)是一種對(duì)使用當(dāng)前字符集時(shí)采用的排序、對(duì)比方式，即便同一種字符集，在不同的地區(qū)也是不同的對(duì)比方式，所以才有校對(duì)這么一說(shuō)，比如utf8_general_ci，這個(gè)ci就是case insensitive，即大小寫(xiě)不敏感，采用它校對(duì)時(shí)，查詢(xún)某字段值匹配時(shí)，大小寫(xiě)的記錄都會(huì)出現(xiàn)，當(dāng)然還有其他的規(guī)則，utf8打印出來(lái)一大坨，不細(xì)研究了~

分享：sql檢測(cè)是否為SA權(quán)限語(yǔ)句
檢測(cè)是否為SA權(quán)限 and 1=(select IS_SRVROLEMEMBER('sysadmin'));-- And char(124)%2BCast(IS_SRVROLEMEMBER(0x730079007300610064006D0069006E00) as varchar(1))%2Bchar(124)=1 --