CN116996499A - 文件的处理方法、装置及设备 - Google Patents

Abstract

本申请提供一种文件的处理方法、装置及设备，涉及数据处理技术，该方法包括：获取文件下载请求，向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息。基于文件下载请求，确定与下载类型标识对应的下载模式。根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。本申请的方法，实现了增量下载，部署简单、使用方便，有效的提升了文件传输的时效性和便捷性，解决了文件下载不及时的技术问题。

Description

文件的处理方法、装置及设备

技术领域

本申请涉及数据处理技术，尤其涉及一种文件的处理方法、装置及设备。

背景技术

目前，银行等企业有众多面向客户的文件传输场景，例如银账通电子回单业务，就是针对企业收款记账场景需求，将账务明细、电子回单及对账单通过API接口输出至客户。

现有技术中，广大中小型客户从服务器实时下载文件时，需要登录规定的服务器下载工具进行文件下载。

然而现有技术中，由于客户需要登录规定的服务器下载工具进行文件下载，此类工具仅能实现简单的服务器连接和文件下载，用户需要手动连接并人工识别下载需要的文件，使得该项工作需要客户每天派专人花费较多时间完成，且无法实时获取最新文件，导致文件下载不及时。

发明内容

本申请提供一种文件的处理方法、装置及设备，用以解决文件下载不及时的技术问题。

第一方面，本申请提供一种文件的处理方法，包括：

获取文件下载请求，并向服务器发送所述文件下载请求；其中，所述文件下载请求包括下载类型标识和下载请求信息，所述下载请求信息用于获取服务器中的文件；

基于所述文件下载请求，确定与所述下载类型标识对应的下载模式；其中，所述下载模式表征在不同下载类型下的下载规则信息；

根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息；

若服务器接收到所述下载请求信息并根据所述下载请求信息确定存在多个待传输的文件，则根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

进一步地，所述根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息，包括：

若确定所述下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。

进一步地，所述根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件，包括：

根据所述立即下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息指示的本地的已有的文件，确定所述多个待传输的文件中的新增文件；

对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

进一步地，所述根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息，包括：

若确定所述下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对所述服务器的文件进行监控，得到监控信息。

进一步地，所述根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件，包括：

基于所述实时同步模式、所述监控信息指示的本地的已有的文件以及所述服务器中的文件，若在预设的时间段内监控到所述服务器存在新增文件，则对所述新增文件进行下载，获取新增文件。

进一步地，所述方法还包括：

获取文件补推请求，并向服务器发送所述文件补推请求；其中，所述文件补推请求包括补推请求信息，所述补推请求信息用于获取服务器中的未保存文件；

根据所述文件补推请求，获取并下载所述服务器中的未保存文件。

第二方面，本申请提供一种文件的处理装置，包括：

第一获取单元，用于获取文件下载请求，并向服务器发送所述文件下载请求；其中，所述文件下载请求包括下载类型标识和下载请求信息，所述下载请求信息用于获取服务器中的文件；

确定单元，用于基于所述文件下载请求，确定与所述下载类型标识对应的下载模式；其中，所述下载模式表征在不同下载类型下的下载规则信息；

监控单元，用于根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息；

下载单元，用于若服务器接收到所述下载请求信息并根据所述下载请求信息确定存在多个待传输的文件，则根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

进一步地，所述监控单元，具体用于：

若确定所述下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。

进一步地，所述下载单元，包括：

确定模块，用于根据所述立即下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息指示的本地的已有的文件，确定所述多个待传输的文件中的新增文件；

下载模块，用于对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

进一步地，所述监控单元，具体用于：

若确定所述下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对所述服务器的文件进行监控，得到监控信息。

进一步地，所述下载单元，具体用于：

基于所述实时同步模式、所述监控信息指示的本地的已有的文件以及所述服务器中的文件，若在预设的时间段内监控到所述服务器存在新增文件，则对所述新增文件进行下载，获取新增文件。

进一步地，所述装置还包括：

补推单元，用于获取文件补推请求，并向服务器发送所述文件补推请求；其中，所述文件补推请求包括补推请求信息，所述补推请求信息用于获取服务器中的未保存文件；

第二获取单元，用于根据所述文件补推请求，获取并下载所述服务器中的未保存文件。

第三方面，本申请提供一种电子设备，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面所述的方法。

第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面所述的方法。

第五方面，本申请提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所述的方法。

本申请提供的一种文件的处理方法、装置及设备，获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。本方案中，获取并向服务器发送文件下载请求后，基于文件下载请求，确定与下载类型标识对应的下载模式。然后，根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的本地的已下载的文件和/或服务器的已有的文件，确定多个待传输的文件中的新增文件，并对新增文件进行下载，获取新增文件。所以，面向服务器中各类文件的对客户传输场景，可以对新增文件进行实时同步下载，即实现了增量下载，部署简单、使用方便，有效的提升了文件传输的时效性和便捷性，解决了文件下载不及时的技术问题。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图2为本申请实施例提供的一种文件的处理方法的场景示意图；

图3为本申请实施例提供的另一种文件的处理方法的场景示意图；

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

图5为本申请实施例提供的又一种文件的处理方法的场景示意图；

图6为本申请实施例提供的图形交互界面的流程示意图；

图7为本申请实施例提供的一种文件的处理装置的结构示意图；

图8为本申请实施例提供的另一种文件的处理装置的结构示意图；

图9为本申请实施例提供的一种电子设备的结构示意图；

图10为本申请实施例提供的一种电子设备的框图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。

需要说明的是，本申请所涉及的用户信息和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

也就是说，本申请的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

目前，银行等企业有众多面向客户的文件传输场景，例如银账通电子回单业务，就是针对企业收款记账场景需求，将账务明细、电子回单及对账单通过API接口输出至客户。

一个示例中，广大中小型客户从服务器实时下载文件时，需要登录规定的服务器下载工具进行文件下载。但是广大中小型客户不具备与服务器进行API接口对接的条件，若想从服务器实时下载文件，需要找外包单位开发对接API接口，或采用市面已有的服务器连接下载工具进行文件下载。然而现有技术中，此类工具仅能实现简单的服务器连接和文件下载，用户需要手动连接并人工识别下载需要的文件，使得该项工作需要客户每天派专人花费较多时间完成，且无法实时获取最新文件。

一个示例中，由于服务器仅存储近三天的文件，客户想要下载历史数据需要到网点手工填写申请表，流程极为不便捷，还徒增网点工作任务，导致下载文件流程较为繁琐。

本申请提供的一种文件的处理方法、装置及设备，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1为本申请实施例提供的一种文件的处理方法的流程示意图，如图1所示，该方法包括：

步骤101、获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。

示例性地，本实施例的执行主体可以为电子设备、或者终端设备、或者文件的处理装置或设备、或者其他可以执行本实施例的装置或设备，对此不做限制。本实施例中以执行主体为电子设备进行介绍。

首先，电子设备包括前端的图形交互界面，图形交互界面基于Python实现，调用Tkinter实现用户交互，该图形交互界面提供了两个页签，分别实现电子回单自动下载、电子回单补推场景的前端交互。图2为本申请实施例提供的一种文件的处理方法的场景示意图，如图2所示，图形交互界面包括“电子回单自动下载”页面和“电子回单补推”页面。具体的，“电子回单自动下载”页面包括服务器信息联(服务器指存在待下载的文件的服务器，服务器信息联指服务器地址、服务器端口、服务器路径)、用户信息联(指用户名、SFTP登录密钥、针对SFTP登录密钥的“选择路径”按钮)、本地选项联(指回单本地存放路径、针对回单本地存放路径的“选择路径”按钮、是否过滤check.sign文件)、“保存参数”按钮、“立即下载”按钮以及“实时同步”按钮，其中，服务器信息联和用户信息联均是用户网点申请企业账户得到的。图3为本申请实施例提供的另一种文件的处理方法的场景示意图，如图3所示，“电子回单补推”页面包括：APPID、选择密钥文件、针对选择密钥文件的“选择路径”按钮、一级合作方编号、协议编号、针对协议编号的“获取协议编号及账号”按钮、账号、补推开始日期、补推结束日期、“保存参数”按钮以及“开始补推”按钮，还显示了“今日已提交补推申请的次数和剩余次数”，其中，APPID、选择密钥文件、协议编号、账号四者均是申请企业账户得到的，此时的密钥文件与“电子回单自动下载”页面中的SFTP登录密钥是不同的；一级合作方编号是指用户自身的编号；补推开始日期、补推结束日期均可由用户自定义设置；“保存参数”按钮用于保存当前页面的信息；“开始补推”按钮用于对服务器中的未保存文件进行补推，并得到补推获取的未保存文件。

在该步骤中，在“电子回单自动下载”页面，若用户填写相关信息并点击“立即下载”按钮，则获取文件下载请求，并向服务器发送文件下载请求，文件下载请求包括下载类型标识和下载请求信息，下载类型标识为立即下载类型，下载请求信息用于获取服务器中的文件。或者，若用户点击“实时同步”按钮，则获取文件下载请求，并向服务器发送文件下载请求，文件下载请求包括下载类型标识和下载请求信息，下载类型标识为实时同步类型，下载请求信息用于获取服务器中的文件。

需要说明的是，为保证用户连接成功，在用户点击“保存参数”按钮后，会自动测试电子设备与服务器之间的连接，若连接成功，则可执行下载，若连接失败，则提示用户修改相关信息。此外，前端的图形交互界面可以最小化到托盘和开机自启动功能，保证同步下载的无感后台运行；能够基于“保存参数”按钮保存所有参数和选项记录；具备完整的日志记录，便于客户发现问题。

步骤102、基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。

示例性地，下载模式表征在不同下载类型下的下载规则信息，例如，下载类型包括立即下载类型和实时同步类型，下载模式包括与立即下载类型对应的立即下载模式、与实时同步类型对应的实时同步模式。电子设备基于文件下载请求，确定与下载类型标识对应的下载模式。

步骤103、根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。

示例性地，若确定下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。或者，若确定下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对服务器的文件进行监控，得到监控信息。

步骤104、若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。

示例性地，下载模式为立即下载模式。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据立即下载模式，接收服务器发送的多个待传输的文件。并基于监控信息指示的本地的已有的文件，确定多个待传输的文件中的相同文件，并确定除相同文件以外的文件为新增文件，并对多个待传输的文件中的新增文件进行下载，获取新增文件。

或者，下载模式为实时同步模式。基于实时同步模式、监控信息指示的本地的文件以及服务器中的文件，若在预设的时间段内监控到服务器存在新增文件，则对新增文件进行下载，获取新增文件。所以，两种下载模式均进行增量下载，即仅下载用户本地没有的文件

本申请实施例中，获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。本方案中，获取并向服务器发送文件下载请求后，基于文件下载请求，确定与下载类型标识对应的下载模式。然后，根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的本地的已下载的文件和/或服务器的已有的文件，确定多个待传输的文件中的新增文件，并对新增文件进行下载，获取新增文件。所以，面向服务器中各类文件的对客户传输场景，可以对新增文件进行实时同步下载，即实现了增量下载，部署简单、使用方便，有效的提升了文件传输的时效性和便捷性，解决了文件下载不及时的技术问题。

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

步骤201、获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。

示例性地，本步骤可以参见图1中的步骤101，不再赘述。

步骤202、基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。

示例性地，下载模式表征在不同下载类型下的下载规则信息，例如，下载类型包括立即下载类型和实时同步类型，下载模式包括与立即下载类型对应的立即下载模式、与实时同步类型对应的实时同步模式。电子设备基于文件下载请求，确定与下载类型标识对应的下载模式。

步骤203、根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。

步骤203包括以下两种实现方式：

步骤203的第一种实现方式：若确定下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。

步骤203的第二种实现方式：若确定下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对服务器的文件进行监控，得到监控信息。

示例性地，如果确定下载模式为立即下载模式，电子设备对本地的文件进行监控，得到关于本地的文件的监控信息。或者，如果确定下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对服务器的文件进行监控，得到监控信息。其中，预设的时间段是用户预先自定义设置的，也可以是默认设置的，对此不作限定。

步骤204、若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。

步骤204包括以下两种实现方式：

步骤204的第一种实现方式：根据立即下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的本地的已有的文件，确定多个待传输的文件中的新增文件；对多个待传输的文件中的新增文件进行下载，获取新增文件。

步骤204的第二种实现方式：基于实时同步模式、监控信息指示的本地的文件以及服务器中的文件，若在预设的时间段内监控到服务器存在新增文件，则对新增文件进行下载，获取新增文件。

示例性地，若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，服务器会将多个待传输的文件发送至电子设备。电子设备根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的已下载的文件，确定多个待传输的文件中的与已下载的文件相同的重复文件，进而对多个待传输的文件中的新增文件进行下载，获取新增文件。

在第一种下载新增文件的实现方式中，电子设备可以根据立即下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的本地的已下载的文件，在多个待传输的文件中确定与已下载的文件相同的重复文件，进而在多个待传输的文件中，确定除了重复文件以外的文件为新增文件。最后，对多个待传输的文件中的新增文件进行自动下载，获取新增文件。

举例来说，监控信息指示本地有18日的回单文件，则电子设备接收服务器发送的18、19、20日的回单文件，并基于监控信息指示的本地存在18日的回单文件，确定19、20日的回单文件为新增文件，仅下载19、20日的回单文件。最后，下载完成后还可以提示用户是否下载成功，以及成功下载了几个文件、成功下载的文件清单等。

在第二种下载新增文件的实现方式中，电子设备基于实时同步模式、监控信息指示的本地的文件以及服务器中的文件，若在预设的时间段内监控到服务器存在与本地的文件不同，并且，与服务器中的文件不同的新生成文件，则确定新生成文件为新增文件，并对新增文件进行自动下载，获取新增文件。

举例来说，监控信息指示本地有18日的回单文件、服务器端有18、19、20日的回单文件，若在预设的时间段内监控到服务器端存在21日的新生成文件，由于21日的新生成文件与本地的文件不同，并且，与服务器中的文件不同，则确定21日的新生成文件为新增文件，仅下载21日的新生成文件。最后，下载完成后还可以提示用户是否下载成功，以及成功下载了几个文件、成功下载的文件清单等。

步骤205、获取文件补推请求，并向服务器发送文件补推请求；其中，文件补推请求包括补推请求信息，补推请求信息用于获取服务器中的未保存文件。

示例性地，如图3所示，“电子回单补推”页面可发起补推，补推是指由于服务器只保存最近预设天数的数据，需获取预设天数之前的消失的数据。

在该步骤中，若用户在“电子回单补推”页面填写相关信息并点击“开始补推”按钮，电子设备获取文件补推请求，并向服务器发送文件补推请求，文件补推请求包括补推请求信息，补推请求信息包括补推开始日期、补推结束日期。

步骤206、根据文件补推请求，获取并下载服务器中的未保存文件。

示例性地，电子设备发起补推后无需任何操作，基于文件补推请求，服务器补推的文件到达后第一时间自动下载到本地。或者，如图2所示，由用户在“电子回单自动下载”页面手动下载，例如，用户通过立即下载模式下载补推的文件，或者通过实时同步模式下载补推的文件，对获取补推文件的方式不作限定。同时，为节约服务器资源，相应接口有每日补推次数限制，该“电子回单补推”页面清晰展示了用户当前账号的今日剩余次数，并在每次成功发起补推后实时更新。

本申请实施例中，获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。获取文件补推请求，并向服务器发送文件补推请求；其中，文件补推请求包括补推请求信息，补推请求信息用于获取服务器中的未保存文件。根据文件补推请求，获取并下载服务器中的未保存文件。所以，面向SFTP协议下服务器中各类文件的对客户传输场景，可以对新增文件进行实时同步下载，即实现了增量下载，部署简单、使用方便，有效的提升了文件传输的时效性和便捷性，解决了文件下载不及时的技术问题。并且，实现了一套包括实时同步下载、历史文件补推、各类场景切换的完整流程，从而大大降低了接口的对接难度，并改进了扩展使用场景的开发流程，实现了最小成本开发、最小成本推广、最小成本维护。改进了传统文件下载工具简单的基于SFTP协议进行服务器连接实现下载的方法，融入Paramiko、Watchdog等技术，并在服务端实现响应用户的文件补推申请，从而形成一套完整的服务器文件同步下载流程，以满足用户无感操作、获取及时、补取方便的需要。

在上述实施例的基础上，本申请实施例提供一种文件的处理方法的架构，该架构包括：同步传输模块、服务器API响应模块、持久化双向监控模块、场景调用模块。具体的，各模块的功能如下：

(一)同步传输模块：

同步传输模块部署在电子设备处，是前端的图形交互页面和服务器之间的连接层，通过Paramiko实现SFTP协议下的服务器连接和文件传输。其实现了以下功能：

以用户输入的参数进行连接测试；

1、解析基于SFTP协议的用户RSA密钥，实现SFTP下的身份验证和单向文件传输；

2、以HTTP请求方式传输客户端向服务器发送的调用参数，如协议查询、补推申请等。其中，关于协议查询，参考图3中的“电子回单补推”页面中，针对协议编号的“获取协议编号及账号”按钮，若用户点击该按钮，则可以查询协议编号及账号，实现了协议编号和账号的自动获取，以减少用户输入。

3.若用户点击“立即下载”按钮，可以立即调用同步传输模块并实现文件的立即下载，若用户点击“实时同步”按钮，可以监控调用同步传输模块并实现文件的实时下载。

相较于传统SFTP文件传输工具，本申请中的同步传输模块主要改进了文件传输的调用模式，由“客户发起，手工单次执行，无差别下载”，改进为“自动触发下载、实时同步执行、增量及过滤下载”。具体来说，同步传输模块前后联动了前端的图形交互界面和持久化双向监控模块，一方面，在实时同步模式下，根据用户设置的时间参数建立线程，自动在后台保持下载任务，例如，用户在前端设置每日自动下载时间段为早8点到晚10点，则建立一个自动下载线程，在该时间段内保持活动状态，随时可以触发下载过程；另一方面，根据持久化双向监控模块对本地的文件和服务器的文件进行监控，并对于服务器新增文件和本地文件的比对结果，在新文件产生的第一时间触发下载任务，实现增量下载，并根据用户需要过滤特定类型的文件，以期提升文件下载的便捷性、实时性和智能性。

(二)服务器API响应模块：

服务器API响应模块部署再服务器端，在服务器端实现了多个Open API接口，并提供外网接入规范。接口使用HTTP协议接收客户端发送的请求，并返回数据集或操作执行结果，可以实现电子回单的补推。具体包括：

1、电子回单文件的校验及下载接口；

电子回单文件校验及下载接口接收用户的文件下载请求后，判断服务器路径下是否存在回单文件，若存在回单文件，则向下传输回单文件。

文件下载请求示例：

(输入字段为服务器地址'url'、用户名'user_name'、密钥'sign'、服务器路径'service_address')。

返回示例：

(返回字段为任务编号'task_id'、返回信息'retmsg'、返回码'retcode'、文件名'filename'、传输时间'datetime')。其中，返回码表示执行是否完成，是否正常。

2、客户协议及账号信息查询接口；

参考图3中的“电子回单补推”页面中，针对协议编号的“获取协议编号及账号”按钮，“获取协议编号及账号”按钮对应有客户协议及账号信息查询接口，客户协议及账号信息查询接口接收用户的APPID等信息，返回名下协议及账号信息JSON串。

请求示例：

(输入字段为服务器地址'url'、APPID'app_id'、密钥'sign'、一级合作方编号'corpno')返回示例：

(返回字段为一级合作方编号'corpno'、协议编号'cino'、账号'account'、消息编码'msgid'、返回信息'retmsg'、返回码'retcode')。

3、文件补推响应接口。

文件补推响应接口接收用户的文件补推请求，在服务器中的总行数据集中查询相应的历史数据，并复制到服务器传输路径，完成补推。

请求示例：

(输入字段为服务器地址'url'、APPID'app_id'、密钥'sign'、一级合作方编号'corpno'、协议编号'cino'、账号'account'、补推开始及结束日期'startdate/enddate')。

返回示例：

(返回字段为请求编号'orderid'、返回信息'retmsg'、返回码'retcode')

{'orderid':'202303***','retmsg':'提交成功,后续请根据orderid在共享目录搜索回单文件','retcode':'0'}。其中，retcode为0，表示执行完成，正常。

(三)持久化双向监控模块

持久化双向监控模块搭建于同步传输模块之上，通过Watchdog监控变化在前端界面和服务器的连接层上部署了双向监控，即：

1、监控客户端(即电子设备)的时间信息和文件信息。在每日零点实现剩余补推次数的自动还原；监控客户端已下载的文件，在既定时间延迟后控制服务器删除路径下已下载的文件以节约空间。对于电子回单下载场景来说，每当一次下载任务执行成功，服务器端对应文件将于24小时后删除，这是考虑到回单文件用户一般每日下载一次的情况配置的，针对不同业务可配置不同的删除延迟时间，可在后文提到的场景调用模块数据库端进行自定义配置。

2、监控服务器端上传路径，每当路径有新增文件，控制客户端的“实时同步”模式调用一次文件传输，从而实现所需文件的实时下载，极大提升文件下载的时效性。

需要说明的是，持久化双向监控模块在特有线程中进行，不影响主线程实现图形交互界面的操作响应，自动下载和补推功能可同步发起。

(四)场景调用模块

本套服务器文件下载方案以电子回单传输业务为基础流程，但并不仅局限于该应用场景，可切换到包括电子对账单、票类数据传输、凭证传输等各类场景，该功能通过场景调用模块实现。

场景调用模块集成了各套环境下的服务器参数，包括服务器地址、端口、路径、API接口类型、地址等。以上信息集成存储在数据库中以供开发端和客户端调用，任何数据项的变动都能实时同步，不必进行复杂的版本更迭和重新分发。

对于开发流程来说，该模块提供了一种标准化的复用逻辑，只需要针对新的场景定义所需API接口，并在数据库端维护场景的各项信息，就能为本申请添加一个新的应用场景；对于用户使用流程，方案更为便捷，无论是新场景增加还是现有场景参数调整，都不必进行客户端的版本更迭，也不必为不同用户分发不同的特色化版本，场景数据库实现了版本参数的统一同步管理。因此，本申请实现了多套业务场景参数的自动切换，可便捷地应用到各类型的文件下载场景，泛用性较高。

示例性的，图5为本申请实施例提供的又一种文件的处理方法的场景示意图；图6为本申请实施例提供的图形交互界面的流程示意图。

图7为本申请实施例提供的一种文件的处理装置的结构示意图，如图7所示，该装置包括：

第一获取单元31，用于获取文件下载请求，并向服务器发送文件下载请求；其中，文件下载请求包括下载类型标识和下载请求信息，下载请求信息用于获取服务器中的文件。

确定单元32，用于基于文件下载请求，确定与下载类型标识对应的下载模式；其中，下载模式表征在不同下载类型下的下载规则信息。

监控单元33，用于根据下载模式，对本地的文件和/或服务器的文件进行监控，得到监控信息。

下载单元34，用于若服务器接收到下载请求信息并根据下载请求信息确定存在多个待传输的文件，则根据下载模式，接收服务器发送的多个待传输的文件，并基于监控信息，对多个待传输的文件中的新增文件进行下载，获取新增文件。

本实施例的装置，可以执行上述方法中的技术方案，其具体实现过程和技术原理相同，此处不再赘述。

图8为本申请实施例提供的另一种文件的处理装置的结构示意图，在图7所示实施例的基础上，如图8所示，监控单元33，具体用于：

若确定下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。

一个示例中，下载单元34，包括：

确定模块341，用于根据立即下载模式，接收服务器发送的多个待传输的文件，并基于监控信息指示的本地的已有的文件，确定多个待传输的文件中的新增文件。

下载模块342，用于对多个待传输的文件中的新增文件进行下载，获取新增文件。

一个示例中，监控单元33，具体用于：

若确定下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对服务器的文件进行监控，得到监控信息。

一个示例中，下载单元34，具体用于：

基于实时同步模式、监控信息指示的本地的已有的文件以及服务器中的文件，若在预设的时间段内监控到服务器存在新增文件，则对新增文件进行下载，获取新增文件。

一个示例中，该装置还包括：

补推单元41，用于获取文件补推请求，并向服务器发送文件补推请求；其中，文件补推请求包括补推请求信息，补推请求信息用于获取服务器中的未保存文件。

第二获取单元42，用于根据文件补推请求，获取并下载服务器中的未保存文件。

本实施例的装置，可以执行上述方法中的技术方案，其具体实现过程和技术原理相同，此处不再赘述。

图9为本申请实施例提供的一种电子设备的结构示意图，如图9所示，电子设备包括：存储器51，处理器52。

存储器51中存储有可在处理器52上运行的计算机程序。

处理器52被配置为执行如上述实施例提供的方法。

电子设备还包括接收器53和发送器54。接收器53用于接收外部设备发送的指令和数据，发送器54用于向外部设备发送指令和数据。

图10是本申请实施例提供的一种电子设备的框图，该电子设备可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

装置600可以包括以下一个或多个组件：处理组件602，存储器604，电源组件606，多媒体组件608，音频组件610，输入/输出(I/O)接口612，传感器组件614，以及通信组件616。

处理组件602通常控制装置600的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件602可以包括一个或多个处理器620来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件602可以包括一个或多个模块，便于处理组件602和其他组件之间的交互。例如，处理组件602可以包括多媒体模块，以方便多媒体组件608和处理组件602之间的交互。

存储器604被配置为存储各种类型的数据以支持在装置600的操作。这些数据的示例包括用于在装置600上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器604可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件606为装置600的各种组件提供电力。电源组件606可以包括电源管理系统，一个或多个电源，及其他与为装置600生成、管理和分配电力相关联的组件。

多媒体组件608包括在装置600和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件608包括一个前置摄像头和/或后置摄像头。当装置600处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件610被配置为输出和/或输入音频信号。例如，音频组件610包括一个麦克风(MIC)，当装置600处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器604或经由通信组件616发送。在一些实施例中，音频组件610还包括一个扬声器，用于输出音频信号。

I/O接口612为处理组件602和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件614包括一个或多个传感器，用于为装置600提供各个方面的状态评估。例如，传感器组件614可以检测到装置600的打开/关闭状态，组件的相对定位，例如组件为装置600的显示器和小键盘，传感器组件614还可以检测装置600或装置600一个组件的位置改变，用户与装置600接触的存在或不存在，装置600方位或加速/减速和装置600的温度变化。传感器组件614可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件614还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件614还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件616被配置为便于装置600和其他设备之间有线或无线方式的通信。装置600可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件616经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件616还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置600可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器604，上述指令可由装置600的处理器620执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本申请实施例还提供了一种非临时性计算机可读存储介质，当该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述实施例提供的方法。

本申请实施例还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方案。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims (10)

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

获取文件下载请求，并向服务器发送所述文件下载请求；其中，所述文件下载请求包括下载类型标识和下载请求信息，所述下载请求信息用于获取服务器中的文件；

基于所述文件下载请求，确定与所述下载类型标识对应的下载模式；其中，所述下载模式表征在不同下载类型下的下载规则信息；

根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息；

若服务器接收到所述下载请求信息并根据所述下载请求信息确定存在多个待传输的文件，则根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

2.根据权利要求1所述的方法，其特征在于，所述根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息，包括：

若确定所述下载模式为立即下载模式，则对本地的文件进行监控，得到关于本地的文件的监控信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件，包括：

根据所述立即下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息指示的本地的已有的文件，确定所述多个待传输的文件中的新增文件；

对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

4.根据权利要求1所述的方法，其特征在于，所述根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息，包括：

若确定所述下载模式为实时同步模式，则在预设的时间段内，对本地的文件进行监控且对所述服务器的文件进行监控，得到监控信息。

5.根据权利要求4所述的方法，其特征在于，所述根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件，包括：

基于所述实时同步模式、所述监控信息指示的本地的已有的文件以及所述服务器中的文件，若在预设的时间段内监控到所述服务器存在新增文件，则对所述新增文件进行下载，获取新增文件。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：

获取文件补推请求，并向服务器发送所述文件补推请求；其中，所述文件补推请求包括补推请求信息，所述补推请求信息用于获取服务器中的未保存文件；

根据所述文件补推请求，获取并下载所述服务器中的未保存文件。

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

第一获取单元，用于获取文件下载请求，并向服务器发送所述文件下载请求；其中，所述文件下载请求包括下载类型标识和下载请求信息，所述下载请求信息用于获取服务器中的文件；

确定单元，用于基于所述文件下载请求，确定与所述下载类型标识对应的下载模式；其中，所述下载模式表征在不同下载类型下的下载规则信息；

监控单元，用于根据所述下载模式，对本地的文件和/或所述服务器的文件进行监控，得到监控信息；

下载单元，用于若服务器接收到所述下载请求信息并根据所述下载请求信息确定存在多个待传输的文件，则根据所述下载模式，接收所述服务器发送的多个待传输的文件，并基于所述监控信息，对所述多个待传输的文件中的新增文件进行下载，获取新增文件。

8.一种电子设备，其特征在于，包括存储器、处理器，所述存储器中存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述权利要求1-6中任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1-6任一项所述的方法。

10.一种计算机程序产品，其特征在于，包括计算机程序，该计算机程序被处理器执行时实现权利要求1-6中任一项所述的方法。