Sqlite是一个用C语言实现的小型SQL数据库引擎。它体积小巧但功能强大，对硬件资源要求很低而且性能表现卓越，非常适合于嵌入式应用环境。最近发现sqlite并不支持中文(拼音/笔画)排序，而这个功能又是我们必需的，所以花了些时间去研究。我对Sqlite的了解只能算是业余级，在研究的过程或许走了些弯路，或许已经有现存的算法可利用，不管怎么样，在研究过程中还是有不少收获，写出来和大家探讨一下。

　　我们知道，计算机中的每一个字符都有一个内码。在默认情况下，计算机排序时，比较两个字符的大小就是比较字符内码的大小，这对于英文来说没有问题，因为英文字母的内码是按字母顺序递增的。对于中文来说，就比较麻烦了：首先，中文的排序方式有多种，比如按内码排序、按拼音排序和按笔画排序，要通过参数指定排序的方式，否则计算机就按内码排序了。其次，汉字的内码顺序即不同于拼音顺序，也不同于按笔画顺序。在GB2312编码中，汉字基本上按拼音排序(据说有例外，不太清楚)。在GBK中，它在GB2312基础上进行了扩充，兼容GB2312中的所有字符，所以不是按拼音排序了。在 Unicode中，汉字的排列似乎更没有什么规律可言了。

　　为了解决内码顺序与用户习惯顺序(如拼音顺序)的冲突，在glibc的 locale数据里，要求提供排序方式(collate)的描述。我看了一下 glibc-2.3.5提供的locale数据，在简体中文(zh_CN)的locale数据描述里，关于排序方式的描述如下：

　　% ISO 14651 collation sequence

　　LC_COLLATE

　　copy "iso14651_t1"

　　END LC_COLLATE

　　也就是说，照抄iso14651_t1的排序方式。打开iso14651_t1文件看了一下，也没有发现关于中文的特殊处理，可以推断glibc默认的排序方式就是按unicode排序。所以不能指望glibc提供中文排序功能，如果SQLite支持了中文排序只能是做了特殊处理。浏览了一下SQLite的代码，这种希望似乎也不大。在网上也没有查到相关的资料和补丁，看来只能靠自己了。

　　不过，在浏览SQLite代码时还是有些收获，至少知道了它比较数据记录的过程：

　　1. sqlite3VdbeExec调用sqlite3BtreeInsert把记录插入到适当的位置。

　　2. sqlite3BtreeInsert调用sqlite3BtreeMoveto找到要插入的位置。

　　3. sqlite3BtreeMoveto调用sqlite3VdbeRecordCompare比较两条记录的大小。

　　4. sqlite3VdbeRecordCompare调用sqlite3MemCompare比较字段的大小。

　　5. sqlite3MemCompare调用binCollFunc去做真正的比较。

　　6. binCollFunc是一个回调函数，由外层设置的。

　　进一步研究，知道了binCollFunc的来源：

　　1. struct CollSeq是一个用来比较的对象，它带有一个比较函数和相关上下文。

　　2. 通过multiSelectCollSeq找到合适的CollSeq对象。

　　3. multiSelectCollSeq调用sqlite3ExprCollSeq查找。

　　4. multiSelectCollSeq调用sqlite3CheckCollSeq查找。

　　5. 查找标准是SELECT或CREATE TABLE所带的COLLATE子句。

　　6. 也就是说可以通过SELECT或CREATE TABLE的参数来决定选择哪个比较函数。

Sqlite是一个用C语言实现的小型SQL数据库引擎。它体积小巧但功能强大，对硬件资源要求很低而且性能表现卓越，非常适合于嵌入式应用环境。最近发现sqlite并不支持中文(拼音/笔画)排序，而这个功能又是我们必需的，所以花了些时间去研究。我对Sqlite的了解只能算是业余级，在研究的过程或许走了些弯路，或许已经有现存的算法可利用，不管怎么样，在研究过程中还是有不少收获，写出来和大家探讨一下。

　　我们知道，计算机中的每一个字符都有一个内码。在默认情况下，计算机排序时，比较两个字符的大小就是比较字符内码的大小，这对于英文来说没有问题，因为英文字母的内码是按字母顺序递增的。对于中文来说，就比较麻烦了：首先，中文的排序方式有多种，比如按内码排序、按拼音排序和按笔画排序，要通过参数指定排序的方式，否则计算机就按内码排序了。其次，汉字的内码顺序即不同于拼音顺序，也不同于按笔画顺序。在GB2312编码中，汉字基本上按拼音排序(据说有例外，不太清楚)。在GBK中，它在GB2312基础上进行了扩充，兼容GB2312中的所有字符，所以不是按拼音排序了。在 Unicode中，汉字的排列似乎更没有什么规律可言了。

　　为了解决内码顺序与用户习惯顺序(如拼音顺序)的冲突，在glibc的 locale数据里，要求提供排序方式(collate)的描述。我看了一下 glibc-2.3.5提供的locale数据，在简体中文(zh_CN)的locale数据描述里，关于排序方式的描述如下：

　　% ISO 14651 collation sequence

　　LC_COLLATE

　　copy "iso14651_t1"

　　END LC_COLLATE

　　也就是说，照抄iso14651_t1的排序方式。打开iso14651_t1文件看了一下，也没有发现关于中文的特殊处理，可以推断glibc默认的排序方式就是按unicode排序。所以不能指望glibc提供中文排序功能，如果SQLite支持了中文排序只能是做了特殊处理。浏览了一下SQLite的代码，这种希望似乎也不大。在网上也没有查到相关的资料和补丁，看来只能靠自己了。

　　不过，在浏览SQLite代码时还是有些收获，至少知道了它比较数据记录的过程：

　　1. sqlite3VdbeExec调用sqlite3BtreeInsert把记录插入到适当的位置。

　　2. sqlite3BtreeInsert调用sqlite3BtreeMoveto找到要插入的位置。

　　3. sqlite3BtreeMoveto调用sqlite3VdbeRecordCompare比较两条记录的大小。

　　4. sqlite3VdbeRecordCompare调用sqlite3MemCompare比较字段的大小。

　　5. sqlite3MemCompare调用binCollFunc去做真正的比较。

　　6. binCollFunc是一个回调函数，由外层设置的。

　　进一步研究，知道了binCollFunc的来源：

　　1. struct CollSeq是一个用来比较的对象，它带有一个比较函数和相关上下文。

　　2. 通过multiSelectCollSeq找到合适的CollSeq对象。

　　3. multiSelectCollSeq调用sqlite3ExprCollSeq查找。

　　4. multiSelectCollSeq调用sqlite3CheckCollSeq查找。

　　5. 查找标准是SELECT或CREATE TABLE所带的COLLATE子句。

　　6. 也就是说可以通过SELECT或CREATE TABLE的参数来决定选择哪个比较函数。