文件处理、文件查找方法、装置、计算机设备及存储介质

技术领域

本公开涉及计算机的技术领域，具体而言，涉及一种文件处理、文件查找方法、装置、计算机设备及存储介质。

背景技术

在现有文件打包技术中，通常选择压缩软件对文件打包到一个压缩包中。当用户需要使用该压缩包中的文件时，需要对该压缩包进行解压，才可以获取该压缩包中的数据。因此，现有文件打包技术的文件读取速度较慢。且在利用该压缩包中的数据进行数据更新时，该压缩包不能删除，这将占用较多的内存空间，从而影响设备的稳定运行。

发明内容

本公开实施例至少提供一种文件处理、文件查找方法、装置、计算机设备及存储介质。

第一方面，本公开实施例提供了一种文件处理方法，包括：

获取待处理目录，其中，所述待处理目录下包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件；

基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，其中，所述打包信息用于指示该层级的文件夹中所包含的每个子文件的文件属性信息和文件位置信息，所述文件位置信息用于指示该子文件在待生成的目标打包文件中的位置；

基于所述每个层级的文件夹的打包信息生成所述目标打包文件。

一种可选的实施方式中，所述基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，包括：

基于所述层级顺序确定所述每个层级的文件夹的第一打包子信息；

确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息；

基于所述第一打包子信息和所述第二打包子信息确定该文件夹的打包信息。

一种可选的实施方式中，所述确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息，包括：

确定所述每个层级的文件夹中每个子文件的文件类型，并确定与所述文件类型相匹配的文件打包模式；

基于所述文件打包模式确定该子文件的第二打包子信息。

一种可选的实施方式中，所述第一打包子信息中包含以下至少之一：文件夹的类型标识、文件夹名称、文件夹中所包含子文件数量、文件夹中各子文件的文件名称哈希值、文件夹中各子文件的文件位置信息。

一种可选的实施方式中，在所述子文件的文件类型为文件夹的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件名称、子文件中所包含子文件数量、子文件中各子文件的文件名称哈希值、子文件中各子文件的文件位置信息；在所述子文件的文件类型为文档文件的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件的名称、子文件长度、子文件内容、子文件的文件位置信息。

一种可选的实施方式中，所述确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息，包括：

确定每个所述子文件的文件名称哈希值；

基于所述文件名称哈希值对该文件夹中的各子文件进行排序，得到子文件排序结果；

基于所述子文件排序结果确定该文件夹中所包含每个子文件的第二打包子信息。

第二方面，本公开实施例还提供一种文件查找方法，包括：

获取文件查找请求，并获取与所述文件查找请求相对应的目标查找文件，其中，所述文件查找请求中携带文件查找路径，所述目标查找文件为基于第一方面中任一项所述的文件处理方法得到的目标打包文件；

按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息；

基于查找到的所述文件位置信息在所述目标查找文件中确定所述文件查找请求所指示查找的目标文件。

一种可选的实施方式中，所述按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息，包括：

按照所述路径层级顺序，将所述文件查找路径进行切分，得到至少一个子路径；

在所述目标查找文件中依次查找每个子路径所对应的哈希值；

在所述目标查找文件中查找到所述所对应的哈希值的情况下，在所述目标查找文件中查找该子路径所对应的文件位置信息，并将查找到的文件位置信息确定为该子路径所包含子文件在所述目标查找文件中文件位置信息。

第三方面，本公开实施例还提供一种文件处理装置，包括：

第一获取单元，用于获取待处理目录，其中，所述待处理目录下包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件；

遍历单元，用于基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，其中，所述打包信息用于指示该层级的文件夹中所包含的每个子文件的文件属性信息和文件位置信息，所述文件位置信息用于指示该子文件在待生成的目标打包文件中的位置；

生成单元，用于基于所述每个层级的文件夹的打包信息生成所述目标打包文件。

第四方面，本公开实施例还提供一种文件查找装置，包括：

第二获取单元，用于获取文件查找请求，并获取与所述文件查找请求相对应的目标查找文件，其中，所述文件查找请求中携带文件查找路径，所述目标查找文件为基于上述第一方面中的文件处理方法得到的目标打包文件；

第一确定单元，用于按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息；

第二确定单元，用于基于查找到的所述文件位置信息在所述目标查找文件中确定所述文件查找请求所指示查找的目标文件。

第五方面，本公开实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面至第二方面中任一种可能的实施方式中的步骤。

第六方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面至第二方面中任一种可能的实施方式中的步骤。

本公开实施例提供的文件处理、文件查找方法、装置、计算机设备及存储介质。在本公开实施例中，首先可以获取待处理目录，并基于待处理目录中文件夹的层级顺序对每个层级的文件夹以及子文件进行遍历，得到每个层级的文件夹的打包信息，并基于该打包信息生成目标打包文件，以使用户基于包含路径层级顺序的文件查找请求，在该目标打包文件直接查找目标文件，从而在一方面提高文件打包的速度，另一方面在查找目标文件时省略了解压的过程，减少了内存空间的占用，使得设备能够更加稳定的运行。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的一种文件处理方法的流程图；

图2示出了本公开实施例所提供的一种文件查找方法的流程图；

图3示出了本公开实施例所提供的一种文件处理装置的示意图；

图4示出了本公开实施例所提供的一种文件查找装置的示意图；

图5示出了本公开实施例所提供的一种计算机设备的示意图；

图6示出了本公开实施例所提供的另一种计算机设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

本文中术语“和/或”，仅仅是描述一种关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

经研究发现，在现有文件打包技术中，通常选择压缩软件对文件打包到一个压缩包中。当用户需要使用该压缩包中的文件时，需要对该压缩包进行解压，才可以获取该压缩包中的数据。因此，现有文件打包技术的文件读取速度较慢。且在利用该压缩包中的数据进行数据更新时，该压缩包不能删除，这将占用较多的内存空间，从而影响设备的稳定运行。

基于上述研究，本公开提供了一种文件处理、文件查找方法、装置、计算机设备及存储介质。在本公开实施例中，首先可以获取待处理目录，并基于待处理目录中文件夹的层级顺序对每个层级的文件夹以及子文件进行遍历，得到每个层级的文件夹的打包信息，并基于该打包信息生成目标打包文件，以使在查找目标文件的过程中，可以基于打包信息查找该目标文件在目标打包文件中的文件位置信息，从而在一方面能通过文件打包将多个层级的文件夹进行合并，提高文件读取的速度，另一方面在查找目标文件时省略了解压的过程，减少了内存空间的占用，使得设备能够更加稳定的运行。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种文件处理、文件查找方法进行详细介绍，本公开实施例所提供的文件处理、文件查找方法的执行主体一般为具有一定计算能力的计算机设备。在一些可能的实现方式中，该文件处理、文件查找方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

参见图1所示，为本公开实施例提供的一种文件处理方法的流程图，所述方法包括步骤S101～S105，其中：

S101：获取待处理目录，其中，所述待处理目录下包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件。

在本公开实施例中，在针对终端设备中所包含的应用程序进行更新的过程中，会产生大量的更新文件，尤其是在采用增量更新的过程中，可能会产生大量的小体积更新资源包(容量为几KB至几十KB)，由于内存读取机制的影响，系统在读取这些小体积更新资源包时的读取速度往往慢于大体积更新资源包(这里的大体积只容量为GB级别的资源包)。因此，在本公开实施例中需要将应用程序所对应的多个更新资源的文件进行打包，从而提升文件的读取速度。这里，增量更新区别于全量更新，在进行增量更新时，只更新需要改变的地方，不需要更新或者已经更新过的地方则不会重复更新，例如，只针对应用程序中的bug进行修复，并将修复后的部分更新内容下发至应用程序中。

具体实施时，可以首先获取待处理目录，例如，该待处理目录可以为上述应用程序的更新资源目录，该更新资源目录中可以包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件，其中，至少一个层级的文件夹可以对应该应用程序中的各个功能的更新资源，该文件夹中可以包含该应用程序中的各个功能所对应的增量更新子文件。

举例来说，上述待处理目录为应用程序A的更新资源目录，该更新资源目录对应着应用程序A的全部更新资源a，其中包含功能A1所对应的文件夹a1，该文件夹中包含功能a1的增量更新子文件a1.txt。那么，该待处理目录可以表示为a/a1/a1.txt。这里，“/”为层级标识，用于区分待处理目录下不同层级的文件。

S103：基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，其中，所述打包信息用于指示该层级的文件夹中所包含的每个子文件的文件属性信息和文件位置信息，所述文件位置信息用于指示该子文件在待生成的目标打包文件中的位置。

在本公开实施例中，首先可以基于上述待处理目录中文件夹的层级顺序，对每个层级的文件夹以及该文件夹中包含的子文件进行遍历，这里，在进行遍历的过程中可以获取每个层级的文件夹以及该文件夹中所包含的子文件的文件属性信息以及文件位置信息，从而基于该文件属性信息以及文件位置信息得到每个层级的文件夹的打包信息。

这里，文件属性信息可以为用于指示该文件夹或者子文件的类型、文件名称、文件内容等属性。文件位置信息可以用于指示该文件夹或者子文件在待处理文件中的层级位置，例如，该文件位置信息可以用于指示包含某个子文件的上一级文件夹，以及该子文件所包含的下一级子文件。应理解的是，该文件夹或者子文件在待处理文件中的层级位置可以为该文件夹或者子文件在待生成的目标打包文件中的位置。

举例来说，以待处理目录中文件夹a为例，该文件夹a中包含子文件b1以及子文件b2，子文件b1中包含子文件c，子文件c中包含子文件1.txt，另外，子文件b2中包含子文件2.txt，那么，该文件夹a的层级顺序就可以为a/{b1/c/1.txt}、{b2/2.txt}。因此，在针对该文件夹a以及其中所包含的子文件进行遍历时，就可以基于该文件夹a的层级顺序进行遍历。

具体的，在基于层级顺序a/{b1/c/1.txt}进行遍历的过程中，首先可以遍历文件夹a，再分别遍历子文件b1，子文件c，以及子文件1.txt。然后，就可以基于层级顺序{b2/2.txt}分别对子文件b2，子文件2.txt进行遍历，从而完成针对该文件夹a以及文件夹a中包含的子文件的遍历。

S105：基于所述每个层级的文件夹的打包信息生成所述目标打包文件。

在本公开实施例中，在确定出每个层级的文件夹的打包信息之后，就可以基于确定出的打包信息，将各个层级的文件夹按照该打包信息进行打包，从而生成目标打包文件。

这里，该打包过程可以为合并以及压缩的过程，即将不同层级的文件夹进行合并，得到合并结果，并对合并结果进行压缩，从而得到目标打包文件，其中，该目标打包文件可以为压缩文件，相较于未压缩的文件夹，压缩文件形式的目标打包文件大大减少了内存空间的占用。

通过上述描述可知，在本公开实施例中，首先可以获取待处理目录，并基于待处理目录中文件夹的层级顺序对每个层级的文件夹以及子文件进行遍历，得到每个层级的文件夹的打包信息，并基于该打包信息生成目标打包文件，从而通过文件打包将多个层级的文件夹进行了合并，提高文件读取的速度。

在一个可选的实施方式中，上述步骤S103，基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，具体包括如下过程：

S1031：基于所述层级顺序确定所述每个层级的文件夹的第一打包子信息；

S1032：确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息；

S1033：基于所述第一打包子信息和所述第二打包子信息确定该文件夹的打包信息。

在本公开实施例中，由于每个层级的文件夹和该文件夹中所包含的子文件的文件属性信息以及文件位置信息是不同的，因此，需要分别针对每个层级的文件夹以及该文件夹中所包含的子文件的打包信息进行获取，从而得到每个层级的文件夹的第一打包子信息以及每个层级的文件夹中所包含每个子文件的第二打包子信息。

举例来说，上述应用程序中包含功能A，该功能A中又包含子功能B1以及B2，功能A对应的更新资源文件夹为a，子功能B1对应的更新资源文件夹为b1，子功能B2对应的更新资源文件夹为b2。

那么，文件夹a中包含子文件b1以及子文件b2，在确定文件夹a所对应层级的文件夹的打包信息的过程中，首先可以确定文件夹a所对应的第一打包子信息，再分别确定该文件夹a所包含的子文件b1以及子文件b2所对应的第二打包子信息。

在本公开实施例中，在确定每个层级的文件夹的打包信息的过程中，可以首先确定每个层级的文件夹的第一打包子信息，并确定每个层级的文件夹中所包含的子文件的第二打包子信息，从而基于该第一打包子信息以及第二打包子信息确定该文件夹的打包信息，为基于每个文件夹的打包信息生成目标打包文件提供了技术基础。

在一个可选的实施方式中，上述步骤S1032，确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息，具体包括如下过程：

(1)、确定所述每个层级的文件夹中每个子文件的文件类型，并确定与所述文件类型相匹配的文件打包模式；

(2)、基于所述文件打包模式确定该子文件的第二打包子信息。

在本公开实施例中，由于不同文件类型所对应的文件打包模式不同，因此需要确定每个层级的文件夹中每个子文件的文件类型，其中，根据每个子文件中所包含的不同内容，该文件类型可以分为文件夹以及文档文件。

这里，文件类型为文件夹的子文件中还可以包含低一层级的子文件，例如，子文件b中还可以包含子文件c。文件类型为文档文件的子文件中可以包含各种格式的文档文件，例如，.txt格式的文档文件。

在确定出文件夹的各个子文件所对应的文件类型后，就可以基于不同文件类型所对应的文件打包模式，确定该文件类型的子文件的第二打包子信息，其中，该第二打包子信息用于基于该文件打包模式对该子文件进行打包，从而生成目标打包文件。

在本公开实施例中，由于每个层级的文件夹中包含的子文件的文件类型可以是不同的，因此可以为不同类型的子文件设置不同的文件打包模式，并基于该文件打包模式获取该子文件的第二打包子信息，从而能够适用于不同文件类型的子文件进行打包，提高了生成的目标打包文件的准确性。

在一个可选的实施方式中，上述第一打包子信息中包含以下至少之一：文件夹的类型标识、文件夹名称、文件夹中所包含子文件数量、文件夹中各子文件的文件名称哈希值、文件夹中各子文件的文件位置信息。

在本公开实施例中，上述文件夹的类型标识可以为该文件夹的文件类型的标识，例如，该文件夹的类型标识可以为0×2；上述文件夹名称可以为该文件夹的文件名；上述文件夹中各子文件的文件名称哈希值可以为通过哈希函数对该文件夹的文件名称进行计算后得到的值，也可记为Hash值；上述文件夹中各子文件的文件位置信息可以通过该子文件在该文件夹中的偏移量进行表示，其中，该偏移量可以用于表征该子文件在存储单元中的实际存储地址以及包含该子文件的文件夹在存储单元中的实际存储地址的差值，例如，文件夹在存储单元中的实际存储位置为第100个字节位置，该文件夹中的子文件的偏移量为50，那么，该子文件在存储单元中的实际存储位置就可以为第150个字节位置。

举例来说，上述文件夹为a，该文件夹中包含子文件b1以及子文件b2，那么，该文件夹a的文件夹的类型标识可以为0×2；文件夹名称可以为a；文件夹中所包含子文件数量可以为2；文件夹中各子文件的文件名称哈希值分别为：子文件b1的文件名称哈希值Hash(b1)以及子文件b2的文件名称哈希值Hash(b2)；文件夹中各子文件的文件位置信息分别为：子文件b1在文件夹a中的偏移量(b1)，以及子文件b2在文件夹a中的偏移量(b2)。

因此，上述文件夹a的第一打包子信息可以记为：0×2丨a丨2丨Hash(b1)Hash(b2)丨偏移量(b1)偏移量(b2)。

在本公开实施例中，上述第一打包子信息中包含以下至少之一：文件夹的类型标识、文件夹名称、文件夹中所包含子文件数量、文件夹中各子文件的文件名称哈希值、文件夹中各子文件的文件位置信息，从而为基于该第一打包信息对文件夹进行打包提供了技术基础。

在一个可选的实施方式中，在所述子文件的文件类型为文件夹的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件名称、子文件中所包含子文件数量、子文件中各子文件的文件名称哈希值、子文件中各子文件的文件位置信息；在所述子文件的文件类型为文档文件的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件的名称、子文件长度、子文件内容、子文件的文件位置信息。

在本公开实施例中，在上述子文件的文件类型为文件夹的情况下，上述第二子信息中包含以下至少之一：子文件的类型标识、子文件名称、子文件中所包含子文件数量、子文件中各子文件的文件名称哈希值、子文件中各子文件的文件位置信息，其中，该子文件的类型标识可以为0×2。

这里，文件类型为文件夹的子文件中还可以包含低一层级的子文件，因此，上述文件夹a的子文件b1，子文件b2以及子文件c的文件类型均为文件夹。那么，以子文件b1为例，该子文件b1的类型标识为0×2，子文件名称为b1，文件中所包含的子文件数量为1，子文件中各子文件的文件名称哈希值为子文件c的文件名称哈希值Hash(c)，子文件中各子文件的文件位置信息为子文件c相对于该子文件b1的偏移量(c)。因此，该子文件b1的第二打包子信息可以记为：0×2丨b1丨1丨Hash(c)丨偏移量(c)。

那么，同理可得，子文件b2的第二打包子信息可以记为：0×2丨b2丨1丨Hash(2.txt)丨偏移量(2.txt)；子文件c的第二打包子信息可以记为：0×2丨c丨1丨Hash(1.txt)丨偏移量(1.txt)。

在本公开实施例中，可以确定文件夹的第一打包子信息，从而为基于该第一打包子信息对该文件夹进行打包提供了技术基础。

在一个可选的实施方式中，在上述子文件的文件类型为文档文件的情况下，第二打包子信息中包含以下至少之一：子文件的类型标识、子文件的名称、子文件长度、子文件内容、子文件的文件位置信息，其中，该子文件的类型标识可以为0×1。

这里，文件类型为文档文件的子文件中可以包含各种格式的文档文件，因此，上述子文件c中的子文件1.txt，以及子文件b2中的子文件2.txt的文件类型为文档文件。那么，以子文件1.txt为例，该子文件1.txt的类型标识为0×1，子文件名称为1.txt，子文件长度为d(1.txt)，子文件内容为内容(1.txt)，子文件的文件位置信息为子文件1.txt相对于该子文件c的偏移量(1.txt)。因此，该子文件1.txt的第二打包子信息可以记为：0×1丨1.txt丨d(1.txt)丨内容(1.txt)丨偏移量(1.txt)。

那么，同理可得，子文件2.txt的第二打包子信息可以记为：0×1丨2.txt丨d(2.txt)丨内容(2.txt)丨偏移量(2.txt)。

在本公开实施例中，可以分别确定文件类型为文件夹以及文档文件的子文件的第二打包子信息，从而为基于该第二打包子信息对该子文件进行打包提供了技术基础。

在一个可选的实施方式中，上述步骤S1032，确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息，具体还包括如下过程：

(1)、确定每个所述子文件的文件名称哈希值；

(2)、基于所述文件名称哈希值对该文件夹中的各子文件进行排序，得到子文件排序结果；

(3)、基于所述子文件排序结果确定该文件夹中所包含每个子文件的第二打包子信息。

在本公开实施例中，首先可以通过哈希函数对各个子文件的文件名进行计算，从而得到每个子文件的文件名称哈希值，然后，就可以基于该文件名称哈希值对该文件夹中的各子文件进行排序，得到子文件排序结果。然后，就可以基于该子文件排序结果确定每个子文件的文件位置信息，并基于该文件位置信息确定每个子文件的第二打包子信息。

在本公开实施例中，在基于该文件名称哈希值对该文件夹中的各子文件进行排序，得到子文件排序结果后，基于该子文件排序结果生成的目标打包文件中的各子文件同样时按照该子文件排序结果进行排序的，而不会因为打包造成乱序，从而在该目标打包文件中查找目标文件时可以基于该子文件排序结果进行查找，而不用对该目标打包文件进行解压，提高了查找效率的同时节省了存储空间。

参见图2所示，为本公开实施例提供的一种文件查找方法的流程图，所述方法包括步骤S201～S205，其中：

S201：获取文件查找请求，并获取与所述文件查找请求相对应的目标查找文件，其中，所述文件查找请求中携带文件查找路径，所述目标查找文件为基于上述文件处理方法的得到的目标打包文件。

在本公开实施例中，可以通过文件查找请求获取目标查找文件中的目标文件，这里，可以基于该目标文件的文件查找路径生成该目标文件的文件查找请求，这里，该文件查找路径可以用于指示该目标文件在目标查找文件中的层级顺序。

这里，以上述1.txt作为目标文件为例，该目标文件的所对应的文件查询路径可以为：a/b1/c/1.txt。

S203：按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息。

在本公开实施例中，首先可以基于上述文件查询路径中各子路径的路径层级顺序，确定每个子路径所包含子文件的打包信息，并基于该打包信息确定对应的子文件在目标查找文件中的文件位置信息，从而确定出目标文件的文件位置信息。

举例来说，以上述目标文件1.txt所对应的文件查询路径a/b1/c/1.txt为例，首先可以确定文件夹a的打包信息，并基于该文件夹a的打包信息确定出子文件b1的文件位置信息，然后，就可以基于该子文件b1的打包信息，确定出子文件c的位置信息，最后基于该子文件c的打包信息确定出1.txt的位置信息。

S205：基于查找到的所述文件位置信息在所述目标查找文件中确定所述文件查找请求所指示查找的目标文件。

在本公开实施例中，在确定出目标文件的文件位置信息之后，就可以基于该文件位置信息在目标查找文件中查找该目标文件。具体的，该文件位置信息可以为该目标文件的打包信息中所包含的偏移量(1.txt)，可以基于该偏移量(1.txt)确定该目标文件在存储单元中的实际存储地址。

通过上述描述可知，在本公开实施例中，可以基于目标文件的打包信息，查找该目标文件在目标查找文件中的文件位置信息，省略了针对目标查找文件进行解压的过程，减少了内存空间的占用，使得设备能够更加稳定的运行。

在一个可选的实施方式中，上述步骤S203，按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息，具体包括如下过程：

S2031：按照所述路径层级顺序，将所述文件查找路径进行切分，得到至少一个子路径。

在本公开实施例中，在按照路径层级顺序对文件查找路径进行切分的过程中，可以基于该文件查找路径中所包含的层级标识对该文件查找路径进行切分，得到至少一个子路径这里，层级标识可以为上述“/”。

具体实施时，以上述文件查询路径a/b1/c/1.txt为例，在基于层级标识“/”对该文件查询路径进行切分后，可以分别得到文件夹a的子路径，子文件b1的子路径，子文件c的子路径以及子文件1.txt的子路径。

S2032：在所述目标查找文件中依次查找每个子路径所对应的哈希值。

S2033：在所述目标查找文件中查找到所述所对应的哈希值的情况下，在所述目标查找文件中查找该子路径所对应的文件位置信息，并将查找到的文件位置信息确定为该子路径所包含子文件在所述目标查找文件中文件位置信息。

在本公开实施例中，可以按照上述路径层级顺序，依次查找每个子路径所对应的下一级子路径的哈希值，并在查找到该下一级子路径的哈希值的情况下，确定该下一级子路径所对应的子文件的文件位置信息。

具体实施时，以上述文件查询路径a/b1/c/1.txt为例，首先获取文件夹a的打包信息，并在该打包信息中查找子文件b1所对应的哈希值Hash(b1)，在查找到该哈希值Hash(b1)的情况下，就可以确定该子文件b1所对应的文件位置信息，即偏移量(b1)。

接下来，就可以获取该子文件b1的打包信息，并在该打包信息中查找子文件c所对应的哈希值Hash(c)，在查找到该哈希值Hash(c)的情况下，就可以确定该子文件c所对应的文件位置信息，即偏移量(c)。同理，然后就可以基于该子文件c的打包信息确定目标文件1.txt的文件位置信息，即偏移量(1.txt)。

需要说明的是，在依次查找每个子路径所对应的哈希值的过程中，可以采用二分查找的方式。例如，上述文件夹a对应两个子文件，即子文件b1以及子文件b2，子文件b1对应的文件查询路径可以为b1/c/1.txt，子文件b2对应的文件查询路径可以为b2/2.txt。那么，就可以分别在子文件b1以及子文件b2的打包信息中查找子文件c所对应的哈希值Hash(c)。由上述实施方式可知，可以在子文件b1的打包信息中查找到子文件c所对应的哈希值Hash(c)，那么，针对该子文件b1的二分查找输出的结果就可以为1，接下来就可以在该子文件b1的打包信息中查找该子文件c的文件位置信息。反之，针对该子文件b2的二分查找输出的结果就可以为0。

在本公开实施例中，可以按照路径层级顺序，将文件查找路径进行切分，得到至少一个子路径，并依次查找每个子路径所对应的哈希值，并在查找到该哈希值的情况下，在该目标查找文件中查找该子路径所对应的文件位置信息，从而提高了查找文件位置信息的准确率，其提高了设备的响应速度。

综上，在本公开实施例中，首先可以获取待处理目录，并基于待处理目录中文件夹的层级顺序对每个层级的文件夹以及子文件进行遍历，得到每个层级的文件夹的打包信息，并基于该打包信息生成目标打包文件，以使在查找目标文件的过程中，可以基于打包信息查找该目标文件在目标打包文件中的文件位置信息，从而在一方面能通过文件打包将多个层级的文件夹进行合并，提高文件读取的速度，另一方面在查找目标文件时省略了解压的过程，减少了内存空间的占用，使得设备能够更加稳定的运行。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与文件处理方法对应的文件处理装置以及文件查找装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述文件处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图3示，为本公开实施例提供的一种文件处理装置的示意图，所述装置包括：第一获取单元31、遍历单元32、生成单元33；其中，

第一获取单元31，用于获取待处理目录，其中，所述待处理目录下包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件；

遍历单元32，用于基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，其中，所述打包信息用于指示该层级的文件夹中所包含的每个子文件的文件属性信息和文件位置信息，所述文件位置信息用于指示该子文件在待生成的目标打包文件中的位置；

生成单元33，用于基于所述每个层级的文件夹的打包信息生成所述目标打包文件。

在本公开实施例中，首先可以获取待处理目录，并基于待处理目录中文件夹的层级顺序对每个层级的文件夹以及子文件进行遍历，得到每个层级的文件夹的打包信息，并基于该打包信息生成目标打包文件，从而通过文件打包将多个层级的文件夹进行了合并，提高文件读取的速度。

一种可能的实施方式中，遍历单元32，还用于：

基于所述层级顺序确定所述每个层级的文件夹的第一打包子信息；

确定所述每个层级的文件夹中所包含每个子文件的第二打包子信息；

基于所述第一打包子信息和所述第二打包子信息确定该文件夹的打包信息。

一种可能的实施方式中，遍历单元32，还用于：

确定所述每个层级的文件夹中每个子文件的文件类型，并确定与所述文件类型相匹配的文件打包模式；

基于所述文件打包模式确定该子文件的第二打包子信息。

一种可能的实施方式中，所述第一打包子信息中包含以下至少之一：文件夹的类型标识、文件夹名称、文件夹中所包含子文件数量、文件夹中各子文件的文件名称哈希值、文件夹中各子文件的文件位置信息。

一种可能的实施方式中，在所述子文件的文件类型为文件夹的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件名称、子文件中所包含子文件数量、子文件中各子文件的文件名称哈希值、子文件中各子文件的文件位置信息；在所述子文件的文件类型为文档文件的情况下，所述第二打包子信息中包含以下至少之一：子文件的类型标识、子文件的名称、子文件长度、子文件内容、子文件的文件位置信息。

一种可能的实施方式中，遍历单元32，还用于：

确定每个所述子文件的文件名称哈希值；

基于所述文件名称哈希值对该文件夹中的各子文件进行排序，得到子文件排序结果；

基于所述子文件排序结果确定该文件夹中所包含每个子文件的第二打包子信息。

参照图4示，为本公开实施例提供的一种文件查找装置的示意图，所述装置包括：第二获取单元41、第一确定单元42、第二确定单元43；其中，

第二获取单元41，用于获取文件查找请求，并获取与所述文件查找请求相对应的目标查找文件，其中，所述文件查找请求中携带文件查找路径，所述目标查找文件为基于上述文件处理方法所对应的实施方式得到的目标打包文件；

第一确定单元42，用于按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息；

第二确定单元43，用于基于查找到的所述文件位置信息在所述目标查找文件中确定所述文件查找请求所指示查找的目标文件。

一种可能的实施方式中，第一确定单元42，还用于：

按照所述路径层级顺序，将所述文件查找路径进行切分，得到至少一个子路径；

在所述目标查找文件中依次查找每个子路径所对应的哈希值；

在所述目标查找文件中查找到所述所对应的哈希值的情况下，在所述目标查找文件中查找该子路径所对应的文件位置信息，并将查找到的文件位置信息确定为该子路径所包含子文件在所述目标查找文件中文件位置信息。

关于装置中的各单元的处理流程、以及各单元之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

对应于图1中的文件处理方法，本公开实施例还提供了一种计算机设备500，如图5所示，为本公开实施例提供的计算机设备500结构示意图，包括：

处理器51、存储器52、和总线53；存储器52用于存储执行指令，包括内存521和外部存储器522；这里的内存521也称内存储器，用于暂时存放处理器51中的运算数据，以及与硬盘等外部存储器522交换的数据，处理器51通过内存521与外部存储器522进行数据交换，当所述计算机设备500运行时，所述处理器51与所述存储器52之间通过总线53通信，使得所述处理器51执行以下指令：

获取待处理目录，其中，所述待处理目录下包含至少一个层级的文件夹，每个层级的文件夹中包含至少一个子文件；

基于所述待处理目录中文件夹的层级顺序，遍历所述每个层级的文件夹，及该文件夹中的子文件，得到每个层级的文件夹的打包信息，其中，所述打包信息用于指示该层级的文件夹中所包含的每个子文件的文件属性信息和文件位置信息，所述文件位置信息用于指示该子文件在待生成的目标打包文件中的位置；

基于所述每个层级的文件夹的打包信息生成所述目标打包文件。

对应于图2中的文件查找方法，本公开实施例还提供了另一种计算机设备600，如图6所示，为本公开实施例提供的计算机设备600结构示意图，包括：

处理器61、存储器62、和总线63；存储器62用于存储执行指令，包括内存621和外部存储器622；这里的内存621也称内存储器，用于暂时存放处理器61中的运算数据，以及与硬盘等外部存储器622交换的数据，处理器61通过内存621与外部存储器622进行数据交换，当所述计算机设备600运行时，所述处理器61与所述存储器62之间通过总线63通信，使得所述处理器61执行以下指令：

获取文件查找请求，并获取与所述文件查找请求相对应的目标查找文件，其中，所述文件查找请求中携带文件查找路径，所述目标查找文件为基于上述文件处理方法所对应的实施方式得到的目标打包文件；

按照所述文件查找路径中各子路径的路径层级顺序，确定每个所述子路径所包含子文件在所述目标查找文件中的文件位置信息；

基于查找到的所述文件位置信息在所述目标查找文件中确定所述文件查找请求所指示查找的目标文件。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的文件处理、文件查找方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机程序产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的文件处理、文件查找方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应所述以权利要求的保护范围为准。