今天终于完成了规则库的增删改的功能，但是还有一些小的问题没有处理。
规则库保存文件的结构：
文件的头部32位用来保存规则库中规则的数量。这个主要是为了比较容易的统计出现有的规则数量。
32位以后就是数据区，用来保存规则的信息。如果规则的属性为字符串，那么在这个属性之前有32位来保存该字符串的长度。如果字符串长度为零，32位长度区域保存0，也就是说即使字符串长度为零，也会占据用来保存数据长度信息的2个字节的空间。这样设计是为了能够尽量的节省空间，使得数据长度可变化。
规则的第一个属性是规则编号，这个编号准备让系统自动维护，就是让他自动增长。但是现在的问题是如果删除了中间的某条规则，那么那个编号就会空出来，浪费了编号资源。所以为了保证不会把编号用完，我用了64位来保存。而且为了提高性能，决定将最大的编号也保存在头部。
我现在每一次系统运行就把规则库全部读入内存，然后对规则库进行管理，为了保证性能，等系统退出之前一次性的把内存中的规则再写回文件。个人觉得这样也不是很好，因为规则库数量比较大的时候，如果规则的改动并不是很大，这样全盘写回去会很浪费。这个要找一个更好的解决方案。
下一步要实现Tab页功能。
规则库保存文件的结构：
文件的头部32位用来保存规则库中规则的数量。这个主要是为了比较容易的统计出现有的规则数量。
32位以后就是数据区，用来保存规则的信息。如果规则的属性为字符串，那么在这个属性之前有32位来保存该字符串的长度。如果字符串长度为零，32位长度区域保存0，也就是说即使字符串长度为零，也会占据用来保存数据长度信息的2个字节的空间。这样设计是为了能够尽量的节省空间，使得数据长度可变化。
规则的第一个属性是规则编号，这个编号准备让系统自动维护，就是让他自动增长。但是现在的问题是如果删除了中间的某条规则，那么那个编号就会空出来，浪费了编号资源。所以为了保证不会把编号用完，我用了64位来保存。而且为了提高性能，决定将最大的编号也保存在头部。
我现在每一次系统运行就把规则库全部读入内存，然后对规则库进行管理，为了保证性能，等系统退出之前一次性的把内存中的规则再写回文件。个人觉得这样也不是很好，因为规则库数量比较大的时候，如果规则的改动并不是很大，这样全盘写回去会很浪费。这个要找一个更好的解决方案。
下一步要实现Tab页功能。
