CN109496419B - 文件处理方法、装置和系统 - Google Patents

Abstract

本申请公开了一种文件处理方法、装置及系统。该方法的一具体实施方式包括：对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部多个客户端生成的文件合并请求；根据文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件。该实施方式实现了通过服务端协调多个客户端上传分片文件的方式上传同一待上传原文件的技术方案，从而可以解决文件上传耗时较长的问题。

Description

文件处理方法、装置和系统

技术领域

本申请涉及计算机技术领域，具体涉及互联网技术领域，尤其涉及一种文件处理方法、装置及系统。

背景技术

现有技术中，虽然可以通过客户端上传文件。但是，现有的客户端的上传文件的速度并不能满足用户的需求，例如，在客户端的上传速度一定但是需要传输的文件所占的内存较大时，由于客户端的上传速度的限制，会导致客户端上传该文件的耗时较长；或者客户端通过网络上传文件，在客户端上传的文件所占的内存虽然不大，但是客户端的网络状况较差时，仍然会由于客户端上传速度的限制，导致上传该文件的耗时较长。

这种由于客户端上传速度存在限制，导致客户端上传文件的耗时较长的情况，会极大地降低用户的体验。

发明内容

本申请的目的在于提出一种文件处理方法、装置及系统，来解决上传文件的耗时较长的技术问题。

第一方面，本申请提供了一种文件处理方法，该方法包括：对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部所述多个客户端生成的文件合并请求；根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

第二方面，本申请实施例提供了一种文件处理方法，该方法包括：多个客户端根据服务端的协调，上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则所述客户端生成合并文件请求，以根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，还原所述待上传原文件。

第三方面，本申请实施例提供了一种文件处理装置，该装置包括：

第一程序单元，配置用于对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；

第二程序单元，配置用于当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部所述多个客户端生成的文件合并请求；

第三程序单元，配置用于根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

第四方面，本申请实施例提供了一种文件处理装置，该装置包括：

第四程序单元，配置用于使客户端上传分片文件，其中，多个客户端根据服务端的协调，上传多个分片文件中的部分分片文件；

第五程序单元，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，配置用于使所述客户端生成合并文件请求，以根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，还原所述待上传原文件。

第五方面，本申请实施例提供了一种设备/终端/服务器，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述的方法。

第七方面，本申请实施例提供了一种文件处理系统，该系统包括服务端以及多个客户端，

服务端对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；

当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得部分或全部所述多个客户端生成的文件合并请求；

所述服务端根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

本申请提供的文件处理方法、装置及系统，通过对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部多个客户端生成的文件合并请求；根据文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件，从而通过服务端协调多个客户端上传分片文件的方式上传同一待上传原文件的技术方案，从而可以解决文件上传耗时较长的问题。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是文件处理系统的结构框图；

图2是本申请实施例提供的一种文件处理方法的方法流程示意图；

图3是本申请实施例提供的另一种文件处理方法的方法流程示意图；

图4是本申请执行文件处理方法的一些电子设备的硬件结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请实施例所提供的文件处理方法可应用于如用户终端(即安装上述客户端的电子终端)中。因此，本申请实施例还提供一种设备/终端/服务器，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现下述方法中客户端所执行的步骤。

于本申请实施例中，用户终端优选为移动终端设备，例如可以包括智能手机、平板电脑、膝上型便携计算机、穿戴式移动终端等等。

电子终端包括存储器(或又称之为存储介质)、存储控制器，一个或多个(图中仅示出一个)处理器、外设接口、射频模块、音频模块、显示屏幕、传感器如加速度传感器、距离传感器等。这些组件通过一条或多条通讯总线/信号线相互通讯。

存储器可用于存储软件程序以及模块，如本申请实施例中的文件处理方法对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理。

存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。处理器以及其他可能的组件对存储器的访问可在存储控制器的控制下进行。

外设接口将各种输入/输入装置耦合至处理器以及存储器。在一些实施例中，外设接口，处理器以及存储控制器可以在单个芯片中实现。在其他一些实例中，他们可以分别由独立的芯片实现。

射频模块用于接收以及发送电磁波，实现电磁波与电信号的相互转换，从而与通讯网络或者其他设备进行通讯。

音频模块向用户提供音频接口，其可包括一个或多个麦克风、一个或者多个扬声器以及音频电路。

显示屏幕在电子终端与用户之间同时提供一个输出及输入界面。具体地，显示屏幕向用户显示内容输出，这些输出的内容可包括文字、图形、视频及其任意组合。

传感器比如为距离传感器用于感应电子终端与人体距离，例如在通话过程中，当电子终端的屏幕贴近用户脸部时，就会自动感应出电子终端与人体距离是多少，当小于某个值时，就会熄灭屏幕，不再接收用户触摸屏幕事件，从而防止通话过程中的误操作。该距离传感器还可以用于实现悬浮等控制。或者，传感器再比如为加速度传感器，用于能感受加速度并转换成可用输出信号的传感器。

可以理解，上述所描述的结构仅为示意，电子终端还可包括比上述所述的电子终端更多或者更少的组件，或者具有不同的配置。上述的各组件可以采用硬件、软件或其组合实现。

于本申请实施例中，电子终端中安装有客户端，该客户端可以是浏览器也可以是第三方应用软件，与服务器(Server)端相对应，为用户提供服务，例如上传服务，用于上传本地的各种文本文件。

于本申请实施例中，电子终端可以包括显示界面，电子终端中的客户端的调用显示界面，用于显示当前所上传文件的进度等信息。显示界面的大小与客户端对显示界面的设置有关，如果客户端设置的显示界面可以是全屏模式，那么显示界面的大小与电子终端显示屏(如显示屏幕)的显示区域大小可以相同，如果客户端设置的显示界面小于电子终端的显示屏，那么显示界面的大小就是实际所设置的显示界面的大小。

图1是文件处理系统的结构框图；如图1所示，其可以包括服务端11以及多个客户端12(图中示例性地示出了三个客户端)，服务端11协同多个客户端12处理文件。其中，服务端11对多个客户端12进行协调，使得每个客户端12上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得部分或全部所述多个客户端12生成的文件合并请求；所述服务端11根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

本实施例中，客户端可以为上述的智能手机、平板电脑、膝上型便携计算机、穿戴式移动终端等，多个客户端可以相同也可以不同，本实施例在此不进行限定。

本实施例中，服务端可以为一台服务器，也可以为多台服务器的集群等，本实施例在此不进行限定。

下面结合图2对本申请实施例中服务端协调客户端来处理文件的方法进行具体说明。具体地，图2是本申请实施例提供的一种文件处理方法的方法流程示意图，如图2所示，其包括：

S21、服务端对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件。

具体地，本实施例中，服务端可以存储有待上传原文件的分片信息，分片信息具体可以包括：待上传原文件的摘要信息、各个分片文件的序号、各个分片文件在待上传原文件中的位置、各个分片文件的大小、各个分片文件的分片状态、各个分片文件上传后的存储地址等。当然，分片信息可以仅包括上述信息中的部分或者全部，本实施例在此不进行限定。

具体地，本实施例中，服务端可以将分片信信息发送至客户端，客户端根据分片信息对待上传原文件进行分片，并上传多个分片文件中的部分分片文件。服务端协调多个客户端上传分片文件的方法参见下述实施例，本实施例在此不再进行详细说明。

S22、当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得部分或全部所述多个客户端生成的文件合并请求。

具体地，本实施例中，服务端可以根据客户端上传分片文件的上传进度，确定多个分片文件的上传进度。例如，上述服务端存储的分片信息可以包括各个分片文件的分片状态，当任意的分片文件由客户端上传完成时，即可将其分片状态改为“上传成功”，以及可以将上传成功的分片文件的数量加1，从而确定上传进度。

由于上传分片文件的过程是由服务端协调多个客户端完成的，在上传分片文件的过程中，客户端可能是变化的，例如，刚开始上传分片文件时仅有3个客户端，在上传过程中增加了1个客户端；或者在开始上传分片文件时有5个客户端，在上传过程中由于网络问题等，其中1个客户端退出上传。由于这个问题的存在，使得服务端存在不易确定将合并后的文件通知至那些客户端，以及不易确定何时通知这些客户端等问题。

因此，本实施例中，当确定所有分片文件均上传完成时，由客户端生成文件合并请求，使得服务端可以准确及时地对客户端进行反馈，从而避免上述问题。

S23、所述服务端根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

具体地，由于上述步骤中指出，分片信息中可以包括各个分片文件的序号，在合并分片文件时，可以按照各个分片文件的需要依次按照分片文件的序号将多个分片文件进行合并，以在服务端还原待上传原文件，从而可以完成文件的上传。

本申请实施例提供的文件处理方法，通过对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部所述多个客户端生成的文件合并请求；根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。通过本申请实施例提供的文件处理方案，可以通过服务端协调多个客户端上传分片文件的方式上传同一待上传原文件，从而可以解决文件上传耗时较长的问题。同时，对于已经上传过的文件，客户端可以直接通过服务端获得对应的存储位置，无需再次上传，即用户发出上传申请后可以即可得到服务端返回的存储地址，实现了文件的秒传。

图3是本申请实施例提供的另一种文件处理方法的方法流程示意图；如图3所示，其包括：

S31、客户端生成上传请求，并将上传请求发送至服务端。

具体地，在生成上传请求时，上传请求中包括待上传原文件的基本信息，例如，待上传原文件的大小、待上传原文件的摘要信息等，摘要信息具体可以为MD5。

S32、服务端根据上传请求确定待上传的原文件是否存在分片信息，若不存在，则执行步骤S33后再执行步骤S34，若存在，则直接执行步骤S34。

本实施例中，摘要信息是通过摘要算法对一段数据进行计算后得到的信息，摘要算法可以为哈希算法等，每段数据都有其独有的摘要信息(即摘要信息与数据之间一一对应)，如果该段数据发生更改，则其对应的摘要信息同样会发生变化。因此，摘要信息相同的数据可以视为同一个数据。

因此，当上传请求中包括摘要信息时，根据摘要信息与每个数据的一一对应关系，服务端可以通过比对摘要信息，确定是否已经存在该待上传原文件的分片信息。

S33、服务端根据待上传的原文件的信息确定待上传原文件的分片信息。

本实施例中，若上传请求中包括待上传原文件的摘要信息以及文件大小信息，则，服务端可以直接根据文件大小信息在逻辑上将待上传原文件分为多个分片文件。例如，若待上传原文件的大小为10M时，可以将待上传原文件分为10个分片文件，每个分片文件的大小为1M。

在将待上传原文件分成多个分片文件后，还需要确定待上传原文件的分片信息，并将分片信息保存。

具体地，分片信息可以包括：待上传原文件的摘要信息、各个分片文件的序号、各个分片文件在待上传原文件中的位置、各个分片文件的大小、各个分片文件的分片状态、各个分片文件上传后的存储地址等。当然，分片信息可以包括上述信息中的部分或者全部，本实施例在此不进行限定。

其中，各个分片的序号即为在确定分片信息时，按照顺序确定的分片文件的编号，例如，当待上传原文件的分为10个分片文件时，按照分片文件在待上传原文件中的先后位置，确定10个分片文件的序号可以为1-10。

各个分片文件在待上传原文件中的位置指的是在待上传原文件中分片文件的开始位置和结束位置，或者分片文件的偏移量等；各个分片文件的分片状态可以为未上传、正在上传、上传完成等。

当然，在本申请的其他实现方式中，确定分片信息也可以由客户端执行。例如，客户端可以在生成上述上传请求的同时，将待上传原文件的分片信息也同时发送至服务端，若服务端中不存在已经确定的待上传原文件的分片信息，则可以直接存储并使用客户端发送的分片信息。

S34、服务端将上传的进度发送至客户端。

本实施例中，上传的进度可以用部分分片信息表示，即可以发送部分分片信息至客户端，客户端得到的分片信息中可以包括分片文件序号以及分片状态(分片状态可以为未上传、正在上传、上传完成等)，以通过所述多个分片文件的序号以及对应的分片状态确定：上传完成的分片文件的数量、正在上传的分片文件的数量以及还未开始上传的分片文件的分片数量。

当然，本申请的其他实现方式中，还可以用其他信息组表示上传的进度，发送至客户端。例如，可以直接将还未开始上传的分片文件的数量以及正在上传的分片文件的数量作为上传的进度，发送至客户端；或者直接将未上传完成的分片文件的数量作为上传的进度，发送至客户端。

S35、客户端根据上传的进度判断所有分片文件是否上传完成，若上传未完成，则执行步骤S36，并再次执行步骤S34，直至所有分片文件上传完成，若上传完成，则执行S37。当然，若上传过程中出错，导致存在所有分片文件始终上传未完成等情况时，也可以根据错误信息直接结束、或者从步骤S31再次开始上传等，本实施例对此不进行限定。

本实施例中，仅以步骤S35在步骤此处执行进行举例说明，在实际使用时，本步骤也可以在其他情况下执行，只要能够使得客户端确定分片文件上传完成即可。

例如，当客户端同时收到服务端的上传任务以及上传的进度，其中根据上传任务可知本次需要上传的分片文件的数量为4个，根据上传的进度可知，未上传完成的分片文件的数量也为4个(即本次上传任务所要求的4个分片文件)，则客户端上传完成分片文件的数量4个即可直接确定所有分片文件上传完成。

S36、服务端根据待上传原文件的分片信息，协调多个客户端，为每个所述客户端分发上传任务，每个所述客户端根据分发给其的所述上传任务，上传所述上传任务所要求的所述分片文件，上传完成后服务端更新分片文件的状态。

具体地，服务端可以为每个所述客户分发上传任务，使得每个所述客户端根据分发给其的所述上传任务，上传所述上传任务所要求的所述分片文件。

具体地，上传任务可以包括需要客户端上传的分片文件的信息(例如分片文件的序号等)，分发上传任务时，对多个客户端分发不同的上传任务，例如服务端协调4个客户端上传分片文件，需要上传的分片文件有10个，10个分片文件对应的序号分别为1-10，则分发上传任务时，第一个客户端上传的分片文件的需要为1-2、第二个客户端上传的分片文件的需要为3-4、第三个客户端上传的分片文件的需要为5-6、第四个客户端上传的分片文件的需要为7-8，剩余序号为9-10的分片文件。

在为客户端分发上传任务时，可以将分发后的分片文件的分片状态标为正在上传。通过为分片文件增加正在上传的标识，可以方便服务端进行协调，避免重复上传同一分片文件的情况发生。

客户端在根据上传任务上传其所要求的分片文件时，可以通过多线程的方式上传所述部分多个分片文件，从而充分利用客户端的网络带宽。

具体地，客户端的线程数量可以根据上传任务中要求上传的分片文件确定，线程数量可以与上传任务中要求上传的分片文件的数量相同；客户端的每一个线程可以上传一个分片文件。

由于由服务器协调多个客户端并行上传分片文件，则分片文件的分片状态不断改变，同时，分片文件的上传进度也在不断改变，因此，服务端还可以在为每个所述客户端分发上传任务的同时将所述上传的进度发送至每个所述客户端，使得客户端可以更新上传的进度。

本实施例中，当客户端上传分片文件时，服务端可以以永久文件的形式存储接收到所述多个分片文件。

具体地，现有的文件传输过程中，大多采用临时文件的存储方式存储文件，这种存储方式对要求多个文件必须存储在统一的服务器里，对服务器的依赖性较高。因此，本实施例中，服务端可以以永久文件的形式存储接收到所述多个分片文件，这样就可以将不同的分片文件传输至同一服务端的不同的服务器中(例如传输至同一服务器集群中的不同服务器中)，只要能够保证分片文件可以顺利合并即可，这样可以降低文件处理系统对服务器的依赖性，同时由于可以通过多个服务器共同处理分片文件，提高了系统的稳定性以及可拓展性。

本实施例中，当客户端根据上传任务完成分片文件的上传后，服务端将已经上传完成的分片文件的分片状态更改为“上传完成”，以更新上传的进度。

此外，当客户端根据所述上传任务完成所述分片文件的上传后，将所述上传的进度发送至完成上传任务的所述客户端。具体地，客户端在根据上传任务完成分片文件的上传后，可以向服务端发送请求，以从服务端获得上传的进度。

另外需要说明的是，服务端可以有时间监控机制，例如，当某一分片文件标记为正在上传后，若其在时间监控机制的监控时长内未上传完成，则将该分片文件的分片状态重新更改为“未上传”。

本实施例中，若客户端根据上传任务上传完成分片文件后，获得的上传的进度中，仅包括正在上传的分片文件以及上传完成的分片文件，此时，所述客户端可以间隔预设时长后发送获取请求以获取所述上传的进度。

S37、多个客户端生成文件合并请求。

S38、服务端根据其中任一文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件，并对生成的文件合并请求的客户端进行反馈。

本实施例中，由于在上传文件时，由服务端协调了多个客户端进行上传，则获得文件合并请求时，服务端可能在设定时限内获取的所述文件合并请求的数量大于1，即可能同时获取多个客户端的文件合并请求，此时，服务端根据任意一个文件合并请求合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件。

具体地，服务端在获取的文件合并请求的数量大于1时，可以通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，以仅还原得到一个所述待上传原文件。具体地，在服务端合并所有的分片文件前，可以先验证上传完成的分片文件的数量是否正确，若正确，再合并所有的分片文件，以提高合并后得到的文件的准确性。

当然，本申请的其他实现方式中，也可以通过其他方式保证服务端仅还原得到一个所述待上传原文件，本实施例对此不进行限定。

本实施例中，所述根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件包括：根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，并校验合并得到的文件与所述待上传原文件的一致性，若一致性校验通过，则确定合并得到的文件为所述待上传原文件。

具体地，可以通过比较合并后得到的文件的摘要信息(此摘要信息是通过摘要算法对合并后得到的文件进行计算得到的)与待上传原文件的摘要信息(此摘要信息是上传请求中的摘要信息)是否一致，来校验合并后得到的文件，摘要信息具体可为MD5信息。

若摘要信息一致，则一致性校验通过，若摘要信息不一致，则一致性校验未通过。

若一致性校验通过，则可以确定合并后得到的文件为待上传原文件。此时，可以将合并后的文件的存储地址返回至客户端，返回存储地址的方式可以为响应客户端的文件合并请求。

另外，若一致性校验未通过，则可以确定某一上传的分片文件发生错误，或合并多个分片文件时发生错误。此时，可以将错误信息返回至客户端，返回的方式同样也可以为响应客户端的文件合并请求。在返回错误的同时，还可以提示信息是否重新进行上传。当有多个客户端确定要重新上传时，服务端可以再次协调多个客户端上传所述待上传原文件的所述多个分片文件。具体上传的方法可以与上述的文件处理方法相同，也可以不同，本申请并不对此进行限定。

本申请实施例提供了一种文件处理装置，该装置包括：

第一程序单元，配置用于对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；

第二程序单元，配置用于当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部所述多个客户端生成的文件合并请求；

第三程序单元，配置用于根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件。

可选地，本申请实施例中，第三程序单元进一步用于：当在设定时限内获取的所述文件合并请求的数量大于1时，通过合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件。

可选地，本申请实施例中，第一程序单元进一步用于：为每个所述客户端分发上传任务，使得每个所述客户端根据分发给其的所述上传任务，上传所述上传任务所要求的所述分片文件。

可选地，本申请实施例中，第三程序单元进一步用于：根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，并校验合并得到的文件与所述待上传原文件的一致性，若一致性校验通过，则确定合并得到的文件为所述待上传原文件。

本申请实施例提供了另一种文件处理装置，该装置包括：

第四程序单元，配置用于使客户端上传分片文件，其中，多个客户端根据服务端的协调，上传多个分片文件中的部分分片文件；

第五程序单元，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，配置用于使所述客户端生成合并文件请求，以根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，还原所述待上传原文件。

本申请实施例还提供一种设备/终端/服务器，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的方法中客户端所执行的步骤。

图4是本申请执行上述文件处理方法的一些电子设备(可作为组成上述服务端的服务器)的硬件结构示意图。根据图4所示，该设备包括：一个或多个处理器41以及存储器42，图4中以一个处理器41为例。

执行文件处理方法的设备还可以包括：输入装置43和输出装置44。

处理器41、存储器42、输入装置43和输出装置44可以通过总线或者其他方式连接，图4中以通过总线连接为例。

存储器42作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如本申请实施例中的文件处理方法对应的程序指令/模块。处理器41通过运行存储在存储器42中的非易失性软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中文件处理方法。

存储器42可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据文件处理时所创建的数据等。此外，存储器42可以包括高速随机存取存储器42，还可以包括非易失性存储器42，例如至少一个磁盘存储器42件、闪存器件、或其他非易失性固态存储器42件。在一些实施例中，存储器42可选包括相对于处理器41远程设置的存储器42，这些远程存储器42可以通过网络连接至客户端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置43可接收输入的数字或字符信息，以及产生与客户端的用户设置以及功能控制有关的键信号输入。输入装置43可包括按压模组等设备。

所述一个或者多个模块存储在所述存储器42中，当被所述一个或者多个处理器41执行时，执行上述任意方法实施例中的文件处理方法。

上述产品可执行本申请实施例所提供的方法，具备执行方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本申请实施例所提供的方法。

本申请实施例的电子设备以多种形式存在，包括但不限于:

(1)移动通信设备:这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括:智能手机(例如iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备:这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括:PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备:这类设备可以显示和播放多媒体内容。该类设备包括:音频、视频播放器(例如iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器:提供计算服务的设备，服务器的构成包括处理器41、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法中客户端所执行的步骤。

本申请实施例还提供另一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法中服务端所执行的步骤。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令中，所述根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件包括：

当在设定时限内获取的所述文件合并请求的数量大于1时，通过合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令中，所述当在设定时限内获取的所述文件合并请求的数量大于1时，通过合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件包括：当在设定时限内获取的所述文件合并请求的数量大于1时，通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，以仅还原得到一个所述待上传原文件。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令中，所述对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件包括：为每个所述客户端分发上传任务，使得每个所述客户端根据分发给其的所述上传任务，上传所述上传任务所要求的所述分片文件。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令还包括：为每个所述客户端分发上传任务的同时将所述上传的进度发送至每个所述客户端；或者，在任一所述客户端根据所述上传任务完成所述分片文件的上传后，将所述上传的进度发送至完成上传任务的所述客户端。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令中，所述根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件包括：根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，并校验合并得到的文件与所述待上传原文件的一致性，若一致性校验通过，则确定合并得到的文件为所述待上传原文件。

可选地，本申请实施例中，存储介质中存储的计算机可执行指令还包括：若一致性校验未通过，则再次协调多个客户端上传所述待上传原文件的所述多个分片文件。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(CPU)执行时，执行本申请的方法中限定的上述功能。需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元也可以设置在处理器中，例如，可以描述为：一种处理器包括接收单元、解析单元、信息选取单元和生成单元。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定，例如，接收单元还可以被描述为“接收用户的网页浏览请求的单元”。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的装置中所包含的；也可以是单独存在，而未装配入该装置中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该装置执行时，使得该装置：接收用户的网页浏览请求，其中，该网页浏览请求包括网址；对该网址所对应的网页页面进行内容解析，提取关键词集合；基于该关键词集合与各条候选推送信息之间的匹配关系，选取至少一条候选推送信息生成推送信息集合；基于该网页页面的内容和该推送信息集合，生成新网页。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (21)

1.一种文件处理方法，其特征在于，包括：

对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；

在上传分片文件的过程中，客户端的数量发生变化，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部变化后的多个客户端生成的文件合并请求；

根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件；

其中，根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件，包括：

当在设定时限内获取的所述文件合并请求的数量大于1时，通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，以仅还原得到一个所述待上传原文件。

2.根据权利要求1所述的方法，其特征在于，所述对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件包括：

为每个所述客户端分发上传任务，使得每个所述客户端根据分发给其的所述上传任务，上传所述上传任务所要求的所述分片文件。

3.根据权利要求2所述的方法，其特征在于，为每个所述客户端分发上传任务的同时将所述上传的进度发送至每个所述客户端；或者，在任一所述客户端根据所述上传任务完成所述分片文件的上传后，将所述上传的进度发送至完成上传任务的所述客户端。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原所述待上传原文件包括：

根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，并校验合并得到的文件与所述待上传原文件的一致性，若一致性校验通过，则确定合并得到的文件为所述待上传原文件。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：若一致性校验未通过，则再次协调多个客户端上传所述待上传原文件的所述多个分片文件。

6.根据权利要求1所述的方法，其特征在于，以永久文件的形式存储接收到所述多个分片文件。

7.根据权利要求1所述的方法，其特征在于，所述上传的进度通过所述多个分片文件的序号以及对应的分片状态确定。

8.根据权利要求1所述的方法，其特征在于，所述上传的进度包括未上传完成的所述多个分片文件的数量。

9.一种文件处理方法，其特征在于，包括：

多个客户端根据服务端的协调，上传多个分片文件中的部分分片文件；

在上传分片文件的过程中，客户端的数量发生变化，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则所述客户端生成合并文件请求，以根据部分或全部变化后的多个客户端生成的文件合并请求合并由多个客户端分别上传的多个分片文件，还原待上传原文件；

其中，根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，还原待上传原文件，包括：

当在设定时限内获取的所述文件合并请求的数量大于1时，通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件。

10.根据权利要求9所述的方法，其特征在于，所述客户端间隔预设时长后发送获取请求，以获取所述上传的进度。

11.根据权利要求9所述的方法，其特征在于，所述客户端根据分发的上传任务，上传所述上传任务所要求的分片文件。

12.根据权利要求11所述的方法，其特征在于，所述客户端在获取所述上传任务的同时获取所述上传的进度；或者，所述客户端根据所述上传任务完成所述分片文件的上传后，获取所述上传的进度。

13.根据权利要求9所述的方法，其特征在于，所述客户端通过多线程的方式上传所述部分多个分片文件。

14.根据权利要求9所述的方法，其特征在于，所述上传的进度包括未上传完成的所述多个分片文件的数量。

15.一种文件处理装置，其特征在于，包括：

第一程序单元，配置用于对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件，在上传分片文件的过程中，客户端的数量发生变化；

第二程序单元，配置用于当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得由部分或全部变化后的多个客户端生成的文件合并请求；

第三程序单元，配置用于根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件；

其中，当在设定时限内获取的所述文件合并请求的数量大于1时，第三程序单元，还配置用于通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，以仅还原得到一个所述待上传原文件。

16.一种文件处理装置，其特征在于，包括：

第四程序单元，配置用于使客户端上传分片文件，其中，多个客户端根据服务端的协调，上传多个分片文件中的部分分片文件，在上传分片文件的过程中，客户端的数量发生变化；

第五程序单元，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，配置用于使所述客户端生成合并文件请求，以根据部分或全部变化后的多个客户端生成的文件合并请求合并由多个客户端分别上传的多个分片文件，还原待上传原文件；

其中，当在设定时限内获取的所述文件合并请求的数量大于1时，第五程序单元，还配置用于通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，仅还原得到一个所述待上传原文件。

17.一种设备/终端/服务器，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-8中任一所述的方法。

18.一种设备/终端/服务器，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求9-14中任一所述的方法。

19.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-8中任一所述的方法。

20.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求9-14中任一所述的方法。

21.一种文件处理系统，其特征在于，包括服务端以及多个客户端，

服务端对多个客户端进行协调，使得每个客户端上传多个分片文件中的部分分片文件；

在上传分片文件的过程中，客户端的数量发生变化，当根据多个分片文件上传的进度确定出所有分片文件均上传完成，则获得部分或全部变化后的多个客户端生成的文件合并请求；

所述服务端根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件；

其中，所述服务端根据所述文件合并请求合并由多个客户端分别上传的多个分片文件，以还原待上传原文件，包括：

当在设定时限内获取的所述文件合并请求的数量大于1时，通过分布式锁确定仅根据其中的一个所述文件合并请求合并由多个客户端分别上传的多个分片文件，以仅还原得到一个所述待上传原文件。

Images