File processing method and device, electronic equipment and computer readable storage medium

By judging the compression ratio of files in the uncompressed queue, sub-files with compression ratios not greater than a threshold are decompressed into memory for detection, solving the problems of excessive IO overhead and memory usage in existing technologies and achieving efficient file detection.

CN116932494BActive Publication Date: 2025-11-25SANGFOR TECH INC
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210335178.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-03-31
Publication Date
2025-11-25
Estimated Expiration
2042-03-31

AI Technical Summary

Technical Problem

Existing technologies for antivirus detection of compressed files suffer from excessive I/O overhead and memory consumption, resulting in low file detection efficiency.

Method used

The compression ratio of files is determined based on the decompression queue. Sub-files with a compression ratio not greater than a preset threshold are decompressed into memory for testing, while sub-files with a compression ratio greater than the threshold are decompressed into disk and reprocessed through the decompression queue until the queue is empty.

Benefits of technology

It effectively saves system I/O consumption, conserves memory space, and improves file detection efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116932494B_ABST
    Figure CN116932494B_ABST
Patent Text Reader

Abstract

The application relates to a file processing method and device, electronic equipment and a computer readable storage medium. The method comprises the following steps: obtaining a to-be-decompressed file based on a to-be-decompressed queue; decompressing a sub-file with a compression rate not greater than a preset compression rate threshold in the to-be-decompressed file into a memory; decompressing a sub-file with a compression rate greater than the preset compression rate threshold in the to-be-decompressed file into a disk, and re-writing the path of the sub-file still compressed after decompression into the to-be-decompressed queue; sequentially obtaining to-be-decompressed files, repeating the above steps until the to-be-decompressed queue is empty. According to the application, whether a sub-file is a compressed file is determined according to the compression rate, the type of the sub-file can be accurately determined at a high speed, performance consumption is saved, a non-compressed file sub-file is directly detected in the memory, the file detection speed is improved, IO cost is saved, and the file processing efficiency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, and in particular to a file processing method and device, electronic equipment and computer readable storage medium. BACKGROUND

[0002] With the development of computer technology, a large amount of data information is processed through the network. In order to ensure the security of the file, virus detection needs to be performed on the file when the computer receives and processes the file to prevent the computer from being damaged by viruses in the file.

[0003] In the anti-virus detection technology of compressed files, a compressed file may have multiple layers of compression, that is, the sub-file in a compressed file may also be a compressed file. When performing anti-virus detection on a compressed file, the compressed file needs to be decompressed to the disk, and then the non-compressed type of sub-file is called from the disk to the memory for detection. When judging whether the sub-file is a compressed file, the file header needs to be read for judgment, which will cause additional performance and IO overhead. In addition, after the sub-file is decompressed to the disk and then called from the disk to the memory for detection, a large amount of IO overhead will be repeatedly occupied, which will cause excessive memory occupation and low file detection efficiency.

[0004] Therefore, the existing anti-virus detection technology for files has the technical problems of excessive IO overhead and excessive memory occupation, and low file detection efficiency, which need to be solved. SUMMARY

[0005] To solve or partially solve the problems in the related art, the present application provides a file processing method, device, electronic equipment and computer readable storage medium, which can effectively save system IO consumption and save memory space.

[0006] The first aspect of the present application provides a file processing method, comprising:

[0007] Step S1, based on a to-be-decompressed queue, obtaining a to-be-decompressed file; wherein the to-be-decompressed queue stores path identifiers of each to-be-decompressed file;

[0008] Step S2, decompressing a sub-file in the to-be-decompressed file whose compression rate is not greater than a preset compression rate threshold to the memory, so as to subsequently directly perform file detection on the uncompressed sub-file in the memory;

[0009] Step S3, decompressing a sub-file in the to-be-decompressed file whose compression rate is greater than the preset compression rate threshold to the disk, and re-writing the path of the sub-file which is still compressed after decompression to the to-be-decompressed queue, returning to execute step S1 until "based on the to-be-decompressed queue, no to-be-decompressed file can be obtained".

[0010] As a possible implementation of the present application, in this implementation, after the step of decompressing the sub-file in the to-be-decompressed file whose compression rate is not greater than a preset compression rate threshold into the memory, the method further comprises:

[0011] If the to-be-decompressed file is still in the to-be-decompressed state after being decompressed into the memory, the to-be-decompressed file is stored into the disk to release the memory, and a path identifier stored in the disk is written into the to-be-decompressed queue.

[0012] As a possible implementation of the present application, in this implementation, after the step of obtaining the to-be-decompressed file, the method further comprises:

[0013] Obtaining original file sizes of the sub-files in the to-be-decompressed file, and decompressing the sub-file whose original file size is greater than a preset file size threshold into the disk;

[0014] Calling the sub-file whose original file size is greater than the preset file size threshold from the disk for detection.

[0015] As a possible implementation of the present application, in this implementation, the step of if the to-be-decompressed file is still in the to-be-decompressed state after being decompressed into the memory, comprises:

[0016] Obtaining a file header of the sub-file after being decompressed into the memory;

[0017] Judging a file type of the sub-file after being decompressed into the memory based on the file header.

[0018] As a possible implementation of the present application, in this implementation, after the step of decompressing the sub-file in the to-be-decompressed file whose compression rate is not greater than a preset compression rate threshold into the memory, the method further comprises:

[0019] Detecting the sub-file whose compression rate is not greater than the preset compression rate threshold by using a preset anti-virus software, and deleting the sub-file whose compression rate is not greater than the preset compression rate threshold from the memory after the detection.

[0020] As a possible implementation of the present application, in this implementation, after the step of returning to execute step S1, the method further comprises:

[0021] When a decompression number of the to-be-decompressed file exceeds a preset decompression number threshold or when a decompression time of the to-be-decompressed file exceeds a preset decompression time threshold, interrupting decompression of the to-be-decompressed file, and storing the to-be-decompressed file into the disk;

[0022] Calling the to-be-decompressed file from the disk for detection.

[0023] As a possible implementation of the present application, in this implementation, after the step of until the to-be-decompressed file cannot be obtained based on the to-be-decompressed queue, the method further comprises:

[0024] deleting the decompression queue and releasing the memory space occupied by the decompression queue.

[0025] The second aspect of the present application provides a file processing device, comprising:

[0026] a file acquisition module configured to acquire a decompression file based on a decompression queue, wherein the decompression queue stores path identifiers of each decompression file;

[0027] a first decompression module configured to decompress a sub-file in the decompression file with a compression rate not greater than a preset compression rate threshold to a memory, so as to facilitate subsequent file detection on the uncompressed sub-file in the memory;

[0028] a second decompression module configured to decompress a sub-file in the decompression file with a compression rate greater than the preset compression rate threshold to a disk, and re-write the path of the still compressed sub-file after decompression to the decompression queue, and return to execute the step of the first decompression module until "unable to acquire a decompression file based on the decompression queue".

[0029] As a possible implementation of the present application, in this implementation, the compression rate acquisition module, before acquiring the compression rate of each sub-file in the decompression file, is further configured to:

[0030] acquire the original file size of each sub-file in the decompression file, and store the sub-file with the original file size greater than a preset file size threshold to a disk;

[0031] call the sub-file with the original file size greater than the preset file size threshold from the disk for detection. As a possible implementation of the present application, in this implementation, the first decompression module, after decompressing the sub-file in the decompression file with the compression rate not greater than the preset compression rate threshold to the memory, is configured to:

[0032] if the decompressed file in the memory is still a decompression file, release the memory by storing the decompression file to the disk, and write the path identifier stored in the disk to the decompression queue.

[0033] As a possible implementation of the present application, in this implementation, the file acquisition module, after acquiring the decompression file, is configured to:

[0034] acquire the original file size of each sub-file in the decompression file, and decompress the sub-file with the original file size greater than a preset file size threshold to a disk;

[0035] call the sub-file with the original file size greater than the preset file size threshold from the disk for detection.

[0036] As a possible implementation form of the present application, in the implementation form, the method for judging whether the sub-file decompressed into the memory is a compressed file comprises:

[0037] obtaining the file header of the sub-file after being decompressed into the memory;

[0038] judging the file type of the sub-file after being decompressed into the memory based on the file header.

[0039] As a possible implementation form of the present application, in the implementation form, the decompressing the sub-file with the compression rate not greater than the preset compression rate threshold in the to-be-decompressed file into the memory further comprises:

[0040] detecting the sub-file with the compression rate not greater than the preset compression rate threshold by using a preset anti-virus software, and deleting the sub-file with the compression rate not greater than the preset compression rate threshold from the memory after the detection.

[0041] As a possible implementation form of the present application, in the implementation form, the returning to the step S1 further comprises:

[0042] when the decompression times of the to-be-decompressed file exceed a preset decompression times threshold or when the decompression time of the to-be-decompressed file exceeds a preset decompression time threshold, interrupting the decompression of the to-be-decompressed file, and storing the to-be-decompressed file into a disk;

[0043] calling the to-be-decompressed file from the disk for detection.

[0044] As a possible implementation form of the present application, in the implementation form, the returning to the step S1 further comprises:

[0045] deleting the to-be-decompressed queue and releasing the memory space occupied by the to-be-decompressed queue.

[0046] The third aspect of the present application provides an electronic device, comprising:

[0047] a processor; and

[0048] a memory having executable codes stored thereon, when the executable codes are executed by the processor, the processor executes the method as described above.

[0049] The fourth aspect of the present application provides a computer readable storage medium having executable codes stored thereon, when the executable codes are executed by the processor of the electronic device, the processor executes the method as described above.

[0050] The embodiment of the application determines whether each sub-file is a compressed file by judging the compression rate of each sub-file in the to-be-decompressed file when processing the file. For a non-compressed sub-file, detection is directly performed in the memory. For a sub-file that is a compressed file, the sub-file is stored in the disk, and the storage path is stored in the to-be-decompressed queue. Then, the sub-file is called in sequence through the storage path in the to-be-decompressed queue, and decompression is performed according to the foregoing steps until the to-be-decompressed queue is empty. The type of the sub-file can be accurately determined at a high speed by judging whether the sub-file is a compressed file according to the compression rate, performance consumption is saved, the detection speed of the file is improved, IO overhead is saved, and the file detection efficiency is improved.

[0051] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory and are not restrictive of the application. BRIEF DESCRIPTION OF DRAWINGS

[0052] The above and other objects, features and advantages of the present application will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which like reference characters refer to like elements throughout the several views, and in which:

[0053] Figure 1 is a flowchart of a file processing method according to an embodiment of the application;

[0054] Figure 2 is a flowchart of a file processing method according to an embodiment of the application;

[0055] Figure 3 is a flowchart of a file processing method according to an embodiment of the application;

[0056] Figure 4 is a flowchart of a file processing method according to an embodiment of the application;

[0057] Figure 5 is a flowchart of a file processing method according to an embodiment of the application;

[0058] Figure 6 is a structural diagram of a file processing device according to an embodiment of the application;

[0059] Figure 7 is a structural diagram of an electronic device according to an embodiment of the application.

[0060] The above and other features, advantages and aspects of the present embodiments will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which: like reference characters refer to like elements throughout the several views, and in which: Detailed Implementation

[0061] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0062] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0063] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0064] In antivirus detection technology for compressed files, a compressed file may contain multiple layers of compression, meaning that a sub-file within a compressed file may also be a compressed file. When performing antivirus detection on a compressed file, it is necessary to decompress the compressed file to the disk and then retrieve the uncompressed sub-files from the disk into memory for detection. Determining whether a sub-file is a compressed file requires reading the file header, which incurs additional performance and I / O overhead. Furthermore, decompressing the sub-files to the disk and then retrieving them from the disk into memory for detection also repeatedly consumes a large amount of I / O overhead, resulting in excessive memory usage and low file detection efficiency.

[0065] To address the aforementioned issues, this application provides a file processing method that effectively saves system I / O consumption, conserves memory space, and improves file detection efficiency.

[0066] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0067] Figure 1 This is a schematic flowchart illustrating a file processing method according to an embodiment of this application.

[0068] Referring to Figure 1 The file processing method provided in the embodiments of the present application comprises the following steps:

[0069] In step S1, a to-be-decompressed file is obtained based on a to-be-decompressed queue, wherein the to-be-decompressed queue stores path identifiers of each to-be-decompressed file.

[0070] In the embodiments of the present application, the to-be-decompressed file refers to a file that needs to be detected, wherein the to-be-decompressed file should be a compressed file, such as a file received from the cloud and sent to the computer system through the network, or a file read through a mobile storage device. The compressed file is a file composed of one or more computer files and metadata, which is used to collect multiple data files into one file for transmission and storage, or compression to reduce storage space. The to-be-decompressed queue refers to a queue constructed in the memory of the computer system, which occupies a certain memory space, and is used to store the path identifiers of the storage paths of the to-be-decompressed files.

[0071] In the embodiments of the present application, as a possible implementation manner of the present application, when the to-be-decompressed queue does not exist, the type of the to-be-decompressed file can be determined, and when it is determined that the to-be-decompressed file is a compressed file, the to-be-decompressed queue is constructed. For the convenience of description, taking a specific embodiment as an example, there is a to-be-detected folder in the computer system, which includes non-compressed files and compressed files. The files in the folder are sequentially obtained for detection, and when it is determined that a certain file in the folder is a compressed file, a to-be-decompressed queue corresponding to the compressed file is constructed. In subsequent use, the path identifiers of the storage paths of the to-be-decompressed files can be stored in the to-be-decompressed queue, so as to facilitate subsequent calling of the to-be-decompressed files through the path identifiers in the to-be-decompressed queue. As a possible implementation manner of the present application, the way to detect whether a certain file in the folder is a compressed file can be to obtain the file header of the file and determine the file type through the file header.

[0072] In step S2, a sub-file with a compression rate not greater than a preset compression rate threshold in the to-be-decompressed file is decompressed into the memory, so as to facilitate subsequent file detection on the uncompressed sub-file in the memory.

[0073] In the embodiments of the present application, the compression rate is a parameter used to describe the file compression effect, and refers to the ratio of the memory size occupied by the compressed file to the memory size occupied by the original file before compression. When each file is compressed, the compression rate is generally automatically stored in the compressed file after compression as a viewable attribute of the compressed file. In the embodiments of the present application, when the compression rates of the sub files in the to-be-decompressed file are obtained, the compression rates stored in the compressed file can be determined. When it is determined that the compression rate of a sub file is not greater than the preset compression rate threshold, the sub file can be considered as a non-compressed type sub file, and the sub file is decompressed into the memory.

[0074] As a possible implementation manner of the present application, for the convenience of description, a specific embodiment is taken as an example. For the to-be-decompressed file A, the file header of the to-be-decompressed file A is obtained to determine that the to-be-decompressed file A is a compressed file, and the to-be-decompressed file A includes sub files a, b and c. The compression rates of the sub files a, b and c are respectively 0.9, 0.98 and 0.84. The preset compression rate threshold is 0.9. The sub files with the compression rates not greater than 0.9 are the sub file a and the sub file c. The sub file a and the sub file c can be decompressed into the memory. For the sub file b, the method in the subsequent steps can be used for processing. In particular, if there is a sub file d in the to-be-decompressed file A, which cannot be detected for the compression rate, the sub file d can be directly decompressed into the disk. Of course, the above embodiment is only a possible implementation manner of the present application, and does not limit the present application.

[0075] In step S3, the sub file with the compression rate greater than the preset compression rate threshold in the to-be-decompressed file is decompressed into the disk, and the path of the sub file still compressed after decompression is written into the to-be-decompressed queue again. The step S1 is returned to be executed until the to-be-decompressed file cannot be obtained based on the to-be-decompressed queue.

[0076] In the embodiments of the present application, according to the foregoing embodiments, when it is determined that there is a sub file with the compression rate greater than the preset compression rate threshold in the to-be-decompressed file, the sub file can be considered as a compressed type sub file. The compressed type sub file is decompressed into the disk, and the storage path of the to-be-decompressed sub file is recorded. The storage path is stored into the to-be-decompressed queue.

[0077] As a possible implementation manner of the present application, for the convenience of description, the foregoing embodiments are taken as an example. There is a sub file b with the compression rate greater than the preset compression rate threshold in the to-be-decompressed file A. The sub file b is considered as a compressed type sub file. The sub file b is stored into the disk as a to-be-decompressed sub file. The storage path of the sub file b is (E: to-be-detected item: to-be-decompressed file A: to-be-decompressed sub file b). The storage path is stored into the to-be-decompressed queue.

[0078] In the embodiment of the present application, the storage path of the to-be-decompressed file is stored in the to-be-decompressed queue, and the storage paths of multiple to-be-decompressed files can be stored in the to-be-decompressed queue. The computer system extracts the to-be-decompressed file according to the storage path stored in the to-be-decompressed queue, repeatedly executes the file processing method in the steps S1 to S3, decompresses the sub-file with the compression rate not greater than the preset compression rate into the memory, and decompresses the sub-file with the compression rate greater than the preset compression rate threshold into the disk, until the to-be-decompressed queue is empty, and the processing of the to-be-decompressed file is completed.

[0079] As a possible implementation of the present application, for the convenience of description, an embodiment is taken as an example, as shown in Figure 2 Figure 2 The flow chart of the file processing method provided by the embodiment of the present application is shown. When the to-be-decompressed file is received, the format of the to-be-decompressed file is identified. When it is detected that the to-be-decompressed file is a non-compressed file, the to-be-decompressed file is directly stored in the memory for corresponding processing. When it is detected that the to-be-decompressed file is a compressed file, a to-be-decompressed queue is constructed, and the storage path of the to-be-decompressed file is stored in the to-be-decompressed queue. The to-be-decompressed queue is traversed, the to-be-decompressed file is extracted according to the file storage path stored in the to-be-decompressed queue, the decompression is started, and the meta information of the sub-file in the to-be-decompressed file is obtained. The meta information includes the original file size and the compressed size of the sub-file. The compression rate of the sub-file can be calculated through the meta information. According to the preset compression rate threshold, the processing mode of the sub-file is determined. The sub-file with the compression rate not greater than the preset compression rate is decompressed into the memory, and the sub-file with the compression rate greater than the preset compression rate threshold is decompressed into the disk. For the sub-file stored in the disk, the storage path is stored in the to-be-decompressed queue, and then the foregoing process is repeated. The to-be-decompressed queue is traversed until the to-be-decompressed queue is empty. Through the foregoing method, all the sub-files in the to-be-decompressed file can be stored in the memory or the disk according to the compression rate.

[0080] When the file is processed, whether the sub-file in the to-be-decompressed file is a compressed file is determined according to the compression rate of the sub-file. For the non-compressed sub-file, the detection is directly performed in the memory. For the sub-file which is a compressed file, the sub-file is stored in the disk, and the storage path is stored in the to-be-decompressed queue. Then the sub-file is sequentially called through the storage path in the to-be-decompressed queue, and the decompression is performed according to the foregoing steps until the to-be-decompressed queue is empty. Whether the sub-file is a compressed file is determined according to the compression rate, the type of the sub-file can be accurately determined at high speed, the performance consumption is saved, the detection of the non-compressed sub-file is directly performed in the memory, the file detection speed is improved, the IO cost is saved, and the file detection efficiency is improved.

[0081] ​As a possible implementation of the present application, in which the sub-file in the to-be-decompressed file with a compression rate not less than a preset compression rate threshold is decompressed into the memory, the method further comprises, after the step of decompressing the sub-file into the memory:

[0082] If the to-be-decompressed file is still in the memory after being decompressed, the memory is released by storing the to-be-decompressed file to the disk, and the storage path of the to-be-decompressed file in the disk is written into the to-be-decompressed queue.

[0083] In the embodiment of the present application, for the sub-file with a smaller compression rate, there may be some special cases that cause the sub-file with a smaller compression rate to be a compressed type file. In this case, the sub-file obtained after being decompressed into the memory needs to be stored to the disk again, and the storage path of the sub-file stored in the disk is written into the to-be-decompressed queue.

[0084] As a possible implementation of the present application, for the convenience of description, a specific embodiment is taken as an example. For the to-be-decompressed file B, it contains a sub-file B1. When the to-be-decompressed file B is decompressed, the compression rate of the sub-file B1 is obtained as 0.8, which is less than the preset compression rate threshold. The sub-file B1 is decompressed into the memory. In a possible case, the file type of the sub-file B1 is detected to determine that the sub-file B1 is a compressed type sub-file. The sub-file B1 is stored to the disk again, and the storage path is written into the to-be-decompressed queue, waiting for subsequent operation.

[0085] As a possible implementation of the present application, in which, as shown in Figure 3 the method further comprises, after obtaining the to-be-decompressed file:

[0086] In step S301, the original file size of each sub-file in the to-be-decompressed file is obtained, and the sub-file with an original file size greater than a preset file size threshold is decompressed to the disk.

[0087] In the embodiment of the present application, for the processing mode of the sub-file of the to-be-decompressed file, the original file size of the sub-file can be obtained before the compression rate of the sub-file is obtained. The original file size refers to the size of the memory occupied by the file before compression. For a compressed file, the original file size is the size of the memory occupied by the file itself.

[0088] As a possible implementation of the present application, to prevent the decompression of an original file that is too large into memory from causing excessive memory usage, when processing a file to be decompressed, the original file size of each sub-file in the file to be decompressed is obtained before the compression rate of each sub-file is obtained. For a sub-file whose original file size exceeds a preset original file size threshold, the sub-file is directly stored to the disk, and the storage path of the sub-file is not stored to the decompression queue. For the convenience of description, taking a specific example, a file to be decompressed B includes sub-files e and f, the original file sizes of the two sub-files are obtained as 500 MB and 100 MB respectively, and the preset original file size threshold is 300 MB. Therefore, the original file size of the sub-file e exceeds the original file size threshold, and the sub-file e is directly stored to the disk. In this step, the processing mode of the sub-file e does not need to be determined by the compression rate of the sub-file e.

[0089] In step S302, the sub-file whose original file size is greater than the preset file size threshold is called from the disk for detection.

[0090] In the embodiment of the present application, after the sub-files of the file to be decompressed are respectively stored to the memory or the disk, the sub-files of the file to be decompressed can be further processed. As described in the background section, the sub-files can be subjected to anti-virus detection by the pre-set anti-virus software to detect whether the sub-files contain viruses. For the files in the disk, the files in the disk can be first called to the memory, and then subjected to detection by the anti-virus software running in the memory.

[0091] As a possible implementation of the present application, for the convenience of description, taking the foregoing embodiment as an example, after the sub-file e is stored to the disk, the sub-file e is directly called from the disk for detection in the subsequent detection of the file.

[0092] The embodiment of the present application directly stores a file whose original file is too large to the disk by obtaining the original file size of each sub-file in the file to be decompressed, thereby preventing the storage of such a sub-file to the memory from occupying excessive memory space, saving the memory space of the computer system, and improving the computing power of the computer.

[0093] As a possible implementation of the present application, in this implementation, Figure 4 As shown in the method for judging whether a sub-file decompressed to the memory is a compressed file, the method comprises:

[0094] In step S401, the file header of the sub-file after being decompressed to the memory is obtained.

[0095] In the embodiment of the present application, the file header refers to the header field of a file, and the type of the file, such as a compressed file or a non-compressed file, can be determined by the file header.

[0096] In step S402, the file type of the sub-file after being decompressed into the memory is determined based on the file header.

[0097] In the embodiment of the present application, when determining the file type of the to-be-decompressed file according to the file header, the file type can be determined according to the content of the first several bytes of the to-be-decompressed file. For example, the first several bytes of a Zip or jar file are 0x504B0304, and the first several bytes of a jpg file are 0xFFD8FF. The content of the first several bytes in the file header can be used to accurately determine the file type of the to-be-decompressed file.

[0098] The embodiment of the present application determines the file type of the to-be-decompressed file through the file header, ensures that the sub-file decompressed into the memory is a non-compressed sub-file, and can be directly subjected to virus detection.

[0099] As a possible implementation manner of the present application, in the implementation manner, after the sub-file with the compression rate not greater than the preset compression rate threshold in the to-be-decompressed file is decompressed into the memory, the method further includes:

[0100] The sub-file with the compression rate not greater than the preset compression rate threshold is detected by using a preset anti-virus software, and after the detection, the sub-file with the compression rate not greater than the preset compression rate threshold is deleted from the memory.

[0101] In the embodiment of the present application, after the sub-file with the compression rate not greater than the preset compression rate threshold is stored into the memory when processing the to-be-decompressed file, the sub-file can be processed according to actual requirements. As mentioned in the background, the file needs to be subjected to virus detection to prevent the file from carrying a virus to harm the computer system.

[0102] In the embodiment of the present application, when the sub-file is subjected to anti-virus detection, a preset anti-virus software can be used. The anti-virus software runs in the memory and is used to detect whether a virus or Trojan horse exists in the file. After the detection of the sub-file is completed, the sub-file is deleted from the memory to prevent the sub-file from occupying the memory for too long time.

[0103] The embodiment of the present application detects the sub-file stored into the memory by using the anti-virus software, effectively prevents the file from carrying a virus to harm the computer system, and deletes the sub-file from the memory after the detection of the sub-file is completed, thereby preventing the sub-file from occupying the memory for too long time and saving the memory space.

[0104] As a possible implementation manner of the present application, in the implementation manner, as shown in FIG. 1, after the step S1, the method further includes: Figure 5

[0105] ​Step S501, when the decompression times of the to-be-decompressed file exceed a preset decompression times threshold or when the decompression time of the to-be-decompressed file exceeds a preset decompression time threshold, interrupting decompression of the to-be-decompressed file and storing the to-be-decompressed file into the disk.

[0106] In the embodiment of the present application, the to-be-decompressed file can have multiple compression processes, and thus, when decompressing the to-be-decompressed file, multiple decompressions of the to-be-decompressed file can be needed. To prevent the memory consumption from being too large due to too many decompression times or too long decompression time of the to-be-decompressed file, a decompression times threshold and a decompression time threshold can be preset. When the decompression times of the to-be-decompressed file exceed the decompression times threshold or the decompression time exceeds the decompression time threshold, the decompression of the to-be-decompressed file is stopped.

[0107] As a possible implementation of the present application, for the convenience of description, a specific embodiment is taken as an example. The to-be-decompressed file C includes a compressed type sub-file C1, the sub-file C1 includes a compressed type sub-file C2, the sub-file C2 includes a compressed type sub-file C3, and the sub-file C3 includes a compressed type sub-file C4. When decompressing the to-be-decompressed file C, four decompressions are needed. If the decompression times threshold is set to three times, after three decompressions are completed, it is found that there are still compressed type files in the to-be-decompressed file that need to be decompressed, and thus the to-be-decompressed file is directly stored into the disk. Alternatively, when decompressing the to-be-decompressed file C, due to the good compression effect of the to-be-decompressed file, the decompression time is too long. If the decompression time threshold is set to three minutes, when the decompression time of the to-be-decompressed file C exceeds three minutes without completing the decompression, the to-be-decompressed file C is directly stored into the disk.

[0108] Step S502, calling the to-be-decompressed file from the disk for detection.

[0109] In the embodiment of the present application, the to-be-decompressed file directly stored into the disk can be called into the memory for detection. The specific detection process has been described in the foregoing embodiment, and thus will not be described here.

[0110] The embodiment of the present application is directed to the to-be-decompressed file with too many decompression times or too long decompression time. By counting the decompression times of the to-be-decompressed file and / or timing the decompression time of the to-be-decompressed file, when the decompression times of the to-be-decompressed file are too many or the decompression time is too long, the to-be-decompressed file is directly stored into the disk, preventing the to-be-decompressed file from occupying too much memory resource for too long time, optimizing the file detection process, and improving the file detection efficiency.

[0111] As a possible implementation of the present application, in the implementation, after "the to-be-decompressed file cannot be obtained based on the to-be-decompressed queue", the following steps are further included:

[0112] delete the to-be-decompressed queue and release the memory space occupied by the to-be-decompressed queue.

[0113] In the embodiment of the present application, when the to-be-decompressed queue is empty after the compression of all the files of the to-be-decompressed file is completed, the to-be-decompressed queue is deleted and the memory space occupied by the to-be-decompressed queue is released. Optionally, when a new to-be-decompressed file needs to be decompressed, a new to-be-decompressed queue can be constructed in the memory.

[0114] In the embodiment of the present application, when the to-be-decompressed file is processed, whether each sub-file in the to-be-decompressed file is a compressed file is determined according to the compression rate of each sub-file. For a non-compressed sub-file, detection is directly performed in the memory. For a sub-file that is a compressed file, the sub-file is stored in the disk, and the storage path is stored in the to-be-decompressed queue. Then, the sub-file is sequentially called through the storage path in the to-be-decompressed queue and decompressed according to the foregoing steps until the to-be-decompressed queue is empty. Whether the sub-file is a compressed file is determined according to the compression rate, which can accurately determine the type of the sub-file at a high speed, save performance consumption, directly detect the non-compressed sub-file in the memory, improve the file detection speed, save IO overhead, and improve the file detection efficiency.

[0115] Corresponding to the foregoing application function implementation method embodiment, the present application further provides a file processing apparatus, an electronic device, and corresponding embodiments.

[0116] Figure 6 FIG. 1 is a structural schematic diagram of a file processing apparatus according to an embodiment of the present application.

[0117] Referring to FIG. 1, Figure 6 The file processing apparatus 60 provided by the embodiment of the present application includes a file acquisition module 610, a first decompression module 620, and a second decompression module 630, wherein:

[0118] The file acquisition module 610 is configured to acquire a to-be-decompressed file based on a to-be-decompressed queue, wherein the to-be-decompressed queue stores path identifiers of each to-be-decompressed file.

[0119] The first decompression module 620 is configured to decompress a sub-file in the to-be-decompressed file whose compression rate is not greater than a preset compression rate threshold to the memory, so as to subsequently directly perform file detection on the uncompressed sub-file in the memory.

[0120] The second decompression module 630 is configured to decompress a sub-file in the to-be-decompressed file whose compression rate is greater than the preset compression rate threshold to the disk, and re-write the path of the sub-file that is still compressed after decompression to the to-be-decompressed queue, and return to execute the step of the first decompression module until "a to-be-decompressed file cannot be acquired based on the to-be-decompressed queue".

[0121] As a possible implementation of the present application, in this implementation, the compression rate obtaining module, before obtaining the compression rate of each sub-file in the file to be decompressed, is further configured to:

[0122] obtain the original file size of each sub-file in the file to be decompressed, and store the sub-file with an original file size greater than a preset file size threshold to a disk;

[0123] call the sub-file with an original file size greater than a preset file size threshold from the disk for detection. As a possible implementation of the present application, in this implementation, the first decompression module, after the step of decompressing the sub-file in the file to be decompressed with a compression rate not greater than a preset compression rate threshold to the memory, is configured to:

[0124] if the file to be decompressed is still in the memory after being decompressed, release the memory by storing the file to be decompressed to the disk, and write the path identifier stored in the disk to the decompression queue.

[0125] As a possible implementation of the present application, in this implementation, the file obtaining module, after obtaining the file to be decompressed, is configured to:

[0126] obtain the original file size of each sub-file in the file to be decompressed, and decompress the sub-file with an original file size greater than a preset file size threshold to a disk;

[0127] call the sub-file with an original file size greater than a preset file size threshold from the disk for detection.

[0128] As a possible implementation of the present application, in this implementation, the method for judging whether the sub-file decompressed to the memory is a compressed file comprises:

[0129] obtaining the file header of the sub-file after being decompressed to the memory;

[0130] judging the file type of the sub-file after being decompressed to the memory based on the file header.

[0131] As a possible implementation of the present application, in this implementation, after the step of decompressing the sub-file in the file to be decompressed with a compression rate not greater than a preset compression rate threshold to the memory, the method further comprises:

[0132] detecting the sub-file with a compression rate not greater than a preset compression rate threshold by using a preset anti-virus software, and deleting the sub-file with a compression rate not greater than a preset compression rate threshold from the memory after the detection.

[0133] As a possible implementation of the present application, in this implementation, the step of returning to perform step S1 further comprises:

[0134] interrupting decompression of the to-be-decompressed file and storing the to-be-decompressed file into the disk when the number of decompression times of the to-be-decompressed file exceeds a preset threshold of the number of decompression times or when the decompression time of the to-be-decompressed file exceeds a preset threshold of the decompression time;

[0135] calling the to-be-decompressed file from the disk for detection.

[0136] As a possible implementation of the present application, in the implementation, until "the to-be-decompressed file cannot be obtained based on the to-be-decompressed queue", the following operations are further included:

[0137] deleting the to-be-decompressed queue and releasing the memory space occupied by the to-be-decompressed queue.

[0138] As to the apparatus in the above embodiments, the specific manners in which the modules perform operations have been described in detail in the embodiments of the method, and will not be described in detail here. The apparatus can be in the form of an image file, which, after being executed, can be run in the form of a container or a virtual machine to implement the data processing method described in the present application. Of course, it is not limited to the form of an image file, and any software form capable of implementing the file processing method described in the present application is within the protection scope of the present application, such as a software module implemented in a hypervisor (virtual machine monitor) in a cloud computing platform.

[0139] In the present application, when it is determined that the to-be-decompressed file is a compressed file, a to-be-decompressed queue is constructed. For the sub-files in the to-be-decompressed file, it is determined whether each sub-file is a compressed file by the compression rate of each sub-file. For a non-compressed sub-file, detection is directly performed in the memory. For a sub-file that is a compressed file, the sub-file is stored into the disk, and the storage path is stored into the to-be-decompressed queue. Then, the sub-file is sequentially called through the storage path in the to-be-decompressed queue, and decompression is performed according to the foregoing steps until the to-be-decompressed queue is empty. The compression rate is used to determine whether the sub-file is a compressed file, which can accurately determine the type of the sub-file at a high speed, save performance consumption, directly detect the non-compressed sub-file in the memory, improve the file detection speed, save IO overhead, and improve the file detection efficiency.

[0140] Figure 7 FIG. 1 is a structural schematic diagram of an electronic device according to an embodiment of the present application.

[0141] Referring to FIG. 1, Figure 7 The electronic device 70 includes a memory 710 and a processor 720.

[0142] The processor 720 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, or the like. The general-purpose processor can be a microprocessor or the processor can be any conventional processor.

[0143] The electronic device 70 described above can also be in a cluster form, such as a cloud computing platform. The cloud computing platform is a business form that uses computing virtualization, network virtualization, and storage virtualization technology to organize multiple independent server physical hardware resources into a pooled resource. It is a structure of software-defined resources based on the development of virtualization technology, and can provide resources and capabilities in the form of virtual machines and containers. By eliminating the fixed relationship between hardware and the operating system, relying on network connectivity to schedule unified resources, and then providing the required virtual resources and services, it is a new type of IT and software delivery mode, with the characteristics of flexibility, elasticity, distribution, multi-tenancy, and on-demand.

[0144] Current cloud computing platforms support several service modes:

[0145] SaaS (Software as a Service): Cloud computing platform users do not need to purchase software, but instead rent software deployed on the cloud computing platform. Users do not need to maintain the software, and the software service provider will fully manage and maintain the software.

[0146] PaaS (Platform as a Service): Cloud computing platform users (usually software developers at this time) can build new applications or extend existing applications on the architecture provided by the cloud computing platform, without having to purchase development, quality control, or production servers.

[0147] IaaS (Infrastructure as a Service): Cloud computing platforms provide data centers, infrastructure hardware, and software resources over the Internet. IaaS mode cloud computing platforms can provide servers, operating systems, disk storage, databases, and / or information resources.

[0148] The memory 710 can include various types of storage units, such as a system memory, a read-only memory (ROM), and a permanent storage device. Among them, the ROM can store static data or instructions required by the processor 720 or other modules of the computer. The permanent storage device can be a read-write storage device. The permanent storage device can be a non-volatile storage device that does not lose stored instructions and data even after the computer is powered off. In some embodiments, the permanent storage device uses a mass storage device (such as a magnetic or optical disk, flash memory) as a permanent storage device. In some other embodiments, the permanent storage device can be a removable storage device (such as a floppy disk, an optical drive). The system memory can be a read-write storage device or a volatile read-write storage device, such as a dynamic random access memory. The system memory can store some or all of the instructions and data required by the processor during runtime. In addition, the memory 710 can include a combination of any computer readable storage media, including various types of semiconductor storage chips (such as DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), magnetic disks and / or optical disks. In some embodiments, the memory 710 can include a read and / or write removable storage device, such as a compact disc (CD), a read-only digital versatile disc (such as DVD-ROM, double-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (such as an SD card, a min SD card, a Micro-SD card, etc.), a magnetic floppy disk, etc. The computer readable storage medium does not include a carrier wave and an instantaneous electronic signal transmitted by wireless or wired transmission.

[0149] The executable code stored on the memory 710 can cause the processor 720 to perform part or all of the above-mentioned methods when the executable code is processed by the processor 720.

[0150] In addition, the method according to the present application can also be implemented as a computer program or computer program product, which includes computer program code instructions for executing part or all of the steps of the above-mentioned methods of the present application.

[0151] Alternatively, the present application can also be implemented as a computer readable storage medium (or non-transitory machine readable storage medium or machine readable storage medium) having executable code (or computer program or computer instruction code) stored thereon, which, when executed by a processor of an electronic device (or server, etc.), causes the processor to execute part or all of the steps of the above-mentioned methods according to the present application.

[0152] The above description merely illustrates the preferred embodiment of this application and the principles thereof. For a fuller understanding of the scope thereof, the following reference is hereby included: the scope of the disclosure is not limited to the specific combinations of technical features disclosed herein, but is also intended to cover other technical solutions formed by any combination of the technical features disclosed herein or equivalent features thereof, without departing from the concept disclosed herein. For example, the technical solutions formed by replacing the above features with similar features disclosed in the disclosure (but not limited to) having similar functions.

[0153] Furthermore, while operations are depicted in a particular, chronological sequence in this disclosure, this should not be understood as requiring that the operations be performed in that particular order, or in the order illustrated. To the contrary, it is contemplated that the operations might be performed in different order, or in parallel. Likewise, while specific implementation details are contained in the above discussion, these should not be construed as limiting the scope of the disclosure. Certain features described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. It will be appreciated that details of the foregoing embodiments, given only for purposes of illustration, are not intended to limit the scope of the present disclosure. As readily apparent to one skilled in the art, the foregoing detailed description is intended to be illustrative only and modifications are expected in various forms. Numerous replacement embodiments will be apparent to the skilled reader. Accordingly, the scope of the disclosure should be judged in terms of the claims and equivalents thereof rather than the details of the foregoing description.

[0154] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A file processing method characterized by, The method comprises: Step S1, obtaining a to-be-decompressed file based on a to-be-decompressed queue; wherein the to-be-decompressed queue stores path identifiers of each to-be-decompressed file; Step S2, decompressing a sub-file in the to-be-decompressed file with a compression rate not greater than a preset compression rate threshold into a memory, so as to facilitate subsequent file detection on the uncompressed sub-file in the memory; Step S3, decompressing a sub-file in the to-be-decompressed file with a compression rate greater than the preset compression rate threshold into a disk, and re-writing a path of the still compressed sub-file after decompression into the to-be-decompressed queue, and returning to execute step S1 until "no to-be-decompressed file can be obtained based on the to-be-decompressed queue".

2. The file processing method according to claim 1, characterized by, After the step of decompressing the sub-file in the to-be-decompressed file with the compression rate not greater than the preset compression rate threshold into the memory, the method further comprises: If the to-be-decompressed file is still stored in the memory after decompression, releasing the memory by storing the to-be-decompressed file into the disk, and writing the path identifier stored in the disk into the to-be-decompressed queue.

3. The file processing method according to claim 1, characterized by, After the step of obtaining the to-be-decompressed file, the method further comprises: Obtaining original file sizes of each sub-file in the to-be-decompressed file, and decompressing a sub-file with an original file size greater than a preset file size threshold into a disk; Calling the sub-file with the original file size greater than the preset file size threshold from the disk for detection.

4. The file processing method according to claim 2, characterized by, A method for judging whether a sub-file decompressed into a memory is a compressed file, comprising: Obtaining a file header of the sub-file after decompression into the memory; Judging a file type of the sub-file after decompression into the memory based on the file header.

5. The file processing method according to claim 1, characterized by, After the step of decompressing the sub-file in the to-be-decompressed file with the compression rate not greater than the preset compression rate threshold into the memory, the method further comprises: Detecting the sub-file with the compression rate not greater than the preset compression rate threshold by using a preset anti-virus software, and deleting the sub-file with the compression rate not greater than the preset compression rate threshold from the memory after detection.

6. The file processing method according to claim 1, characterized by, Before the step of returning to execute step S1, the method further comprises: When a decompression number of the to-be-decompressed file exceeds a preset decompression number threshold or when a decompression time of the to-be-decompressed file exceeds a preset decompression time threshold, interrupting decompression of the to-be-decompressed file, and storing the to-be-decompressed file into a disk; Calling the to-be-decompressed file from the disk for checking.

7. The file processing method according to claim 1, characterized by, After the step of "until no to-be-decompressed file can be obtained based on the to-be-decompressed queue", the method further comprises: Deleting the to-be-decompressed queue, and releasing a memory space occupied by the to-be-decompressed queue.

8. A file processing apparatus characterized by comprising: The file processing device comprises: A file obtaining module configured to obtain a to-be-decompressed file based on a to-be-decompressed queue; wherein the to-be-decompressed queue stores path identifiers of each to-be-decompressed file; A first decompression module configured to decompress a sub-file in the to-be-decompressed file with a compression rate not greater than a preset compression rate threshold into a memory, so as to facilitate subsequent file detection on the uncompressed sub-file in the memory; A second decompression module is configured to decompress the sub-file with the compression rate greater than the preset compression rate threshold in the to-be-decompressed file to the disk, and re-write the path of the sub-file still compressed after decompression to the to-be-decompressed queue, and return to execute the step of the first decompression module until "based on the to-be-decompressed queue, the to-be-decompressed file cannot be obtained".

9. An electronic device, comprising: Comprise: a processor; and a memory having stored thereon executable code that, when executed by the processor, causes the processor to perform the method of any one of claims 1-7. 10.A computer-readable storage medium having stored thereon executable code that, when executed by a processor of an electronic device, causes the processor to perform the method of any one of claims 1-7.

Citation Information

Patent Citations

  • Method, device and server for compressing text data

    CN104021121A

  • Multi-layer decompression method of compressed file, electronic equipment and storage medium

    CN112214462A