網(wǎng)站建設(shè)需要哪些步驟灰色seo推廣
前言
嗨嘍，大家好呀~這里是愛看美女的茜茜吶
我們的MySQL使用latin1的默認(rèn)字符集，
也就是說，對(duì)漢字字段直接使用GBK內(nèi)碼的編碼進(jìn)行存儲(chǔ)，
當(dāng)需要對(duì)一些有漢字的字段進(jìn)行拼音排序時(shí)（特別涉及到類似于名字這樣的字段時(shí)），默認(rèn)無法通過order by關(guān)鍵字正確排序。
👇 👇 👇 更多精彩機(jī)密、教程，盡在下方，趕緊點(diǎn)擊了解吧~
python資料、視頻教程、代碼、插件安裝教程等我都準(zhǔn)備好了，直接在文末名片自取就可
經(jīng)過網(wǎng)上查找，網(wǎng)上的辦法大多是針對(duì)使用utf8字符集的數(shù)據(jù)庫，主要的方法有：
1）直接轉(zhuǎn)換字段為gbk，比如：
SELECT * FROM table ORDER BY CONVERT( chinese_field USING gbk ) ;
或者干脆將相應(yīng)字段改為gbk字符集。
我在我的數(shù)據(jù)庫測試了上面的方法，或者直接按字段排序，都不行，主要是排序結(jié)果不理想。
2）查表法
創(chuàng)建一個(gè)新表，用來存儲(chǔ)拼音聲母和使用該聲母的漢字首字的對(duì)應(yīng)關(guān)系。
然后寫一個(gè)函數(shù)，每次排序時(shí)通過轉(zhuǎn)換為gbk再查表的方法得到字段內(nèi)容首字的聲母的方法。
這個(gè)方法我也試了，太麻煩，而且針對(duì)我的數(shù)據(jù)庫，也不能正確排序。
后來，我查詢了漢字編碼的一些資料，發(fā)現(xiàn)GBK內(nèi)碼編碼時(shí)本身就采用了拼音排序的方法（常用一級(jí)漢字3755個(gè)采用拼音排序，二級(jí)漢字就不是了，但考慮到人名等都是常用漢字，因此只是針對(duì)一級(jí)漢字能正確排序也夠用了）。
根據(jù)這個(gè)原理，直接按字段排序就應(yīng)該可以的（我的數(shù)據(jù)庫使用Latin1字符集，存的漢字本來就是GBK內(nèi)碼），但我試了以后發(fā)現(xiàn)不行。
參考上面方法2的查表法，我把字段內(nèi)容轉(zhuǎn)換為16進(jìn)制編碼，再排，就OK了！
這就是最終的辦法：SELECT * FROM table ORDER BY hex( chinese_field ) 簡單吧！
這是我的例子數(shù)據(jù)排序輸出的結(jié)果，如下圖：
附：漢字編碼方式簡介
ASCII
ASCII碼是7位編碼，編碼范圍是0x00-0x7F。
ASCII字符集包括英文字母、阿拉伯?dāng)?shù)字和標(biāo)點(diǎn)符號(hào)等字符。
其中0x00-0x20和0x7F共33個(gè)控制字符。
只支持ASCII碼的系統(tǒng)會(huì)忽略每個(gè)字節(jié)的最高位，只認(rèn)為低7位是有效位。
HZ字符編碼就是早期為了在只支持7位ASCII系統(tǒng)中傳輸中文而設(shè)計(jì)的編碼。
早期很多郵件系統(tǒng)也只支持ASCII編碼，為了傳輸中文郵件必須使用BASE64或者其他編碼方式。
GB2312
GB2312 是基于區(qū)位碼設(shè)計(jì)的，區(qū)位碼把編碼表分為94個(gè)區(qū)，每個(gè)區(qū)對(duì)應(yīng)94個(gè)位，每個(gè)字符的區(qū)號(hào)和位號(hào)組合起來就是該漢字的區(qū)位碼。
區(qū)位碼一般 用10進(jìn)制數(shù)來表示，如1601就表示16區(qū)1位，對(duì)應(yīng)的字符是“啊”。
在區(qū)位碼的區(qū)號(hào)和位號(hào)上分別加上0xA0就得到了GB2312編碼。
區(qū)位碼中01-09區(qū)是符號(hào)、數(shù)字區(qū)，16-87區(qū)是漢字區(qū)，10-15和88-94是未定義的空白區(qū)。
它將收錄的漢字分成兩級(jí)：
-
第一級(jí)是常用漢字計(jì) 3755個(gè)，置于16-55區(qū)，按漢語拼音字母/筆形順序排列；
-
第二級(jí)漢字是次常用漢字計(jì)3008個(gè)，置于56-87區(qū)，按部首/筆畫順序排列。
一級(jí)漢字 是按照拼音排序的，這個(gè)就可以得到某個(gè)拼音在一級(jí)漢字區(qū)位中的范圍，很多根據(jù)漢字可以得到拼音的程序就是根據(jù)這個(gè)原理編寫的。
GB2312字符集中除常用簡體漢字字符外還包括希臘字母、日文平假名及片假名字母、俄語西里爾字母等字符，未收錄繁體中文漢字和一些生僻字。
可以用繁體漢字測試某些系統(tǒng)是不是只支持GB2312編碼。
GB2312的編碼范圍是0xA1A1-0x7E7E，去掉未定義的區(qū)域之后可以理解為實(shí)際編碼范圍是0xA1A1-0xF7FE。
EUC-CN可以理解為GB2312的別名，和GB2312完全相同。
區(qū)位碼更應(yīng)該認(rèn)為是字符集的定義，定義了所收錄的字符和字符位置，而GB2312及EUC-CN是實(shí)際計(jì)算機(jī)環(huán)境中支持這種字符集的編碼。
HZ和ISO-2022-CN是對(duì)應(yīng)區(qū)位碼字符集的另外兩種編碼，都是用7位編碼空間來支持漢字。區(qū)位碼和GB2312編碼的關(guān)系有點(diǎn)像 和。
GBK
GBK 編碼是GB2312編碼的超集，向下完全兼容GB2312，同時(shí)GBK收錄了Unicode基本多文種平面中的所有CJK漢字。
同 GB2312一樣，GBK也支持希臘字母、日文假名字母、俄語字母等字符，但不支持韓語中的表音字符（非漢字字符）。
GBK還收錄了GB2312不包含的 漢字部首符號(hào)、豎排標(biāo)點(diǎn)符號(hào)等字符。
GBK的整體編碼范圍是為0x8140-0xFEFE，不包括低字節(jié)是0×7F的組合。
高字節(jié)范圍是0×81-0xFE，低字節(jié)范圍是0x40-7E和0x80-0xFE。
低字節(jié)是0x40-0x7E的GBK字符有一定特殊性，因?yàn)檫@些字符占用了ASCII碼的位置，這樣會(huì)給一些系統(tǒng)帶來麻煩。
有些系統(tǒng)中用0x40-0x7E中的字符（如“|”）做特殊符號(hào)，在定位這些符號(hào)時(shí)又沒有判斷這些符號(hào)是不是屬于某個(gè) GBK字符的低字節(jié)，這樣就會(huì)造成錯(cuò)誤判斷。
在支持GB2312的環(huán)境下就不存在這個(gè)問題。
需要注意的是支持GBK的環(huán)境中小于0x80的某個(gè)字節(jié)未必就 是ASCII符號(hào)；另外就是最好選用小于0×40的ASCII符號(hào)做一些特殊符號(hào)，這樣就可以快速定位，且不用擔(dān)心是某個(gè)漢字的另一半。
Big5編碼中也 存在相應(yīng)問題。
CP936和GBK的有些許差別，絕大多數(shù)情況下可以把CP936當(dāng)作GBK的別名。
GB18030
GB18030編碼向下兼容GBK和GB2312，兼容的含義是不僅字符兼容，而且相同字符的編碼也相同。
GB18030收錄了所有Unicode3.1中的字符，包括中國少數(shù)民族字符，GBK不支持的韓文字符等等，也可以說是世界大多民族的文字符號(hào)都被收錄在內(nèi)。
GBK和GB2312都是雙字節(jié)等寬編碼，如果算上和ASCII兼容所支持的單字節(jié)，也可以理解為是單字節(jié)和雙字節(jié)混合的變長編碼。
GB18030編碼是變長編碼，有單字節(jié)、雙字節(jié)和四字節(jié)三種方式。
-
GB18030 的單字節(jié)編碼范圍是0x00-0x7F，完全等同與ASCII；
-
雙字節(jié)編碼的范圍和GBK相同，高字節(jié)是0x81-0xFE，低字節(jié)的編碼范圍是0x40 -0x7E和0x80-FE；
-
四字節(jié)編碼中第一、三字節(jié)的編碼范圍是0x81-0xFE，二、四字節(jié)是0x30-0x39。
Windows 中CP936代碼頁使用0x80來表示歐元符號(hào)，而在GB18030編碼中沒有使用0x80編碼位，用其他位置來表示歐元符號(hào)。這可以理解為是 GB18030向下兼容性上的一點(diǎn)小問題；
也可以理解為0x80是CP936對(duì)GBK的擴(kuò)展，而GB18030只是和GBK兼容良好。
unicode
每一種語言的不同的編碼頁，增加了那些需要支持不同語言的軟件的復(fù)雜度。
因而人們制定了一個(gè)世界標(biāo)準(zhǔn)，叫做unicode。
unicode為每個(gè)字符提供 了唯一的特定數(shù)值，不論在什么平臺(tái)上、不論在什么軟件中，也不論什么語言。
也就是說，它世界上使用的所有字符都列出來，并給每一個(gè)字符一個(gè)唯一特定數(shù)值。
Unicode的最初目標(biāo)，是用1個(gè)16位的編碼來為超過65000字符提供映射。
但這還不夠，它不能覆蓋全部歷史上的文字，也不能解決傳輸?shù)膯栴} (implantation head-ache’s)，尤其在那些基于網(wǎng)絡(luò)的應(yīng)用中。
已有的軟件必須做大量的工作來程序16位的數(shù)據(jù)。
因 此，Unicode用一些基本的保留字符制定了三套編碼方式。
它們分別是UTF-8,UTF-16和UTF-32。
正如名字所示，在UTF－8中，字符是 以8位序列來編碼的，用一個(gè)或幾個(gè)字節(jié)來表示一個(gè)字符。
這種方式的最大好處，是UTF－8保留了ASCII字符的編碼做為它的一部分，例如，在UTF－8 和ASCII中，“A”的編碼都是0x41.
UTF－16和UTF－32分別是Unicode的16位和32位編碼方式。
考慮到最初的目的，通常說的Unicode就是指UTF-16。在討論Unicode時(shí)，搞清楚哪種編碼方式非常重要。
UTF-8
Unicode Transformation Format-8bit，允許含BOM，但通常不含BOM。
是用以解決國際上字符的一種多字節(jié)編碼，它對(duì)英文使用8位（即一個(gè)字節(jié)），中文使用24為（三 個(gè)字節(jié)）來編碼。
UTF-8包含全世界所有國家需要用到的字符，是國際編碼，通用性強(qiáng)。
UTF-8編碼的文字可以在各國支持UTF8字符集的瀏覽器上顯 示。
如果是UTF8編碼，則在外國人的英文IE上也能顯示中文，他們無需下載IE的中文語言支持包。
GBK的文字編碼是用雙字節(jié)來表示的，即不論中、英文字符均使用雙字節(jié)來表示，為了區(qū)分中文，將其最高位都設(shè)定成1。
GBK包含全部中文字符，是國家編碼，通用性比UTF8差，不過UTF8占用的數(shù)據(jù)庫比GBD大。
GBK、GB2312等與UTF8之間都必須通過Unicode編碼才能相互轉(zhuǎn)換：
-
GBK、GB2312→Unicode→UTF8
-
UTF8→Unicode→GBK、GB2312
對(duì)于一個(gè)網(wǎng)站、論壇來說，如果英文字符較多，則建議使用UTF－8節(jié)省空間。不過現(xiàn)在很多論壇的插件一般只支持GBK。
Windows的ANSI
為使計(jì)算機(jī)支持更多語言，通常使用 0x80~0xFF 范圍的 2 個(gè)字節(jié)來表示 1 個(gè)字符。
比如：漢字 ‘中’ 在中文操作系統(tǒng)中，使用 [0xD6,0xD0] 這兩個(gè)字節(jié)存儲(chǔ)。
不同的國家和地區(qū)制定了不同的標(biāo)準(zhǔn)，由此產(chǎn)生了 GB2312, BIG5, JIS 等各自的編碼標(biāo)準(zhǔn)。
這些使用 2 個(gè)字節(jié)來代表一個(gè)字符的各種漢字延伸編碼方式，稱為 ANSI 編碼。
在簡體中文系統(tǒng)下，ANSI 編碼代表 GB2312 編碼，在日文操作系統(tǒng)下，ANSI 編碼代表 JIS 編碼。
不同 ANSI 編碼之間互不兼容，當(dāng)信息在國際間交流時(shí)，無法將屬于兩種語言的文字，存儲(chǔ)在同一段 ANSI 編碼的文本中。
尾語
感謝你觀看我的文章吶~本次航班到這里就結(jié)束啦 🛬
希望本篇文章有對(duì)你帶來幫助 🎉，有學(xué)習(xí)到一點(diǎn)知識(shí)~
躲起來的星星🍥也在努力發(fā)光，你也要努力加油（讓我們一起努力叭）。
