MySQL汉字字段按拼音排序显示
我们的MySQL使用latin1的默认字符集，也就是说，对汉字字段直接使用GBK内码的编码进行存储，当需要对一些有汉字的字段进行拼音排
我们的MySQL使用latin1的默认字符集，也就是说，对汉字字段直接使用GBK内码的编码进行存储，当需要对一些有汉字的字段进行拼音排序时（特别涉及到类似于名字这样的字段时），默认无法通过order by关键字正确排序。
经过网上查找，网上的办法大多是针对使用utf8字符集的数据库，主要的方法有：
1）直接转换字段为gbk，比如：
SELECT * FROM table ORDER BY CONVERT( chinese_field USING gbk ) ;
或者干脆将相应字段改为gbk字符集。
我在我的数据库测试了上面的方法，或者直接按字段排序，都不行，主要是排序结果不理想。
2）查表法
创建一个新表，用来存储拼音声母和使用该声母的汉字首字的对应关系。然后写一个函数，每次排序时通过转换为gbk再查表的方法得到字段内容首字的声母的方法。
这个方法我也试了，太麻烦，而且针对我的数据库，也不能正确排序。
后来，我查询了汉字编码的一些资料，发现GBK内码编码时本身就采用了拼音排序的方法（常用一级汉字3755个采用拼音排序，二级汉字就不是了，但考虑到人名等都是常用汉字，因此只是针对一级汉字能正确排序也够用了）。根据这个原理，直接按字段排序就应该可以的（我的数据库使用Latin1字符集，存的汉字本来就是GBK内码），但我试了以后发现不行。参考上面方法2的查表法，我把字段内容转换为16进制编码，再排，就OK了！
这就是最终的办法：SELECT * FROM table ORDER BY hex( chinese_field ) 简单吧！
这是我的例子数据排序输出的结果，如下图：
附：汉字编码方式简介
ASCII
ASCII码是7位编码，编码范围是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0x00-0x20和0x7F共33个控制字符。
只支持ASCII码的系统会忽略每个字节的最高位，只认为低7位是有效位。HZ字符编码就是早期为了在只支持7位ASCII系统中传输中文而设计的编码。早期很多邮件系统也只支持ASCII编码，为了传输中文邮件必须使用BASE64或者其他编码方式。
GB2312
GB2312 是基于区位码设计的，区位码把编码表分为94个区，每个区对应94个位，每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般 用10进制数来表示，如1601就表示16区1位，对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。
区位码中01-09区是符号、数字区，，16-87区是汉字区，10-15和88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计 3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。一级汉字 是按照拼音排序的，这个就可以得到某个拼音在一级汉字区位中的范围，很多根据汉字可以得到拼音的程序就是根据这个原理编写的。
GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。
GB2312的编码范围是0xA1A1-0x7E7E，去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。
EUC-CN可以理解为GB2312的别名，和GB2312完全相同。
区位码更应该认为是字符集的定义，定义了所收录的字符和字符位置，而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码，都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像 和。
GBK
GBK 编码是GB2312编码的超集，向下完全兼容GB2312，同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同 GB2312一样，GBK也支持希腊字母、日文假名字母、俄语字母等字符，但不支持韩语中的表音字符（非汉字字符）。GBK还收录了GB2312不包含的 汉字部首符号、竖排标点符号等字符。
GBK的整体编码范围是为0x8140-0xFEFE，不包括低字节是0×7F的组合。高字节范围是0×81-0xFE，低字节范围是0x40-7E和0x80-0xFE。
低字节是0x40-0x7E的GBK字符有一定特殊性，因为这些字符占用了ASCII码的位置，这样会给一些系统带来麻烦。
有些系统中用0x40-0x7E中的字符（如“|”）做特殊符号，在定位这些符号时又没有判断这些符号是不是属于某个 GBK字符的低字节，这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0x80的某个字节未必就 是ASCII符号；另外就是最好选用小于0×40的ASCII符号做一些特殊符号，这样就可以快速定位，且不用担心是某个汉字的另一半。Big5编码中也 存在相应问题。