基于SQLite数据库的丢失数据的恢复装置和方法
技术领域
本发明属于数据恢复技术领域,具体涉及一种基于SQLite数据库的丢失数据的恢复装置和方法。
背景技术
SQLite是一款轻型的数据库,它的设计目标是嵌入式的,而且目前已经在很多嵌入式产品中使用了它,它占用资源非常的低,在嵌入式设备中,可能只需要几百KB的内存就够了。它能够支持Windows/Linux/Unix/MacOSX等等主流的操作系统,同时能够跟很多程序语言相结合。SQLite以资源占用少、操作简洁、零管理成本、性能良好、代码开源等一系列特性广泛的应用于嵌入式设备、桌面应用以及Websites等领域。
然而,一旦基于SQLite数据库的系统发生了数据丢失的情况,往往会给用户带来诸多不便,现有的进行SQLite数据库恢复的方法一般都是针对某个应用程序,比如微信,QQ等,并不能解决整个数据库的数据丢失问题,即便有针对整个数据库进行数据恢复的方法也存在数据恢复不全,恢复的数据不够准确以及运行效率低下等情况。
比如,申请日为2012年10月30日,申请号为201210430026.0,发明名称为一种恢复移动终端已删除SQLite文件的方法和装置针对SQLite数据丢失提出了一种解决方案,本发明提供的方法预先设置若干种SQLite页特征规则,当检测到移动终端时,执行步骤:获取当前移动终端的镜像文件;解析当前移动终端的镜像文件并设置搜索区域;根据搜索区域内的数据特征调用至少一种预先设置的SQLite页特征规则,以SQLite页特征规则作为匹配依据对搜索区域内的数据进行匹配,获得当前移动终端上已删除的SQLite文件页碎片;最后对当前移动终端上已删除的SQLite文件页碎片内的数据进行解码。本发明提供的方案可获取移动终端上所有已删除SQLite文件未被覆盖的页碎片内有效数据,恢复成功率及恢复完整性高。
上述解决方案存在以下缺陷:以页作为特征规则,使得数据恢复的规则筛选范围过大,恢复数据的精细化程度不高,导致数据恢复仍然不够全面,完整性也有待提高,且运行效率低下。
另外,上述解决方案仅仅是针对移动终端,而现实情况中在PC端和其它应用平台也大量使用SQLite数据库,因此现有的解决方案并不能满足现实情况的需求。
发明内容
本发明针对现有技术的不足,提供了一种基于SQLite数据库的丢失数据的恢复装置和方法,能够有效解决现有技术数据恢复不够全面,运行效率低下等问题。
为解决以上问题,本发明采用的技术方案如下:一种基于SQLite数据库的丢失数据的恢复装置,包括以下模块:
特征配置模块:用于配置包含待恢复数据的源数据库中部分或全部表的列的属性特征;
特征匹配模块:用于将列的属性特征与待恢复数据进行匹配验证。
作为优选,特征配置模块包含以下单元:
数据库加载单元:用于读取待恢复数据的源数据库的信息;
特征定义单元:用于设置源数据库中部分或全部表的列的属性特征,包括列值类型、列值长度和列数量;
保存单元:用于保存列的属性特征至预置的特定文件类型中。
作为优选,特征匹配模块包含以下单元:
数据库加载单元:用于读取源数据库的信息;
特征匹配单元:用于将列的属性特征与待恢复数据进行匹配验证;
保存单元:用于将匹配成功的信息进行保存。
作为优选,特征匹配模块还包含以下单元:
显示单元:用于将读取的源数据库的信息以表格形式展示,并将匹配成功的信息解码展示到显示单元;
设置单元:用于设置显示单元所需显示的表和列。
为了实现本发明目的,本发明还提供了一种基于SQLite数据库的丢失数据的恢复方法,其包括以下步骤:
S1配置包含待恢复数据的源数据库中部分或全部表的列的属性特征;
S2将特列的属性特征与待恢复数据进行匹配验证。
作为优选,S1的详细流程如下所述:
S11读取包含待恢复数据的源数据库;
S12根据S11中获取的源数据库,设置包含待恢复数据的表的列的属性,包括列值类型、列值长度和列数量;
S13保存S12设置的列的属性至预置的特定文件类型中。
作为优选,S2的详细流程如下所述:
S21从0字节开始遍历读取待恢复的镜像文件;
S22读取S1中配置的源数据库的列的属性特征;
S23将列的属性特征与待恢复数据进行匹配验证;
S24根据SQLite数据库存储规则进行信息解码,并按照源数据库格式恢复数据库的丢失数据。
作为优选,S23的详细流程如下所述:
以S23的列的属性特征作为匹配规则,对读取的镜像文件扫描匹配管理字节,扫描时从镜像文件0字节开始依次读取长度为最小扫描单元的内容进行匹配,匹配成功则跳至S24,否则跳转至下一个字节即1字节,继续执行本步骤,其中最小扫描单元=3+列的数量。
作为优选,S23判断结构是否匹配的方法为:在扫描过程中成功匹配数据时,则向前读取3个字节的数据内容,并检验其是否满足存储数据的结构特征。
作为优选,所述的检验其是否满足存储数据的结构特征规则如下:
规则1:数据符合正常的payload结构,则直接按照结构读取;
规则2:数据不符合正常payload结构时,又分为多字节匹配和单字节匹配,当字节的第八位为1时,表明该管理项为多字节,多字节的处理方式为读取的数据中当字节第八位为1时,继续向下读取,直至字节的第八位为0结束,将读取的字节作为一个管理项,去掉每字节的第八位构成新的值作为该管理项对应数据的长度值;当字节的第八位为0时,表示该字节为单字节,其值即为该管理项的长度;根据匹配成功的字节中记录的关于列长度的值,向后匹配数据内容,在匹配的过程中将数据库定义时的数据类型划分为int、double、text、blob,按照这四种类型进行逐一匹配。
本发明的有益效果如下:由于本发明采用了列的属性特征作为匹配规则,筛选单位小于页结构,因此可以保证恢复的数据具有较高的完整性,并且提升了数据恢复的效率;由于本发明采用了匹配验证的手段,因此可以保证恢复的数据具有较高的准确性;本发明还能根据不同应用条件下自定义源数据库的特征来恢复所有使用到SQLite数据库的应用数据,而不仅仅限于移动终端,因此应用平台十分广泛,具有良好的应用前景。
附图说明
图1数据库中数据存储的结构(payload)示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明做进一步详细说明。
本发明提出一种基于SQLite数据库的丢失数据的恢复的装置和方法,结合SQLite3版本的数据存储结构,简要介绍SQLite数据库在存储数据时的特点。SQLite数据库的页结构中使用BTree树,而数据库中列值存储在BTree的单元内容区中,单元内容区中数据以图1所示的格式进行存储。匹配过程中,通过读取源数据库的特征信息,待恢复数据按照特征信息进行逐一匹配,匹配成功后再结合图1所示的数据存储结构进一步验证数据的完整性和有效性。
实施例1:
一种基于SQLite数据库的丢失数据的恢复装置,包括以下模块:
特征配置模块:用于配置包含待恢复数据的源数据库中部分或全部表的列的属性特征;
特征匹配模块:用于将列的属性特征与待恢复数据进行匹配验证。
进一步地,特征配置模块包含以下单元:
数据库加载单元:用于读取含待恢复数据的数据库的信息;
特征定义单元:用于设置源数据库中部分或全部表的列的属性特征,包括列值类型、列值长度和列数量;
保存单元:用于保存列的属性特征至预置的特定文件类型中。
进一步地,特征匹配模块包含以下单元:
数据库加载单元:用于读取源数据库的信息;
特征匹配单元:用于将列的属性特征与待恢复数据进行匹配验证;
保存单元:用于将匹配成功的信息进行保存;
显示单元:用于将读取的源数据库的信息以表格形式展示,并将匹配成功的信息解码展示到显示单元;
设置单元:用于设置显示单元所需显示的表和列。
实施例2:
一种基于SQLite数据库的丢失数据的恢复方法,包括如下步骤:
S1配置包含待恢复数据的源数据库中部分或全部表的列的属性特征;
S2将特列的属性特征与待恢复数据进行匹配验证。
进一步地,S1的详细流程如下所述:
S11读取包含待恢复数据的源数据库;
S12根据S11中获取的源数据库,设置包含待恢复数据的表的列的属性,包括列值类型、列值长度和列数量;
其中,在定义多张表结构时,如果表的结构完全一致,可以同*作为通配符来建立表集合以表示同一类型的表可使用一个特征信息,例如在iPhone设备中存储微信聊天消息的数据库中,与每一个好友的聊天信息均会产生一张名为“chat_x”(x代表0~9、a~z、A~Z中任意一字符)的表,此处定义表结构时不必根据每个表格来定义结构,可使用“chat_.*”来表示所有与好友聊天的表结构;在列值类型定义时设定了INT、DOUBLE、TEXT、BLOB四种类型;在列值长度定义时用十进制数来描述,并设定了最小长度值可为0,最大长度值为无穷(-1表示无穷);
S13保存S12设置的列的属性至预置的特定文件类型中,其格式如“源文件名(含后缀).charactor”。
进一步地,S2的详细流程如下所述:
S21从0字节开始遍历读取待恢复的镜像文件;
S22读取S1中配置的源数据库的列的属性特征;
S23将列的属性特征与待恢复数据进行匹配验证;
S24根据SQLite数据库存储规则进行信息解码,并按照源数据库格式恢复数据库的丢失数据。
进一步地,S23的详细流程如下所述:
以S23的列的属性特征作为匹配规则,对读取的镜像文件扫描匹配管理字节,扫描时从镜像文件0字节开始依次读取长度为最小扫描单元的内容进行匹配,匹配成功则跳至S24,否则跳转至下一个字节即1字节,继续执行本步骤,其中最小扫描单元=3+列的数量。
S23判断结构是否匹配的方法为:在扫描过程中成功匹配数据时,则向前读取3个字节的数据内容,并检验其是否满足存储数据的结构特征。
由于在不同的删除情况下,会造成对管理项字节不同程度的破坏(全部覆盖、部分覆盖、未覆盖),结构特征匹配的规则包含以下两条:
规则1:数据符合正常的payload结构,则直接按照结构读取;
其核心代码如下:
规则2:数据不符合正常payload结构时,又分为多字节匹配和单字节匹配。当字节的第八位为1时,表明该管理项为多字节,多字节的处理方式为读取的数据中当字节第八位为1时,继续向下读取,直至字节的第八位为0结束,将读取的字节作为一个管理项,去掉每字节的第八位构成新的值作为该项对应数据的长度值,其核心代码如下:
当字节的第八位为0时,表示该管理项为单字节,其值即为该项的长度,其核心代码如下:
根据S23中命中的管理项字节中记录的关于列长度的值,向后匹配数据内容,在匹配的过程中将数据库定义时的数据类型划分为int、double、text、blob四种,按照这四种类型进行逐一匹配,其中匹配int类型的数据的核心代码如下:
匹配double类型的数据的核心代码如下:
匹配text类型的数据的核心代码如下:
匹配blob类型的数据的核心代码如下:
此外,对于在上述四种类型中未包含的其他类型处理的核心代码如下:
本领域的普通技术人员将会意识到,这里所述的实施例是为了帮助读者理解本发明的实施方法,应被理解为本发明的保护范围并不局限于这样的特别陈述和实施例。本领域的普通技术人员可以根据本发明公开的这些技术启示做出各种不脱离本发明实质的其它各种具体变形和组合,这些变形和组合仍然在本发明的保护范围内。