我们的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编码中也 存在相应问题。
CP936和GBK的有些许差别,绝大多数情况下可以把CP936当作GBK的别名。
GB18030
GB18030编码向下兼容GBK和GB2312,兼容的含义是不仅字符兼容,而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符,包括中国少数民族字符,GBK不支持的韩文字符等等,也可以说是世界大多民族的文字符号都被收录在内。
GBK和GB2312都是双字节等宽编码,如果算上和ASCII兼容所支持的单字节,也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码,有单字节、双字节和四字节三种方式。
GB18030 的单字节编码范围是0x00-0x7F,完全等同与ASCII;双字节编码的范围和GBK相同,高字节是0x81-0xFE,低字节的编码范围是0x40 -0x7E和0x80-FE;四字节编码中第一、三字节的编码范围是0x81-0xFE,二、四字节是0x30-0x39。
Windows 中CP936代码页使用0x80来表示欧元符号,而在GB18030编码中没有使用0x80编码位,用其他位置来表示欧元符号。这可以理解为是 GB18030向下兼容性上的一点小问题;也可以理解为0x80是CP936对GBK的扩展,而GB18030只是和GBK兼容良好。
unicode
每一种语言的不同的编码页,增加了那些需要支持不同语言的软件的复杂度。因而人们制定了一个世界标准,叫做unicode。unicode为每个字符提供 了唯一的特定数值,不论在什么平台上、不论在什么软件中,也不论什么语言。也就是说,它世界上使用的所有字符都列出来,并给每一个字符一个唯一特定数值。
Unicode的最初目标,是用1个16位的编码来为超过65000字符提供映射。但这还不够,它不能覆盖全部历史上的文字,也不能解决传输的问题 (implantation head-ache's),尤其在那些基于网络的应用中。已有的软件必须做大量的工作来程序16位的数据。
因 此,Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示,在UTF-8中,字符是 以8位序列来编码的,用一个或几个字节来表示一个字符。这种方式的最大好处,是UTF-8保留了ASCII字符的编码做为它的一部分,例如,在UTF-8 和ASCII中,“A”的编码都是0x41.
UTF-16和UTF-32分别是Unicode的16位和32位编码方式。考虑到最初的目的,通常说的Unicode就是指UTF-16。在讨论Unicode时,搞清楚哪种编码方式非常重要。
UTF-8
Unicode Transformation Format-8bit,允许含BOM,但通常不含BOM。是用以解决国际上字符的一种多字节编码,它对英文使用8位(即一个字节),中文使用24为(三 个字节)来编码。UTF-8包含全世界所有国家需要用到的字符,是国际编码,通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显 示。如,如果是UTF8编码,则在外国人的英文IE上也能显示中文,他们无需下载IE的中文语言支持包。
GBK的文字编码是用双字节来表示的,即不论中、英文字符均使用双字节来表示,为了区分中文,将其最高位都设定成1。GBK包含全部中文字符,是国家编码,通用性比UTF8差,不过UTF8占用的数据库比GBD大。
GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:
GBK、GB2312→Unicode→UTF8
UTF8→Unicode→GBK、GB2312
对于一个网站、论坛来说,如果英文字符较多,则建议使用UTF-8节省空间。不过现在很多论坛的插件一般只支持GBK。
Windows的ANSI
为使计算机支持更多语言,通常使用 0x80~0xFF 范围的 2 个字节来表示 1 个字符。比如:汉字 '中' 在中文操作系统中,使用 [0xD6,0xD0] 这两个字节存储。
不同的国家和地区制定了不同的标准,由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式,称为 ANSI 编码。在简体中文系统下,ANSI 编码代表 GB2312 编码,在日文操作系统下,ANSI 编码代表 JIS 编码。
不同 ANSI 编码之间互不兼容,当信息在国际间交流时,无法将属于两种语言的文字,存储在同一段 ANSI 编码的文本中。
分享到:
相关推荐
MySQL汉字拼音数据库是一种用于存储和查询汉字与其相关拼音信息的资源,它通常包含多个字段,如汉字、繁体字、拼音、笔画数以及汉字的解释等。这样的数据库对于开发涉及中文处理的应用程序,比如搜索引擎优化、中文...
《全球城市中文-拼音-英文名数据库:MySQL中的地理信息宝藏》 在信息化时代,数据是推动各行各业发展的关键要素之一,尤其是地理位置数据,它在地图服务、导航系统、旅游推荐、物流配送等领域扮演着至关重要的角色...
MySQL中文拼音数据库是一种专门用于处理中文字符到其拼音转化的数据资源,它包含了6565个汉字的全拼和首字母信息。这个数据库是用MySQL这种关系型数据库管理系统构建的,设计时考虑到了高效检索和数据存储的需求。...
在使用Hibernate进行数据库操作时,可能会遇到MySQL数据库中文排序不正确的问题。这通常是由于字符集设置、数据库排序规则以及Hibernate的配置等因素导致的。本文将深入探讨如何解决这些问题,确保MySQL数据库中的...
在数据库设计时,可以创建一个特殊的数据表,包含汉字、拼音首码、五笔首码等字段。当用户输入拼音或五笔首码时,数据库系统可以通过索引快速匹配相应的汉字记录。这需要数据库具备高效的全文搜索或者模糊匹配能力,...
MySQL的`CONVERT()`函数可以帮助我们将UTF-8编码的字段转换为GBK,以便进行拼音排序: ```sql SELECT * FROM test ORDER BY CONVERT(value USING GBK) ASC; ``` 如果数据库字段确实使用的是UTF-8,确保在执行此...
在MySQL数据库中,有时我们需要对汉字字段按照汉字的拼音顺序进行排序,这在处理中文数据时非常实用。本文将详细讲解如何实现这一功能,主要针对GBK和UTF-8两种字符集的情况。 首先,GBK字符集是一种双字节编码标准...
为了对中文字段进行拼音排序,我们可以利用`CONVERT`函数配合特定的字符集。例如,如果我们知道`user_name`字段使用的是GBK编码,可以使用以下语句: ```sql SELECT * FROM user ORDER BY CONVERT(user_name USING ...
5. **查询与分析**:使用SQL查询语言从数据库中提取所需的信息,例如按拼音排序、查找特定经纬度范围内的城市等。 6. **安全性与性能优化**:设置合适的权限,确保数据安全,并根据需要进行索引优化,提升查询效率。...
在这个“MYSQL汉字字典词典数据库合集”中,包含了两个关键的表:`word` 和 `words`,它们分别用于存储汉字字典和词典信息。 `word` 表很可能是用来存储单个汉字的数据库表,每个记录可能包含以下字段: 1. `id`:...
在MySQL数据库中,有时我们需要对包含汉字的字段提取每个汉字的首字母,例如用于拼音排序或创建基于拼音的索引。这个问题可以通过编写一个自定义函数来解决,正如给定的代码片段所示。下面我们将详细讨论这个过程。 ...
在数据库中,拼音字段可以帮助进行基于拼音的搜索,比如拼音排序或模糊搜索。 5. **经纬度**:经度和纬度是地理坐标系统的一部分,用于确定地球表面的精确位置。在数据库中,这些信息可以用于地图定位、距离计算等...
其次,数据以“数据库表”的形式存在,意味着它们被组织成结构化的数据集,包含字段(如:省级ID、市级ID、区级ID、名称、拼音等)和记录(每个省市区的详细信息)。数据库表是关系型数据库的基础,通过表格形式展示...
3. **按拼音排序**: 如果需要按照汉字的拼音进行排序,可以使用`NLSSORT(columnName,’NLS_SORT=SCHINESE_PINYIN_M’)`。这将按照汉字对应的汉语拼音进行排序,无论是声母、韵母还是声调都会被考虑在内,适合拼音...
7. **mysql的中文数据按拼音排序的2个方法** 8. **MySQL中按照多字段排序及问题解决** 9. **mysql 关键词相关度排序方法详细示例分析** 总之,选择在PHP还是MySQL中进行排序,需根据实际情况综合考虑数据量、索引、...
通过这样的设计,数据库不仅能够存储大量中国姓氏,还可以支持各种查询,如按拼音查找、按人口数量排序等。此外,这样的数据集对于研究姓氏分布、文化变迁、人口统计等方面都有极大的价值。 在实际应用中,开发人员...
Java拼音搜索是一个在Java开发中常见的功能,尤其在构建搜索引擎或者中文输入法时,将汉字转化为拼音以便于处理和...开发者可以在这个基础上进一步扩展,如增加拼音排序、语音输入支持等功能,以满足不同场景下的需求。