CN111625827A

CN111625827A - 文件处理方法、装置、终端设备及计算机可读存储介质

Info

Publication number: CN111625827A
Application number: CN202010479582.1A
Authority: CN
Inventors: 李伟清
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2020-05-29
Filing date: 2020-05-29
Publication date: 2020-09-04
Anticipated expiration: 2040-05-29
Also published as: CN111625827B

Abstract

本申请实施例公开了一种文件处理方法、装置、终端设备及计算机可读存储介质，所述方法包括：获取传输协议请求，其中，所述传输协议请求中携带有待传输文件；对所述传输协议请求进行解析，并获取所述待传输文件；在确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。本申请实施例提供的文件处理方法，通过确定接收到完整的待传输文件后再进行病毒查杀，避免了破坏病毒的特性，确保对病毒查杀的准确性。

Description

文件处理方法、装置、终端设备及计算机可读存储介质

技术领域

本申请实施例涉及信息技术领域，涉及但不限于一种文件处理方法、装置、终端设备及计算机可读存储介质。

背景技术

随着互联网的普及，黑客攻击目标的方式越来越多种多样，但是通常以日常传输文件的相关协议作为恶意文件的载体。目前已知的检测常见传输协议中恶意载体的方式如下：解析传输协议(如超文本传输协议(HTTP，Hyper Text Transfer Protocol))中传输文件数据的部分，将其缓存到一个固定缓冲区中，当缓冲数据满时，将缓冲数据送入杀毒引擎进行查杀，并根据查杀结果进行处理。但是相关技术中，将恶意文件进行病毒查杀时是进行分块查杀，有可能会破坏病毒特征，导致查杀结果不准确。

发明内容

有鉴于此，本申请实施例提供一种文件处理方法、装置、终端设备及计算机可读存储介质。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种文件处理方法，所述方法包括：

获取传输协议请求，其中，所述传输协议请求中携带有待传输文件；

对所述传输协议请求进行解析，并获取所述待传输文件；

在确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。

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

第一获取模块，用于获取传输协议请求，其中，所述传输协议请求中携带有待传输文件；

第一解析模块，用于对所述传输协议请求进行解析，并获取所述待传输文件；

第一确定模块，用于在确定获取到所述待传输文件的所有数据包情况下，对所述待传输文件进行病毒查杀。

本申请实施例提供一种终端设备，所述终端设备至少包括：

处理器；以及

存储器，用于存储可在所述处理器上运行的计算机程序；

其中，所述计算机程序被处理器执行时实现上述文件处理方法的步骤。

本申请实施例提供一种计算机可读存储介质，所述计算机存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行上述文件处理方法的步骤。

本申请实施例提供一种文件处理方法、装置、终端设备及存储介质，通过对获取到的传输协议请求进行解析获取待传输文件，当确定获取到所述待传输文件的所有数据包时，对待传输文件进行病毒查杀，从而基于完整的待传输文件进行杀毒，并不会破坏病毒的特性，确保查杀的准确性，进而能够实现保护客户端或服务器的安全。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为本申请实施例提供的一种文件处理系统的结构示意图；

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

图3为本申请实施例提供的HTTP请求的数据包结构；

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

图5为本申请实施例提供的HTTP请求上传文件的解析流程示意图；

图6为本申请实施例提供的HTTP响应的解析流程示意图；

图7A为本申请实施例提供的HTTP请求头解析的流程示意图；

图7B为本申请实施例提供的HTTP数据解析的流程示意图；

图8为本申请实施例提供的FTP文件解析流程示意图；

图9为本申请实施例提供的SMTP消息格式的结构示意图；

图10为本申请实施例提供的SMTP消息的解析流程示意图；

图11为本申请实施例提供的SMB消息进行解析的流程示意图；

图12为本申请实施例提供的SMB消息杀毒流程示意图；

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

图14为本申请实施例提供的终端设备的组成结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果申请文件中出现“第一\第二\第三”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

基于相关技术所存在的问题，本申请实施例提供一种文件处理方法，所述方法应用于终端设备，该终端设备可以是防火墙(AF，Application Firewall)。图1为本申请实施例提供的一种文件处理系统的结构示意图，如图1所示，在图1中终端设备以AF示出，文件处理系统包括：客户端(client)101、AF 102、服务器(Server)103，其中，AF 102设置于客户端101和服务器103之间，AF 102通过接收客户端101的请求信息，将该信息传输给服务器103，AF 102接收服务器103的针对请求消息的响应信息，将所述响应信息再传输给客户端101。本申请实施例提供的方法可以通过计算机程序来实现，该计算机程序在执行的时候，完成本申请实施例提供的文件处理方法中各个步骤。在一些实施例中，该计算机程序可以被终端设备的处理器执行。图2为本申请实施例提供的文件处理方法的一种实现流程示意图，如图2所示，所述方法包括：

步骤S201，获取传输协议请求。

本申请实施例中，所述传输协议请求可以是客户端发送的，也可以是服务器发送的。所述传输协议请求中携带有待传输文件，所述待传输文件是针对终端设备来说的。本申请实施例中，所述待传输文件可以是可执行文件(EXE，executable file)，也可以非EXE文件。

本申请实施例中，传输协议包括以下之一：服务器信息块(SMB，Server MessageBlock)协议、文件传输协议(FTP，File Transfer Protocol)、超文本传输协议(HTTP，HyperText Transfer Protocol)和简单邮件传输协议(SMTP，Simple Mail TransferProtocol)。其中，SMB协议主要用来使得一个网络上的机器共享计算机文件、打印机、串行端口和通讯等资源。FTP协议包括两个组成部分：FTP服务器和FTP客户端。其中，FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于FTP服务器上的资源。HTTP是一个简单的请求-响应协议，它通常运行在传输控制协议(TCP，Transmission ControlProtocol)之上，HTTP指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应，请求和响应消息的头以美国信息交换标准代码(ASCII，American Standard Code forInformation Interchange)码形式给出；而消息内容则具有一个类似多用途互联网邮件扩展类型(MIME，Multipurpose Internet Mail Extensions)的格式。SMTP是一个相对简单的基于文本的协议，在其之上指定了一条消息的一个或多个接收者，然后消息文本会被传输。

步骤S202，对所述传输协议请求进行解析，获取所述待传输文件。

本申请实施例中，当终端设备获取到传输协议请求后，对所述传输协议请求进行解析。通过对传输协议请求进行解析，可以获取到待传输文件的描述信息和待传输文件的数据。示例性的，图3为本申请实施例提供的HTTP请求的数据包结构，如图3所示，HTTP请求的数据包结构包括：消息头部301和消息实体302，可以对该数据包结构的消息实体302进行解析，从而获取待传输文件，对该数据包结构的消息头部301进行解析可以获取待传输文件的描述信息。本申请实施例中，当获取到待传输文件的数据时，将所述数据存储在自身的缓存空间中。

步骤S203，当确定接收到所述待传输文件的所有数据包时，对所述待传输文件进行病毒查杀。

本申请实施例中，终端设备可以通过描述文件确定待传输文件的数据总长度，描述信息中有表征待传输文件的数据总长度，当接收到的数据长度与所述待传输文件的数据总长度相等时，即确定接收到了待传输文件的所有数据包。当接收完所有数据包时，对所述待传输文件进行病毒查杀。在一些实施例中，终端设备可以根据描述文件确定病毒查杀策略，进而根据病毒查杀策略对所述待传输文件进行病毒查杀。

在一些实施例中，在完成对所述待传输文件的病毒查杀后，终端设备基于所述传输协议请求对应的传输协议传输所述待传输文件。本申请实施例中，终端设备将查杀后的待传输文件基于传输协议进行文件传输，本申请实施例中，如果传输协议请求是HTTP请求，该HTTP请求对应的文件传输协议为HTTP协议，如果传输请求时FTP请求，该FTP请求对应的文件传输协议为FTP协议。本申请实施例中，终端设备基于所述传输协议请求对应的传输协议传输所述待传输文件至服务器或客户端。

本申请实施例提供的文件处理方法，通过对获取到的传输协议请求进行解析获取到待传输文件，当确定接收到所述待传输文件的所有数据包时，对待传输文件进行病毒查杀，从而基于完整的待传输文件进行杀毒，并不会破坏病毒的特性，确保查杀的准确性，进而能够实现保护客户端或服务器的安全。

在一些实施例中，在执行步骤S202“对所述传输协议请求进行解析”时，所述方法还包括：

步骤S205，获取用于描述所述待传输文件的描述信息。

本申请实施例中，所述描述信息包括：文件大小、文件类型等等。

步骤S206，根据所述描述信息，确定病毒查杀策略。

本申请实施例中，可以建立文件大小和/或文件类型与病毒查杀策略的对应关系。所述病毒查杀策略可以是不进行查杀和需要进行查杀，也可以是进行快速杀毒、全数据查杀和自定义查杀。示例性的，建立文件大小与病毒查杀策略的对应关系时，对超过100兆字节(MB，million byte)的文件进行病毒查杀，对比小于100MB的文件不进行病毒查杀。在一些实施例中，建立文件类型与病毒查杀策略的对应关系时，可以是EXE文件进行病毒查杀，对非EXE文件不进行病毒查杀。当然也可以建立文件大小和文件类型与病毒查杀策略的对应关系，示例性地，对超过100MB且文件类型为EXE文件进行查杀。

对应地，步骤S203“在确定接收到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀”，包括：

当确定接收到所述待传输文件的所有数据包时，根据所述病毒查杀策略对所述待传输文件进行病毒查杀。

本申请实施例中，当根据描述文件确定了杀毒策略后，当确定接收到所述待传输文件的所有数据包时，根据所述病毒查杀策略对所述待传输文件进行病毒查杀。承接上面的示例，所述待传输文件为EXE文件，且文件大于100MB，此时需要对该文件进行查杀，终端设备将待传输文件进行病毒查杀。

本申请实施例提供的方法，通过对所述传输协议请求进行解析，得到用于描述所述待传输文件的描述信息；根据所述描述信息，确定病毒查杀策略。通过该方法可以过滤掉不用进行查收的文件，提升了病毒查杀的效率。

在一些实施例中，所述描述信息至少包括数据总长度，在步骤S203“当确定接收到所述待传输文件的所有数据包时，对所述待传输文件进行病毒查杀”之前，所述方法还包括：

步骤S207，判断获取到的所述待传输文件的数据长度是否与所述数据总长度相等。

本申请实施例中，当所述待传输文件的数据长度与所述数据总长度相等时，确定获取到所述待传输文件的所有数据包。当所述待传输文件的数据长度与所述数据总长度不相等时，表明并没有获取完成，此时继续获取待传输文件。

本申请实施例提供的方法，通过接收的文件长度和数据总长度进行比较确定是否获取完成待传输文件，保证了待传输文件为一个整体文件，避免对数据进行分块查杀有可能会破坏病毒特征，导致查杀结果不准确的问题。

在一些实施例中，在步骤S205“获取用于描述所述待传输文件的描述信息”之后，所述方法还包括：

步骤S205A，根据所述描述信息确定所述传输协议请求中是否存在待传输文件。

本申请实施例中，可以通过描述信息确定是否存在待传输文件，例如，当描述信息携带有表征待传输文件的长度时，则确定存在待传输文件。本申请实施例中，当所述传输协议请求中存在待传输文件的情形下，进入步骤S202中的“获取所述待传输文件”。

本申请实施例中，所述步骤S202“对所述传输协议请求进行解析”包括：

步骤S2021，对所述传输协议请求的消息头部进行解析。

本申请实施例中，所述消息头部通常携带有表征待传输文件的描述信息，因此，通过对所述传输协议请求的消息头部进行解析以获取获得待传输文件的描述信息。示例性地，继续参见图3，通过对消息头部301进行解析可以获取到待传输文件的描述信息。

步骤S2022，对所述传输协议请求的消息实体进行解析。

承接上面的示例，通过对消息实体302进行解析，可以获取待传输文件的数据。

本申请实施例提供的文件处理方法，通过对传输协议请求进行解析获取描述信息和待传输文件，从而根据描述信息确定对待传输文件的病毒查杀策略。实现了根据描述信息来过滤需要查杀的待传输文件，提高了终端设备的工作效率。

在一些实施例中，当所述传输协议请求为超文本传输协议HTTP请求时，步骤S203“所述对所述传输协议请求的消息实体进行解析，获得所述待传输文件”可以通过以下步骤实现：

步骤S2031，对所述消息实体进行解析，判断所述消息实体中携带的文件是否是编码文件。

本申请实施例中，为了保证数据的安全性，在进行网络传输时，通常都是编码文件，因此，在获取待传输文件前需要对该编码文件进行解码，如果判断所述消息实体中携带的文件不是编码文件，那么终端设备直接获取消息实体中的待传输文件的数据，如果当所述消息实体中携带的文件是编码文件，执行步骤S2032。

步骤S2032，对所述消息实体中携带的文件进行解码，获取所述待传输文件。

本申请实施例中，在进行消息实体中携带的文件进行解码时，也需要判断是否解码完所述待传输文件。本申请实施例中，通过判断解码的数据长度和编码总长度进行比较，当解码的数据长度与编码总长度相等时即解码完成，当解码完成后，获取所述待传输文件。

在一些实施例中，在步骤S206“根据所述描述信息，确定病毒查杀策略”之前，所述方法还包括：

步骤S208，建立文件类型和/或文件大小与病毒查杀策略的对应关系。

本申请实施例中，终端设备可以根据历史数据确定哪类文件或文件大小存在病毒的概率更大，可以自动生成对应文件类型和/或文件大小与病毒查杀策略的对应关系。在一些实施例中，也可以根据用户的指令，来建立文件类型和/或文件大小与病毒查杀策略的对应关系。本申请实施例中，文件类型通常是EXE文件。

所述描述信息中还包括文件类型和/或文件大小，对应地，步骤S206“所述根据所述描述信息，确定病毒查杀策略”，可以通过以下步骤实现：

步骤S206A，根据所述对应关系，确定所述描述信息对应的病毒查杀策略。

本申请实施例中，由于所述描述信息中包括文件类型和/或文件大小，那么可以根据文件类型和/或文件大小来确定病毒查杀策略的对应关系。

在一些实施例中，在步骤S206“根据所述描述信息，确定病毒查杀策略”之后，所述方法还包括：

步骤S206A，判断所述病毒查杀策略是否为第一次调用。

本申请实施例中，当病毒查杀策略为第一次调用时，执行步骤S206B；当病毒查杀策略不是第一次调用时，执行步骤S206D。

步骤S206B，创建所述病毒查杀策略对应的内存文件。

本申请实施例中，创建的内存文件可以根据病毒查杀策略来进行命名，示例性地，所述病毒查杀策略为快速杀毒，那么该内存文件可以命名为快速杀毒。

步骤S206C，将获取的所述待传输文件存储在所述内存文件中。

在步骤S206C之后，执行步骤S203。

步骤S206D，将获取的所述待传输文件存在原病毒查杀策略对应的内存文件中。

本申请实施例中，在步骤S206D后执行步骤S203。

本申请实施例提供的文件处理方法，通过判断病毒查杀策略是否为第一次调用，如果为第一次调用，创建该病毒查杀策略对应的内存文件，以存储待传输文件，实现不同杀毒策略对应不同的内存文件，方便终端设备进行维护和分析。

在一些实施例中，当所述传输协议请求为文件传输协议FTP请求时，在步骤S201“获取传输协议请求”之前，所述方法还包括：

步骤S200A，接收并解析客户端发送的针对待传输文件的控制指令，得到解析结果。

本申请实施例中，所述解析结果包括客户端的控制命令是否被发送给服务器，本申请实施例中，终端设备对控制命令进行解析，以确定该控制命令是否存在安全隐患。也就是说，AF可以对控制命令进行初步筛选，进而保证了服务器的安全。

步骤S200B，将所述控制指令发送给服务器。

本申请实施例中，在步骤S200B之前，所述方法还包括：判断解析结果是否满足传输所述控制指令的条件，当根据所述解析结果确定达到满足传输所述控制指令的条件时，执行步骤S200B，当不满足传输所述控制指令的条件时，不进行传输。

步骤S200C，接收并解析所述服务器的发送的响应信息，将所述响应信息发送给所述客户端，以使所述客户端与所述服务器根据所述控制指令和所述响应信息建立数据连接，其中，当建立数据连接后，获取传输协议请求。

本申请实施例中，终端设备将控制指令发送给服务器后，服务器根据该控制指令生成响应信息，将响应信息发送给服务器，终端设备对响应信息进行解析，并将响应信息发送给客户端，从而使得所述客户端与所述服务器根据所述控制指令和所述响应信息建立数据连接。

本申请实施例中，当建立数据连接后，服务器或客户端即可以发送传输协议请求，从而使得终端设备获取传输协议请求。

本申请实施例中，当所述文件传输协议请求为文件传输协议FTP请求时，通过对客户端的控制命令进行解析得到解析结果，根据解析结果判断是否发送给服务器，避免了存在安全隐患的控制命令发送给服务器，提高了服务器的安全性。

在一些实施例中，当所述文件传输协议请求为FTP请求时，在步骤S202“对所述传输协议请求进行解析，并获取所述待传输文件”之后，所述方法还包括步骤S209，确定待传输文件的文件类型。

本申请实施例中，当文件协议请求为FTP协议时，可以从解析的待传输文件确定文件类型，例如文件类型可以为EXE文件。

步骤S210，根据所述待传输文件的文件类型确定是否进行病毒查杀，其中，在确定进行病毒查杀且确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。

本申请实施例中，在终端设备中预设有文件类型与是否进行病毒查杀的策略，当待传输文件满足进行病毒查杀的策略时，即确定需要进行病毒查杀，当确定需要进行病毒查杀且确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。

本申请实施例提供的方法，针对FTP协议，直接根据待传输文件的文件类型，确定是否进行查杀，当需要进行病毒查杀时，确定获取到待传输文件的所有数据包的情况下，对该待传输文件进行病毒查杀，避免对数据进行分块查杀有可能会破坏病毒特征，导致查杀结果不准确的问题。

在一些实施例中，当所述文件传输协议请求为SMTP请求时，步骤S202“对所述传输协议请求的消息实体进行解析，获得所述待传输文件”可以通过以下步骤实现，

步骤S202A，对传输协议请求的消息实体进行解析，判断是否存在待传输文件。

本申请实施例中，可以对SMTP协议中的消息实体进行解析，通过对消息实体进行解析确定是否携带有附件，如果携带有附件则表明存在待传输文件。

本申请实施例中，当存在待传输文件的情况下，执行步骤S202B，当不存在待传输文件的情况下，执行步骤S202D。

步骤S202B，对所述待传输文件进行解码。

本申请实施例中，对待传输文件进行解码以识别该待传输文件的数据。

步骤S202C，获取解码后的待传输文件。

本申请实施例中，将解码的待传输文件存储到缓存中，直至获取到所有待传输文件的数据包。

步骤S202D，传输所述传输协议请求。

本申请实施例提供的方法，针对SMTP协议请求，通过对消息实体进行解析判断是否存在待传输文件，如果存在待传输文件，则对该待传输文件进行解码，以获取解码后的待传输文件，进而在接收到待传输文件的最后一个数据包时，进行病毒查杀。避免对数据进行分块查杀有可能会破坏病毒特征，导致查杀结果不准确的问题。

基于前述的各个实施例，本申请实施例再提供一种文件处理方法，图4为本申请实施例提供的文件处理方法的实现流程示意图，如图4所示，所述方法包括：

步骤S401，终端设备根据各个协议(同上述各个实施例中的传输协议)格式，实现对协议中携带的传输文件进行解析。

本申请实施例中，在步骤S401之前，所述方法还包括：获取传输协议请求。所述协议请求可以包括：SMB请求、FTP请求、HTTP请求和SMTP请求。

示例性地，图5为本申请实施例提供的HTTP请求上传文件的解析流程示意图，如图5所示：

步骤S51，解析读入行(line)。

步骤S52，解析消息头部(headers)；

步骤S53，解析消息实体(body)。

本申请实施例中，当解析到body时，获取到NO-BODY或文件传输长度(CTLEN，content length)为0时，执行步骤S54。

本申请实施例中，当解析到body带有content-length字段且不为0时，执行步骤S55。

步骤S54，调用finalize函数回收数据，此时解析流程结束。

步骤S55，body-identity识别。

本申请实施例中，在进行body-identity识别时，持续接收数据。当接收的数据长度与CTLEN相等时，执行步骤S54。如果请求中带有transfer-encoding字段，表明携带的数据经过chunk分块，此时执行步骤S56。

步骤S56，判断编码长度(同图中的BODY CHUNKED LENGTH)是否等于0。

本申请实施例中，当编码长度等于0时，执行步骤S54；当编码长度不等于0时，执行步骤S57。

步骤S57，持续解码。

步骤S58，解码完成(同图中的BODY CHUNKED DATAEND)

这里，确定解码数据长度与编码数据长度相等时，也即解码完成，执行步骤S55。

本申请实施例中，回调HTTP文件处理逻辑进行缓存文件和进入查杀的检测流程。

图6为本申请实施例提供的HTTP响应的解析流程示意图，如图6所示：HTTP响应上传文件解析与HTTP请求上传文件的解析流程类似，包括：

步骤S61，解析读入行(line)。

步骤S62，解析消息头部(headers)；

步骤S63，解析body。

本申请实施例中，当解析到body中CTLEN为0时，执行步骤S64。当CTLEN不为0时，执行步骤S66。本申请实施例中，如果请求中带有transfer-encoding字段，表明携带的数据经过chunk分块，此时执行步骤S67。

步骤S64，调用finalize函数回收数据，此时解析流程结束。

本申请实施例中，当解析到NO-BODY时，执行步骤S65。

步骤S65，body-identity识别，关闭连接。

本申请实施例中，由于NO-BODY，此时即没有数据传输，关闭连接，执行步骤S64。

步骤S66，body-identity识别。

本申请实施例中，在进行body-identity识别时，持续接收数据。当接收的数据长度与CTLEN相等时，执行步骤S64。

步骤S67，判断编码长度(同图中的BODY CHUNKED LENGTH)是否等于0。

本申请实施例中，当编码长度等于0时，执行步骤S64；当编码长度不等于0时，执行步骤S68。

步骤S68，持续解码。

步骤S69，解码完成(同图中的BODY CHUNKED DATAEND)。

这里，在解码完成后，确定解码数据长度与编码数据长度相等时，执行步骤S66。

在解析正常后回调文件处理逻辑进行文件缓存和进入杀毒策略判断逻辑。

本申请实施例中，以HTTP协议请求的文件处理逻辑进行详细说明，本申请实施例中文件处理逻辑即为获取数据包(同上述各个实施例中的获取待传输文件)，所述文件处理逻辑包括：

步骤S71，请求头解析。

图7A为本申请实施例提供的请求头解析的流程示意图，如图7A所示，步骤S71“请求头解析”在实现时包括：请求头解析回调，判断是否打上KV-mark，如果没有打上KV-mark返回DP-CONTINUE，如果打上了KV-mark，判断应用层是否再匹配一次策略，如果应用层没有再匹配一次策略返回DP-CONTINUE，如果应用层再匹配一次策略，判断是否获取到数据委托，如果没有获取到数据委托，返回DP-CONTINUE。

此时进入响应头解析回调，判断是否打上KV-mark，如果没有打上KV-mark返回DP-CONTINUE，如果打上了KV-mark，获取委托数据，注册委托数据并进一步判断是否获取到统一资源定位符(URL，Uniform Resource Locator)，如果没有获取到URL，释放委托数据返回DP-CONTINUE，如果获取到URL，获取文件相关信息(包括文件大小、格式)，进入策略匹配，以判断是否需要进行杀毒。如果不需要杀毒，释放委托数据返回DP-CONTINUE。如果需要进行杀毒，进入URL本地查杀，判断URL本地查杀是否有毒，当有毒时，提示发现病毒并记录该日志。判断委托数据是否丢包，如果有丢包发送重定向页面，随后判断是否记录日志。如果没有丢包，直接确定是否记录日志，如果确定记录日志，在确定后发送该日志，如果确定不记录日志，再次判断委托数据是否有丢包，如果委托数据有丢包，执行DP-STOP，如果委托数据没有丢包返回DP-CONTINUE。

当确定URL本地查杀没有毒时，判断URL本地查杀是否需要杀毒，如果不需要杀毒释放委托数据返回DP-CONTINUE，如果需要进行杀毒，判断杀毒缓存是否达到最大数，当杀毒缓存达到最大数时，释放委托数据返回DP-CONTINUE，当杀毒缓存没有达到最大数时，判断是否获取文件大小，如果不获取文件大小，进入释放委托数据并返回DP-CONTINUE，如果需要获取文件大小，创建存储文件数据的文件，打上接收文件数据标记，返回DP-CONTINUE，此时请求头解析完成。

步骤S72，数据(同上述各个实施例中的消息实体)解析。

本申请实施例中，图7B为本申请实施例提供的HTTP协议的数据解析的流程示意图，如图7B所示，步骤S72“数据解析”在实现时包括：数据内容解析回调，判断是否打上KV-mark，如果没有打上KV-mark返回DP-CONTINUE，如果打上了KV-mark，判断应用层是否再匹配一次策略，如果应用层没有再匹配一次策略则返回DP-CONTINUE，如果应用层再匹配一次策略，判断是否获取到数据委托，没有获取到数据委托时返回DP-CONTINUE，如果获取到委托数据，判断是否进行了文件内容识别，如果没有进行文件内容识别，进行文件类容匹配，将缓存区内容写到临时存储文件，如果进行了文件内容识别，直接将缓存区内容写到临时存储文件。

判断写到临时存储文件的文件内容是否大于2M，如果大于2M，释放委托数据返回DP-CONTINUE，如果不大于2M返回DP-CONTINUE，此时进入响应数据解析回调。

当进入响应数据解析回调时，判断是否打上KV-mark，如果没有打上KV-mark返回DP-CONTINUE，如果打上了KV-mark，判断应用层是否再匹配一次策略，如果应用层没有再匹配一次策略返回DP-CONTINUE，如果应用层再匹配一次策略，判断是否获取到数据委托，如果没有获取到数据委托，返回DP-CONTINUE，如果获取到数据委托，获取显示文件列表(dir)，判断数据方向是否为响应方向，如果数据方向不是响应方向，返回DP-CONTINUE，如果数据方向为响应方向，判断是否进行了文件内容识别，如果没有进行文件内容识别，进行文件内容匹配，通过信息摘要算法(MD₅，MD5 Message-Digest Algorithm)判断文件是否全局排除，如果将文件通过MD₅全局排除，释放委托数据返回DP-CONTINUE，如果没有将文件通过MD₅全局排除，保存当前数据包，开始杀毒。

判断缓存转发数据包是否成功，如果没有成功，释放委托数据返回DP-CONTINUE，如果转发数据包成功，发送杀毒请求至杀毒引擎，判断杀毒请求是否发送成功，如果杀毒请求没有发送成功，释放委托数据返回DP-CONTINUE，如果杀毒请求发送成功，记录缓存数据包到委托数据，丢掉当前转发数据包，执行DP-STOP，如此HTTP请求处理完成。

本申请实施例中，文件处理逻辑主要在解析流程中缓冲文件数据，并判断文件类型是否需要查杀等逻辑判断。

图8为本申请实施例提供的FTP文件解析流程示意图，如图8所示，包括：

步骤S81，判断数据包方向。

当数据包方向为客户端到服务器时，执行步骤S82。当数据包方向为服务器到客户端时，执行步骤S83。

步骤S82，解析控制命令，并执行相应处理。

本申请实施例中，如果解析的控制命令为上传/下载后，等待数据(pendingdata)，判断FTP-INIT位置，并打上对应的标记。

如果解析的控制命令为获取文件大小和切换目录，打上对应的标记。

如果解析的控制命令为切换主被动模式，复位INIT标记。

步骤S83，接收解析服务器响应信息。

步骤S84，判断是否进行数据连接。

本申请实施例中，如果进行数据连接，执行步骤S85，如果不进行数据连接，则执行步骤S86。

步骤S85，进行数据获取处理。

本申请实施例中，进行数据获取处理包括：判断是否为同步序列编号(SYN，Synchronize Sequence Numbers)数据包，如果不是，则退出(out)，如果是，打上FTP-INIT标记，然后判断是否存在上传/下载标记，如果存在在上传/下载标记打上FDATA标记，如果不存在在上传/下载标记，则退出。

本申请实施例中，在解析过程中，判断客户端发起了文件传输控制命令的时机，在接下来的数据传输，直接对文件进行缓存，并判断是否允许此类型文件进入杀毒引擎，若允许，则在文件完整缓存下来之后送入杀毒引擎查杀即可。

步骤S86，解析控制命令响应，根据控制命令响应进行相应处理。

本申请实施例中，当解析的控制命令响应包括文件大小标记且响应成功时，赋值文件大小，当解析的控制命令响应包括切换目录标记响应且响应成功时，切换目录。

图9为本申请实施例提供的SMTP消息格式的结构示意图，如图9所示，该SMTP消息900分为消息头(未示出)，及boundary以上的部分901和boundary夹的消息体内容902，SMTP文件杀毒即要解析带有文件传输的消息体。

图10为本申请实施例提供的SMTP消息的解析流程示意图，如图10所示，包括：

步骤S111，确定\r\n为当前读入行。

步骤S112，判断是否找到strcmp([pos]，给束标记)。如果没有找到strcmp则执行步骤S113。

步骤S113，确定下一个\r\n行。

步骤S114，判断下个\r\n的内容是否为空。

本申请实施例中，如果下个\r\n的内容为空，则执行步骤S115；如果下个\r\n的内容不为空，则执行步骤S116。

步骤S115，进入解析流程。

本申请实施例中，解析流程包括：解析捕获的头字段，判断是否multipart解析，如果不是multipart解析，回调header解析，如果是multipart解析，则返回(ret)。当回调header解析后，判断是否需要解析body，如果不解析body，则ret。如果需要解析body，判断是否需要解析附件，如果需要解析附件，则增大缓冲区长度，进入解析body，如果不需要解析附件，在直接进入解析body。此时解析流程结束。

步骤S116，以：分割读入行。

步骤S117，匹配预定义捕获头字段。

步骤S118，记录捕获头字段在解析缓冲区的偏移。

当执行完步骤S118后，进入步骤S111。

本申请实施例中，在进入SMTP消息体解析逻辑后，判断此消息体是否带有文件，若是传输文件，则将解码后的文件送入文件处理逻辑，进行杀毒逻辑之前的过滤判断。

SMB消息包括：消息头(header)和数据(data)。

图11为本申请实施例提供的对SMB消息进行解析的流程示意图，如图11所示，所述解析方法包括：

步骤S1101，获取SMB数据包。

步骤S1102，判断数据包的方向，所述方向包括：请求方向(Request)或响应方向(Respond)。

当为请求方向时，执行步骤S1103，当为响应方向时，执行步骤S1104。

步骤S1103，缓存请求方向SMB_Flow对象的数据。

当执行完步骤S1103后，进入步骤S1105。

步骤S1104，缓存响应方向SMB_Flow对象的数据。

步骤S1105，判断SMB_TCP对象是否存在。

当SMB_TCP对象不存在时，执行步骤S1106，当SMB_TCP对象存在时，执行步骤S1107。

步骤S1106，创建SMB_TCP对象，设置frame_size＝0，stat＝0。

步骤S1107，判断数据长度大于是否等于frame_size。

如果数据长度小于frame_size，执行步骤S1108，如果数据长度大于frame_size，执行步骤S1109。

步骤S1108，缓存数据解析结束。此时解析流程结束。

步骤S1109，判断内部状态。

本申请实施例中，当stat＝0时，执行步骤S1110，当stat＝1时，执行步骤S1111，当stat不为0且当stat不为1时，执行步骤S1112。

步骤S1110，设置frame_size＝4，stat＝1。

本申请实施例中，当S1110执行完成后继续执行步骤S1107。

步骤S1111，通过4字节网上基本输入输出系统(netbios，Network Basic Input/Output System)解析出SMB消息长度n，设置frame_size＝n+4，stat＝2。继续执行步骤S1107。

步骤S1112，完成SMB消息解析释放SMB_TCP对象。

本申请实施例中，在步骤S1112执行完成后，继续执行步骤S1105，直到SMB消息解析完成。

本申请实施例中，通过对不同协议的解析，进而可以获取传输文件。

步骤S402，终端设备获取协议中传输文件(同上述各个实施例中的待传输文件)将其缓存到内存中。

步骤S403，终端设备在接收到传输文件的最后一个数据包时，将完整文件送入杀毒引擎查杀。

本申请实施例中，以SMB杀毒为例进行说明，图12为本申请实施例提供的SMB杀毒流程示意图，如图12所示，包括：

步骤S1201，获取SMB协议的数据包。

步骤S1202，判断SMB协议的数据包是否是新连接。

本申请实施例中，如果SMB协议的数据包是新连接，执行步骤S1203，如果SMB协议的数据包不是新连接，执行步骤S1204。

步骤S1203，创建SMB连接对象，委托到连接session上。

步骤S1204，通过连接session获取SMB连接对象，通过corelight提供的接口进行数据解析。

步骤S1205，判断数据包是上行还是下行。

本申请实施例中，如果判断数据包是上行，执行步骤S1206，如果判断数据包是下行执行步骤S1207。

步骤S1206，选择上行的Flow对象。

本申请实施例中，执行完S1206后执行步骤S1208。

步骤S1207，选择下行的Flow对象。

本申请实施例中，执行完S1207后执行步骤S1208。

步骤S1208，判断对应方向是否有数据缓存。

本申请实施例中，如果没有数据缓存，执行步骤S1209，如果有数据缓存执行步骤S1210。

步骤S1209，解析是否存在netbios消息。

本申请实施例中，如果不存在netbios消息，执行步骤S1211；如果存在netbios消息，执行步骤S1212。

步骤S1210，将数据追加到对应缓存区。

本申请实施例中，当执行完步骤S1210后，继续执行步骤S1209。

步骤S1211，缓存未解析数据结束返回，此时流程结束。

步骤S1212，判断SMB协议版本。

本申请实施例中，当SMB协议版本为V1版本时，执行步骤S1213，当SMB协议版本为V2版本时，执行步骤S1214。

步骤S1213，SMB v1 header解析。

步骤S1215，SMB v1 command解析。

本申请实施例中，当执行完S1215后，执行步骤S1217。

步骤S1214，SMB v2 header解析。

步骤S1216，SMB v2 command解析。

本申请实施例中，当执行完步骤S1216后，执行步骤S1217。

步骤S1217，保存有效字段的值，如fid，filename。

步骤S1218，判断是否存在文件传输。

本申请实施例中，当存在文件传输时，执行步骤S1219，当不存在文件传输时，执行步骤S1220。

步骤S1220，判断是否还有剩余数据且是SMB v2。

本申请实施例中，如果没有剩余数据且是SMB v2，执行步骤S1221。如果有剩余数据且是SMB v2执行步骤S1214。

步骤S1221，SMB解析结束。

步骤S1219，Kvd SMB文件处理。

步骤S1222，判断是否存在杀毒磁盘的(kvd，Kill Virtual Disk)策略匹配。

本申请实施例中，如果存在kvd策略匹配，执行步骤S1223，如果不存在kvd策略匹配执行步骤S1228。

步骤S1223，判断所述策略是否第一次调用。

本申请实施例中，如果所述策略是第一次调用，执行步骤S1224，如果所述策略不是第一次调用，执行步骤S1225。

步骤S1224，创建内存文件。

步骤S1225，缓存文件数据。

步骤S1226，判断缓存是否足够，且不存在空洞。

本申请实施例中，当缓存不足够，且存在空洞时，执行步骤S1220，当缓存足够，且不存在空洞时，执行步骤S1227。

步骤S1227，扣留当前文件传输的数据包，通知kvd杀毒。

在步骤S1227执行完成后，继续执行步骤S1220。

步骤S1228，打上匹配标记，加速下次策略匹配。

在步骤S1228执行完成后，继续执行步骤S1220。

本申请实施例提供的文件处理方法，通过针对常用HTTP、FTP、SMB协议、SMTP等进行解析，识别其中的文件传输数据，基于完整文件进行文件检测，能最大程度上保证检测的准确性。

基于前述的实施例，本申请实施例提供一种文件处理装置，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central ProcessingUnit)、微处理器(MPU，Microprocessor Unit)、数字信号处理器(DSP，Digital SignalProcessing)或现场可编程门阵列(FPGA，Field Programmable Gate Array)等。

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

第一获取模块1301，用于获取传输协议请求，其中，所述传输协议请求中携带有待传输文件；

第一解析模块1302，用于对所述传输协议请求进行解析，并获取所述待传输文件；

第一确定模块1303，用于在确定获取到所述待传输文件的所有数据包情况下，对所述待传输文件进行病毒查杀。

在一些实施例中，所述文件处理装置1300还包括：

第二解析模块，用于获取用于描述所述待传输文件的描述信息；

第二确定模块，用于根据所述描述信息，确定病毒查杀策略；

对应地，所述第一确定模块1303，包括：

第一确定单元，用于在确定获取到所述待传输文件的所有数据包情况下，根据所述病毒查杀策略对所述待传输文件进行病毒查杀。

在一些实施例中，所述描述信息至少包括数据总长度，所述文件处理装置1300还包括：

第一判断模块，用于判断获取到的所述待传输文件的数据长度是否与所述数据总长度相等，其中，在所述待传输文件的数据长度与所述数据总长度相等情况下，确定获取到所述待传输文件的所有数据包。

在一些实施例中，所述文件处理装置1300还包括：

第三确定模块，用于根据所述描述信息确定所述传输协议请求中是否存在待传输文件；其中，当所述传输协议请求中存在待传输文件的情形下，获取所述待传输文件。

在一些实施例中，所述第一解析模块1302包括：

第一解析单元，用于对所述传输协议请求的消息头部进行解析，其中，对所述消息头部进行解析获取所述待传输文件的描述信息；

第二解析单元，用于对所述传输协议请求的消息实体进行解析，其中，对所述消息实体进行解析获取所述待传输文件。

在一些实施例中，当所述文件传输协议请求为超文本传输协议HTTP请求时，所述第二解析单元包括：

第一判断子单元，用于对所述消息实体进行解析，判断所述消息实体中携带的文件是否是编码文件；

解码子单元，用于在所述消息实体中携带的文件是编码文件情况下，对所述消息实体中携带的文件进行解码，获取所述待传输文件。

在一些实施例中，所述文件处理装置1300还包括：

建立模块，用于建立文件类型和/或文件大小与病毒查杀策略的对应关系；

所述描述信息中还包括文件类型和/或文件大小，对应地，第二确定模块，包括：

第二确定单元，用于根据所述对应关系，确定所述描述信息对应的病毒查杀策略。

在一些实施例中，所述文件处理装置1300还包括：

第二判断模块，用于判断所述病毒查杀策略是否为第一次调用；

创建模块，用于当所述病毒查杀策略是第一次调用时，创建所述病毒查杀策略对应的内存文件；

存储模块，用于将获取的所述待传输文件存储在所述内存文件中。

在一些实施例中，当所述文件传输协议请求为文件传输协议FTP请求时，所述文件处理装置1300还包括：

第一接收模块，用于接收并解析客户端发送的针对待传输文件的控制指令，得到解析结果；

发送模块，用于当根据所述解析结果确定达到满足传输所述控制指令的条件时，将所述控制指令发送给服务器；

第二接收模块，用于接收并解析所述服务器的发送的响应信息，将所述响应信息发送给所述客户端，以使所述客户端与所述服务器根据所述控制指令和所述响应信息建立数据连接，其中，当建立数据连接后，获取传输协议请求。

在一些实施例中，当所述文件传输协议请求为FTP请求时，所述文件处理装置1300还包括：

第四确定模块，用于确定待传输文件的文件类型；

第五确定模块，用于根据所述待传输文件的文件类型确定是否进行病毒查杀，其中，在确定进行病毒查杀且确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。

在一些实施例中，当所述文件传输协议请求为SMTP请求时，第一解析模块1302，包括：

第三解析单元，对传输协议请求的消息实体进行解析，判断是否存在待传输文件；

解码单元，用于在存在待传输文件的情形下，对所述待传输文件进行解码；

获取单元，用于获取解码后的待传输文件。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供的文件处理装置，通过第一获取模块1301获取传输协议请求，第一解析模块1302对所述传输协议请求进行解析，并获取所述待传输文件；第一确定模块1303，用于当确定获取到所述待传输文件的所有数据包时，对所述待传输文件进行病毒查杀。从而基于完整的待传输文件进行杀毒，并不会破坏病毒的特性，确保查杀的准确性，进而能够实现保护客户端或服务器的安全。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的文件处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，ReadOnly Memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

相应地，本申请实施例提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的文件处理方法中的步骤。

本申请实施例提供一种文件传输设备，图14为本申请实施例提供的终端设备的组成结构示意图，如图14所示，所述终端设备1400包括：一个处理器1401、至少一个通信总线1402、用户接口1403、至少一个外部通信接口1404和存储器1405。其中，通信总线1402配置为实现这些组件之间的连接通信。其中，用户接口1403可以包括显示屏，外部通信接口1404可以包括标准的有线接口和无线接口。其中，所述处理器1401配置为执行存储器中存储的文件处理方法的程序，以实现以上述实施例提供的文件处理方法中的步骤

以上文件传输设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请文件传输设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台AC执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

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

对所述传输协议请求进行解析，获取所述待传输文件；

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取用于描述所述待传输文件的描述信息；

根据所述描述信息，确定病毒查杀策略；

对应地，在确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀，包括：

在确定获取到所述待传输文件的所有数据包的情况下，根据所述病毒查杀策略对所述待传输文件进行病毒查杀。

3.根据权利要求2所述的方法，其特征在于，所述描述信息至少包括数据总长度，所述方法还包括：

判断获取到的所述待传输文件的数据长度是否与所述数据总长度相等，其中，在所述待传输文件的数据长度与所述数据总长度相等的情况下，确定获取到所述待传输文件的所有数据包。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

根据所述描述信息确定所述传输协议请求中是否存在待传输文件；其中，在所述传输协议请求中存在待传输文件的情形下，获取所述待传输文件。

5.根据权利要求2所述的方法，其特征在于，所述对所述传输协议请求进行解析，包括：

对所述传输协议请求的消息头部进行解析，其中，对所述消息头部进行解析获取所述待传输文件的描述信息；

对所述传输协议请求的消息实体进行解析，其中，对所述消息实体进行解析获取所述待传输文件。

6.根据权利要求5中所述的方法，其特征在于，在所述传输协议请求为超文本传输协议HTTP请求的情况下，所述对所述传输协议请求的消息实体进行解析，获得所述待传输文件，包括：

判断所述消息实体中携带的文件是否是编码文件；

在所述消息实体中携带的文件是编码文件的情况下，对所述消息实体中携带的文件进行解码，获取所述待传输文件。

7.根据权利要求2所述的方法，其特征在于，所述方法还包括：

建立文件类型和/或文件大小与病毒查杀策略的对应关系；

所述描述信息中还包括文件类型和/或文件大小，对应地，所述根据所述描述信息，确定病毒查杀策略，包括：

根据所述对应关系，确定所述描述信息对应的病毒查杀策略。

8.根据权利要求2所述的方法，其特征在于，所述方法还包括：

判断所述病毒查杀策略是否为第一次调用；

在所述病毒查杀策略是第一次调用的情况下，创建所述病毒查杀策略对应的内存文件；

将获取的所述待传输文件存储在所述内存文件中。

9.根据权利要求1所述的方法，其特征在于，在所述传输协议请求为文件传输协议FTP请求的情况下，所述方法还包括：

接收并解析客户端发送的针对待传输文件的控制指令，得到解析结果；

根据所述解析结果确定达到满足传输所述控制指令的条件的情况下，将所述控制指令发送给服务器；

接收并解析所述服务器的发送的响应信息，将所述响应信息发送给所述客户端，以使所述客户端与所述服务器根据所述控制指令和所述响应信息建立数据连接，其中，在建立数据连接的情况下，获取传输协议请求。

10.根据权利要求1所述的方法，其特征在于，在所述传输协议请求为FTP请求的情况下，所述方法还包括：

确定待传输文件的文件类型；

根据所述待传输文件的文件类型确定是否进行病毒查杀，其中，在确定进行病毒查杀且确定获取到所述待传输文件的所有数据包的情况下，对所述待传输文件进行病毒查杀。

11.根据权利要求1所述的方法，其特征在于，在所述传输协议请求为SMTP请求的情况下，所述对所述传输协议请求进行解析，获取所述待传输文件，包括：

对传输协议请求的消息实体进行解析，判断是否存在待传输文件；

在存在待传输文件的情形下，对所述待传输文件进行解码；

获取解码后的待传输文件。

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

第一确定模块，用于在确定获取到所述待传输文件的所有数据包的情形下，对所述待传输文件进行病毒查杀。

13.一种终端设备，其特征在于，包括：

处理器；以及

存储器，用于存储可在所述处理器上运行的计算机程序；

其中，所述计算机程序被处理器执行时实现权利要求1至11任一项所述的文件处理方法的步骤。

14.一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行上述权利要求1至11任一项所述的文件处理方法的步骤。