Compressed file hash value calculation method and device, compressed file comparison method and device, equipment and medium

Abstract

The invention discloses a compressed file hash value calculation method and device, a compressed file comparison method and device, equipment and a medium, and relates to the technical field of computers.The compressed file hash value calculation method comprises the steps that a target compressed file is obtained, and a temporary directory is created; decompressing the target compressed file to a temporary directory; traversing the file objects in the temporary directory, and executing the following steps on each file object: generating a first hash element based on a relative path of the file object, and adding the first hash element into a preset data structure; generating a second hash element based on the file type of the file object, and adding the second hash element into a preset data structure; traversing all Hash elements in the preset data structure and splicing the Hash elements to obtain an integrated data block; and performing hash operation on the integrated data block to obtain a target hash value of the target compressed file. According to the scheme, the problem that the Hash values of compressed files with the same content are inconsistent due to the fact that an existing method is influenced by factors except the file content is solved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for calculating the hash value of compressed files, a method for comparing compressed files, an apparatus, a device, and a medium. Background Technology

[0002] Currently, to compare the content of two compressed files, the common method is to calculate and compare their hash values. However, in practical applications, even when compressing files with identical content, the resulting hash values ​​often differ. This difference mainly stems from the fact that the binary data of compressed files is affected by various factors unrelated to the content, including the choice of compression algorithm, parameter settings (such as compression level), software version differences, packaging format (such as zip / rar / tar), and internal metadata (such as file modification time, permission information, and file order). These factors cause a collection of files with the same content to generate compressed files with vastly different binary structures after being packaged through different processing procedures, making the verification results of traditional hash methods unreliable.

[0003] Traditional methods for calculating the hash value of compressed files directly calculate the hash value of the binary stream containing metadata and compression format information. This fails to effectively eliminate interference from factors unrelated to the file content, ultimately resulting in compressed files with the same content receiving different hash values. Therefore, providing a hash value calculation method that accurately reflects the actual content of a compressed file has become a pressing technical problem to be solved in this field. Summary of the Invention

[0004] This invention provides a method for calculating the hash value of compressed files, a method for comparing compressed files, an apparatus, a device, and a medium to solve the problem that existing methods for calculating the hash value of compressed files are easily affected by factors other than the file content, resulting in differences in the hash values ​​calculated for compressed files with the same content.

[0005] Firstly, a method for calculating the hash value of compressed files is provided, including: Obtain the target compressed file and create a temporary directory for the target compressed file; Decompress the target compressed file to the temporary directory; Traverse the file objects in the temporary directory and perform the following steps for each file object: generate a first hash element based on the relative path of the file object and add the first hash element to a preset data structure; generate a second hash element based on the file type of the file object and add the second hash element to the preset data structure; Traverse all hash elements in the preset data structure and concatenate them to obtain an integrated data block; A hash operation is performed on the integrated data block to obtain the target hash value of the target compressed file.

[0006] Secondly, a method for comparing compressed files is provided, including: Obtain the first compressed file and the second compressed file; For the first compressed file, the hash value calculation method for compressed files described in the first aspect above is applied to calculate the corresponding first hash value; For the second compressed file, the hash value calculation method for compressed files described in the first aspect above is applied to calculate the corresponding second hash value; Based on the first hash value and the second hash value, determine whether the first compressed file and the second compressed file are the same.

[0007] Thirdly, a device for calculating the hash value of compressed files is provided, comprising: The first acquisition module is used to acquire the target compressed file and create a temporary directory for the target compressed file; The decompression module is used to decompress the target compressed file to the temporary directory; A generation module is used to traverse the file objects in the temporary directory and perform the following steps for each file object: generate a first hash element based on the relative path of the file object, and add the first hash element to a preset data structure; generate a second hash element based on the file type of the file object, and add the second hash element to the preset data structure; The splicing module is used to traverse all hash elements in the preset data structure and splice them to obtain an integrated data block. The calculation module is used to perform hash calculations on the integrated data blocks to obtain the target hash value of the target compressed file.

[0008] Fourthly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for calculating the hash value of a compressed file, or the computer program, when executed by the processor, implements the steps of the above-described method for comparing compressed files.

[0009] Fifthly, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the hash value calculation method for compressed files as described above, or, when executed by a processor, implements the steps of the compressed file comparison method as described above.

[0010] The beneficial effects of the technical solution provided by this invention are as follows: First, by acquiring the target compressed file and creating a temporary directory, and then decompressing the target compressed file to the temporary directory, the encapsulation differences brought about by the compression format itself can be eliminated, ensuring that the objects of subsequent operations are the original file objects within the compressed file, effectively avoiding initial interference from factors unrelated to the content, such as compression algorithms, parameters, and packaging formats. Next, for each file object in the temporary directory, a first hash element is generated based on the relative path and added to a preset data structure, and a second hash element is generated based on the file type and added to the preset data structure. By traversing all hash elements in the preset data structure and concatenating them, an integrated data block is obtained. Then, a hash operation is performed on the integrated data block based on the first preset hash algorithm to obtain the target hash value of the target compressed file. This ensures that the hash value calculation result is only related to the path and type of the file objects within the compressed file, achieving a consistent hash value for compressed files with the same content regardless of how the compression process changes. This effectively solves the problem that existing methods for calculating hash values ​​of compressed files are easily affected by factors other than the file content, leading to differences in the hash values ​​calculated for compressed files with the same content. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For users of ordinary skills in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for a method for calculating the hash value of a compressed file according to an embodiment of the present invention; Figure 2 This is a flowchart of a method for calculating the hash value of a compressed file according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a compressed file comparison method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a hash value calculation device for compressed files according to an embodiment of the present invention; Figure 5 This is a schematic diagram of a compressed file comparison device according to an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by users of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0014] The hash value calculation method for compressed files provided in this embodiment of the invention can be applied to, for example... Figure 1 The application environment is shown. Specifically, the hash value calculation method for compressed files is applied in a hash value calculation system for compressed files, which includes, for example, […]. Figure 1 The client and server shown communicate over a network to implement the steps of the hash value calculation method for compressed files.

[0015] The client, also known as the user terminal, refers to the program that provides local services to the client, corresponding to the server. Clients can include, but are not limited to, various personal computers, laptops, smartphones, and tablets. The server can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0016] like Figure 2 As shown, in one embodiment, a method for calculating the hash value of a compressed file is provided, which is applied to applications such as... Figure 1 The following steps are used as an example of the server shown: S101: Obtain the target compressed file and create a temporary directory for the target compressed file; S102: Decompress the target compressed file to a temporary directory.

[0017] As an example, the target compressed file refers to any compressed file whose content consistency needs to be hashed. Its format may include, but is not limited to, zip, rar, tar or 7z, etc., and is not limited here.

[0018] A temporary directory is an intermediate directory with a unique identifier that is dynamically created during the execution of file content parsing or hash calculation to store the decompressed contents of the target compressed file. This temporary directory is deleted after use to avoid polluting the system file structure and to ensure the independence of the processing.

[0019] In one feasible approach, the target compressed file for which the hash value is to be calculated is first obtained, and a temporary directory is created for the target compressed file. Then, the target compressed file is decompressed to this temporary directory, allowing all file objects and directory structures within the target compressed file to be accessed, traversed, and processed one by one within the physical file system. This avoids the uncertainties introduced by directly performing hash calculations on the binary structure of the compressed file, such as differences in compression algorithms, compression parameters, and software versions.

[0020] For example, consider a target compressed file named "project_xx.zip". This file might have been generated by different engineers using different compression software, but its internal file content would be identical. During processing, a unique temporary directory, such as " / tmp / tmp_xxxxx / ", is first created for this file. Then, "project_xx.zip" is completely decompressed into this temporary directory, resulting in a file structure identical to that before compression, including actual file objects like "src / main.c" and "config / settings.json". Because the decompressed content is independent of the compression algorithm, even if another engineer uses WinRAR to generate "project_xx_new.zip", the decompression will still yield the same directory structure and file content, and subsequent content hash calculations will also be completely consistent, ensuring the reliability of the compressed file content consistency judgment.

[0021] S103: Traverse the file objects in the temporary directory and perform the following steps for each file object: a. Based on the relative path of the file object, generate the first hash element and add the first hash element to a preset data structure; b. Based on the file type of the file object, generate a second hash element and add the second hash element to the preset data structure.

[0022] As an example, a file object refers to any file entity that can be recognized and accessed by the system after being decompressed to a temporary directory. This can include, but is not limited to, regular files, symbolic links, and compressed files that can be further decompressed (i.e., nested compressed files), etc., without any limitation here.

[0023] Among them, a regular file is a file object that stores actual data content and is not a nested compressed file or a symbolic link; a nested compressed file is a file object with a compressed format contained within a target compressed file; a symbolic link is a special file object whose content is a path string pointing to another file or directory, rather than actual data.

[0024] A relative path refers to the path of a file object within a temporary directory, excluding the prefix of the temporary directory itself, and is used to indicate the structural location of the file within the target archive.

[0025] The first hash element refers to the path hash element generated based on the relative path of each file object, which is used to reflect the path information of each file object within the target compressed package in the final hash.

[0026] The second hash element refers to the content-class hash element generated based on the actual type of each file object (regular file, nested compressed file, or symbolic link), used to reflect the content or equivalent attributes of each file object itself in the final hash.

[0027] In one feasible approach, after decompressing the target compressed file, all file objects appearing in the temporary directory are traversed, and steps ab are executed for each file object. Specifically, for each file object, a first hash element is generated based on its corresponding relative path and added to a predefined data structure. A second hash element is generated based on its corresponding file type and added to the same predefined data structure. In this way, two independent yet interconnected hash elements are generated for each file object within the target compressed package: a first hash element (path hash) accurately representing its logical location and a second hash element (content hash) precisely reflecting its content essence. By incorporating both types of elements into the same predefined data structure, a complete, comprehensive, and standardized set of digital fingerprints describing the entire content and structure of the target compressed package is constructed.

[0028] S104: Traverse all hash elements in the preset data structure and concatenate them to obtain the integrated data block.

[0029] As an example, the preset data structure in this step is used to centrally store all the generated first and second hash elements. Its specific implementation is not limited; it can be a regular container without automatic sorting (such as a list or array), or a data structure with automatic sorting capabilities (such as sorting by the first letter of the hash elements).

[0030] The preset data structure can include, but is not limited to, a priority queue, a balanced tree structure, or a list sorted lexicographically. The purpose is to ensure that the order of hash elements is independent of the file traversal order, thereby guaranteeing the stability of the final hash result. The priority queue can be configured to automatically maintain the lexicographical order of its stored hash elements.

[0031] It should be understood that if the default data structure does not have automatic sorting capabilities, an external sorting algorithm (such as quicksort) must be called to sort all hash elements before traversal and concatenation to obtain a definite sequence of elements. Regardless of whether automatic or external sorting is used, the core purpose is to ensure that all hash elements are arranged according to a unified and definite rule (such as lexicographical order).

[0032] A data block integration refers to taking all hash elements from a pre-sorted data structure, extracting them in their order, and concatenating their string representations to form a complete and continuous data string.

[0033] In one feasible approach, after the hash elements of all file objects have been generated and stored in a predefined data structure, the elements within the data structure are first ensured to be sorted. Subsequently, these sorted hash elements are traversed sequentially and concatenated together in order to ultimately form an integrated data block representing the content and structural characteristics of the entire target compressed package.

[0034] Because this process forces all hash elements to be sorted according to a predetermined rule (such as lexicographical order) before concatenation, the resulting integrated data block possesses high stability and determinism. It is completely unaffected by the original file packaging order, differences in file system traversal, uncertainties in multi-threaded execution, or differences in the runtime environment. As long as the content and path structure of the files within the compressed package are consistent, their sorted hash element sequence will inevitably be identical, resulting in completely consistent integrated data blocks. This provides a unique and reliable input for the next step of calculating the final stable hash value, fundamentally guaranteeing the reproducibility and consistency of the hash calculation results. This is key to achieving reliable content comparison across environments and tools using this method.

[0035] For example, suppose the sorted hash element sequence is: "PATH2A1F…", "FILE8C9D…", "PATH3B77…", "RECU55AA…". Concatenating them in this order will result in the string: "PATH2A1F…FILE8C9D…PATH3B77…RECU55AA…".

[0036] S105: Perform a hash operation on the integrated data blocks to obtain the target hash value of the target compressed file.

[0037] As an example, hashing refers to the process of performing a one-way hash algorithm on input data. It can use SHA256, SM3, xxHash, MD5 or other hash algorithms that are collision-resistant and tamper-resistant. There is no limitation here. It is used to map data of arbitrary length to a hash value of fixed length.

[0038] The target hash value is the final calculation result of this invention. It is a fixed-length hash value obtained by performing a hash operation on the integrated data block. It is used to uniquely represent the internal content of the target compressed file and does not depend on the external binary form of the compressed file.

[0039] In one feasible approach, after generating the integrated data block, a hash operation is directly performed on the integrated data block to obtain the target hash value of the target compressed file. Since the integrated data block is constructed entirely according to file path and content information, and the influence of external factors such as compression software version, compression parameters, and operating system file traversal order is eliminated, hashing it can generate a stable and content-consistent identifier independent of the compression method. This effectively solves the problem that existing methods for calculating hash values ​​of compressed files are easily affected by factors other than file content, leading to differences in hash values ​​calculated for compressed files with the same content.

[0040] For example, suppose the integrated data block obtained in the previous step is a long string "PATH2A1F…FILE8C9D…RECU55AA…". Using this integrated data block as input to a hash algorithm (such as SHA256), the algorithm will output a fixed-length hash value, such as "91F3A8C2…E7B1F4". This value is the target hash value of the target compressed file, used to uniquely represent its internal content. If another user regenerates a compressed package on a different computer using a different compression tool (such as 7zip), as long as the directory structure and file content are completely identical, the resulting integrated data block after decompression will also be the same. After hashing, the same target hash value will still be obtained, thus achieving stable determination of content consistency under different compression methods.

[0041] In summary, the beneficial effects of the technical solution provided by this invention are as follows: First, by acquiring the target compressed file and creating a temporary directory, and then decompressing the target compressed file to the temporary directory, the encapsulation differences brought about by the compression format itself can be eliminated, ensuring that the objects of subsequent operations are the original file objects within the compressed file, effectively avoiding initial interference from factors unrelated to the content, such as compression algorithms, parameters, and packaging formats. Next, for each file object in the temporary directory, a first hash element is generated based on the relative path and added to a preset data structure, and a second hash element is generated based on the file type and added to the preset data structure. By traversing all hash elements in the preset data structure and concatenating them, an integrated data block is obtained. Then, a hash operation is performed on the integrated data block based on the first preset hash algorithm to obtain the target hash value of the target compressed file. This ensures that the hash value calculation result is only related to the path and type of the file objects within the compressed file, achieving a consistent hash value for compressed files with the same content regardless of how the compression process changes. This effectively solves the problem that existing methods for calculating hash values ​​of compressed files are easily affected by factors other than the file content, leading to differences in the hash values ​​calculated for compressed files with the same content.

[0042] In one embodiment, specifically step S101, which involves obtaining the target compressed file and creating a temporary directory for it, the following steps are included: S111: Get the nesting depth value. The nesting depth value represents the number of compressed files that are decompressed layer by layer from the target compressed file to the lowest nested compressed file. S112: If the nesting depth value is greater than or equal to the preset nesting depth threshold, an error will be reported and the processing will be terminated; S113: If the nesting depth value is less than the preset nesting depth threshold, a temporary directory is created for the target compressed file.

[0043] As an example, the nesting depth value represents the number of compressed files encountered when decompressing from the target compressed file, layer by layer, until the lowest nested compressed file. For example, suppose the target compressed file "A.zip" has the following internal structure: "A.zip" contains "B.rar", "B.rar" contains "C.tar.gz", and "C.tar.gz" contains only regular files. In this nested structure, starting from "A.zip" (the beginning), decompressing layer by layer until the lowest "C.tar.gz", the compressed files encountered are "A.zip", "B.rar", and "C.tar.gz" in sequence. Therefore, the number of compressed files is 3, i.e., the nesting depth value is 3.

[0044] In one feasible approach, after obtaining the target compressed file, its corresponding nesting depth value is first determined (e.g., a nesting depth value of 3). Next, the nesting depth value is compared to a preset nesting depth threshold. If the nesting depth value is greater than or equal to the preset nesting depth threshold, an error is reported and processing terminates. For example, if the preset nesting depth threshold is 2, since 3 is greater than 2, an error will be reported and processing terminated directly, thus preventing unlimited decompression of excessively nested compressed structures. The order of reporting errors and terminating processing is not limited; that is, errors can be reported first and then processing terminated, or processing can be terminated first and then errors reported. This does not constitute a limitation of the invention. If the nesting depth value is less than the preset nesting depth threshold, a temporary directory is created for the target compressed file. For example, if the preset nesting depth threshold is 5, since 3 is less than 5, a temporary directory will be created for "A.zip" and subsequent calculations will continue.

[0045] As can be seen, by limiting the nesting depth of the target compressed file at the beginning of the processing, this embodiment not only effectively prevents the system risks that may be caused by infinite recursive decompression, but also ensures that the system can maintain stable operation even in the face of malicious construction or abnormally complex compression structures. Furthermore, it ensures that subsequent steps can be reliably executed within a controllable range, thereby improving the security and stability of the entire content consistency hash calculation process.

[0046] In one embodiment, specifically in sub-step a of step S103, that is, in generating the first hash element based on the relative path of the file object, the following steps are included: a1. Get the full path of the file object; a2. Remove the part of the path corresponding to the temporary directory from the complete path to obtain the relative path; a3. Generate the first hash element based on the relative path and the first preset prefix.

[0047] As an example, a full path refers to the path from the root directory (i.e., the temporary directory) to the file object after it has been decompressed, such as " / tmp / tmp_123 / foo / bar.txt". A relative path is the path obtained by removing the prefix corresponding to the temporary directory (e.g., " / tmp / tmp_123 / ") from the full path, i.e., "foo / bar.txt".

[0048] The first preset prefix is ​​a predefined, fixed-length string identifier (e.g., "PATH"), which is used to explicitly identify the type of the final hash element as path information to avoid confusion with other types of hash elements (such as content hash elements).

[0049] In one feasible approach, by obtaining the complete path of the file object and removing the path portion corresponding to the temporary directory from the complete path, a relative path is obtained. Based on the relative path and a first preset prefix, a first hash element is generated. This fundamentally ensures that different decompression environments (such as different temporary directory paths or names) will not have any impact on the final hash calculation result, thereby ensuring the stability of the hash calculation and the uniqueness of the compressed package content structure characteristics. This allows the same target compressed package to calculate a unique and consistent identifying hash value in any compliant system.

[0050] The process of generating the first hash element based on the relative path and the first preset prefix is ​​not limited. That is, the relative path can be hashed independently to obtain its hash value, and then the first preset prefix can be concatenated with the hash value to obtain the first hash element (format: prefix + hash value); the first preset prefix can be concatenated with the relative path to obtain a combined string, and then the combined string can be hashed, with the result being the first hash element; the first preset prefix, a predefined separator (such as a colon ":") and the relative path can be concatenated in order, and then the concatenated complete string can be hashed, with the result being the first hash element; the first preset prefix and the relative path can be hashed independently to obtain two independent intermediate hash values, and then these two intermediate hash values ​​can be mixed according to a predetermined rule (such as string concatenation, byte XOR or rehashing), with the mixed result being the first hash element; none of the above implementation methods are limited.

[0051] The following examples illustrate in detail the process of generating the first hash element based on the relative path and the first preset prefix, namely, one implementation method corresponding to steps a31a-a32a and another implementation method corresponding to steps a31b-a32b, which are not limited here.

[0052] In one embodiment, specifically in step a31, which involves generating the first hash element based on the relative path and the first preset prefix, the following steps are included: a31a. Add the first preset prefix to the relative path to obtain the combined relative path; a32a. Based on the first preset hash algorithm, calculate the first path hash value corresponding to the combined relative path, and use it as the first hash element.

[0053] As an example, the first preset prefix can be added to the beginning of a relative path or to the end of a relative path, without limitation. It should be understood that the prefix here is merely a noun designation and is not limited to being added only to the beginning, nor does it constitute a limitation on the present invention.

[0054] In one feasible approach, a first preset prefix can be added to the front of the relative path to construct a combined relative path that can simultaneously reflect the path semantics and path category identifier. Subsequently, a hash operation is performed on the combined relative path according to a first preset hash algorithm (such as SHA256, SM3, xxHash, or MD5) to obtain a stable and irreversible first path hash value (or first path hash string), and the first path hash value is used as the first hash element.

[0055] For example, adding the first preset prefix "PATH" to the beginning of the relative path results in the combined relative path "PATHdocs / readme.txt". The SHA-256 algorithm is then used to hash the combined relative path "PATHdocs / readme.txt", yielding a first path hash value of "e3b0c44...". This first path hash value is the first hash element.

[0056] In one embodiment, specifically in step a31, which involves generating the first hash element based on the relative path and the first preset prefix, the following steps are included: a31b. Based on the first preset hash algorithm, calculate the hash value of the second path corresponding to the relative path; a32b. Concatenate the second path hash value with the first preset prefix to generate the first hash element.

[0057] In another feasible approach, firstly, a first preset hash algorithm (such as SHA256, SM3, xxHash, or MD5) can be selected to hash the extracted relative path, resulting in a fixed-length, irreversible second path hash value (or second path hash string). Subsequently, the first preset prefix is ​​concatenated with the second path hash value (for example, placing the first preset prefix before the second path hash value) to generate the first hash element.

[0058] Although the "hash first, then concatenate" method differs from the aforementioned "concatenate first, then hash" method in the order of steps, both achieve the core function of transforming the original path information into a standardized hash element that is independent of the decompression environment and carries a type identifier.

[0059] For example, following the previous example, suppose the relative path of a file object is "docs / readme.txt". Using the SHA-256 algorithm, hash the string "docs / readme.txt" to obtain a second path hash value, such as "9f86d081884c7d659a2feaa0c55ad015...". Concatenate the first preset prefix PATH with this second path hash value string (taking the prefix first as an example) to generate the first hash element: "PATH9f86d081884c7d659a2feaa0c55ad015...".

[0060] In one embodiment, specifically in sub-step b of step S103, that is, calculating the second hash element based on the file type of the file object, the following steps are included: b1. If the file type is a nested compressed file, the hash value calculation method is applied to calculate the hash value of the nested compressed file; the hash value of the compressed file is concatenated with the second preset prefix to generate the second hash element; b2. If the file type is a symbolic link, determine the symbolic link string corresponding to the symbolic link; generate the second hash element based on the symbolic link string and the third preset prefix; b3. If the file type is a regular file, determine the file content corresponding to the regular file; based on the file content and the fourth preset prefix, generate the second hash element.

[0061] As an example, a nested compressed file is a file object with a compressed format contained within a target compressed file; a regular file is a file object that stores actual data content and whose file type is neither a nested compressed file nor a symbolic link; a symbolic link is a special file object whose content is a path string pointing to another file or directory, rather than actual data.

[0062] The second, third, and fourth preset prefixes are similar to the first preset prefix; that is, they are all predefined, fixed-length string identifiers (e.g., RECU, LINK, and FILE, respectively). Their core function is to clearly identify the data source type of the element in the final generated second hash element, thereby clearly distinguishing it from path hash elements (first hash elements) and other types of content hash elements during subsequent integration. This effectively avoids confusion and conflict caused by the accidental similarity of hash values ​​for different types of data.

[0063] In another possible implementation, different strategies are used to generate the second hash element based on the identified file type of the file object. Specifically: if the file type of the file object is identified as a nested compressed file, the hash value calculation method for this compressed file is recursively called (i.e., steps S101-S105 are recursively executed) to obtain the hash value of the compressed file corresponding to the nested compressed file; then, the compressed file hash value is concatenated with a second preset prefix (e.g., RECU) to obtain the second hash element. If the file type of the file object is identified as a symbolic link, its stored target path is read as the symbolic link string, and the second hash element is generated based on the symbolic link string and a third preset prefix (e.g., "LINK"). If the file type of the file object is identified as a regular file, all its byte data is read as the file content, and the second hash element is generated based on the file content and a fourth preset prefix.

[0064] This type-based standardization process accurately and unambiguously captures the essential attributes of various file objects within a compressed archive—whether it's a complex, recursively nested structure, the pointing relationships of symbolic links, or the actual data of ordinary files. Furthermore, the unique prefixes (RECU, LINK, FILE) corresponding to different types play a crucial role in identifying the type in the final generated hash elements. This fundamentally eliminates the risk of element confusion or hash collisions caused by different data types (such as the recursive hash value of a nested compressed archive being identical to the content hash value of a regular file), thus significantly improving the robustness, uniqueness, and reliability of the entire calculation scheme.

[0065] The specific process of generating the second hash element based on the symbolic link string and the third preset prefix, as well as the specific process of generating the second hash element based on the file content and the fourth preset prefix, are not limited. For details, please refer to the description of the implementation process of generating the first hash element based on the relative path and the first preset prefix in sub-step a of step S103. To avoid repetition, it will not be repeated here.

[0066] The following examples illustrate in detail the process of generating the second hash element based on the symbolic link string and the third preset prefix, namely, one implementation method corresponding to steps b21a-b22a and another implementation method corresponding to steps b21b-b22b, which are not limited here.

[0067] In one embodiment, specifically in step b2, which involves generating the second hash element based on the symbolic link string and the third preset prefix, the following steps are included: b21a: Add the third preset prefix to the symbolic link string to obtain the combined symbolic link string; b22a: Based on the second preset hash algorithm, calculate the hash value of the first soft link corresponding to the combined path string, and use it as the second hash element.

[0068] As an example, the third preset prefix can be added to the beginning or the end of the symbolic link string; there is no limitation here. It should be understood that the prefix here is merely a noun representation, and its core function is to inject a clear link type identifier into the original data to distinguish it from other types of data such as paths and file content.

[0069] A combined symbolic link string is a new string formed by concatenating a third preset prefix with the symbolic link string in sequence.

[0070] The second preset hash algorithm can be any of the cryptographic hash algorithms such as SHA256, SM3, xxHash, or MD5, and is not limited here.

[0071] In one feasible approach, a third preset prefix (e.g., LINK) is first added to the front of the symbolic link string to obtain a combined symbolic link string; then, according to a second preset hash algorithm, the combined symbolic link string is hashed to obtain a stable and irreversible first symbolic link hash value (or first symbolic link hash string), and this first symbolic link hash value is used as the second hash element.

[0072] For example, suppose the target path (symbolic link string) of a symbolic link is " / usr / local / bin / myapp". Adding the third predefined prefix LINK to the beginning of this string results in the combined symbolic link string "LINK / usr / local / bin / myapp". Using the SHA-256 algorithm to hash the string "LINK / usr / local / bin / myapp", let's assume the first symbolic link hash value is "c3d4e55f...". This first symbolic link hash value is the second hash element.

[0073] In one embodiment, specifically step b2, which involves generating the second hash element based on the symbolic link string and the third preset prefix, the following steps are also included: b21b: Calculate the second soft link hash value corresponding to the soft link string based on the second preset hash algorithm; b22b: Concatenate the hash value of the second soft link with the third preset prefix to generate the second hash element.

[0074] In another feasible approach, firstly, a second preset hash algorithm (e.g., SHA256) can be used to hash the extracted symbolic link string itself, resulting in a fixed-length, irreversible second symbolic link hash value. Then, a third preset prefix is ​​concatenated with this second symbolic link hash value string (e.g., placing the third preset prefix before the hash value) to generate a second hash element.

[0075] Although the "hash first, then concatenate" method differs from the aforementioned "concatenate first, then hash" method in the order of steps, both achieve the core function of transforming the essential information of a soft link (the target path it points to) into a standardized hash element that is independent of the processing environment and carries a clear type identifier.

[0076] For example, following the previous example, the symbolic link string is " / usr / local / bin / myapp". The SHA-256 algorithm is used to directly hash this symbolic link string, resulting in a second symbolic link hash value, such as "a5b6c798...". The third preset prefix "LINK" is then concatenated with this second symbolic link hash value (taking the prefix first as an example), generating a second hash element as "LINKa5b6c798...".

[0077] The following examples illustrate in detail the process of generating the second hash element based on the file content and the fourth preset prefix, namely, one implementation method corresponding to steps b31a-b32a and another implementation method corresponding to steps b31b-b32b, which are not limited here.

[0078] In one embodiment, specifically step b3, which involves generating the second hash element based on the file content and the fourth preset prefix, the following steps are included: b31a: Adds the fourth preset prefix to the file content to obtain combined file data; b32a: Based on the third preset hash algorithm, calculate the first content hash value corresponding to the combined file data, and use it as the second hash element; As an example, the fourth preset prefix can be combined with the byte stream of the file content. This combination can be achieved by appending the prefix's byte representation before or after the content byte stream, or by concatenating it with a standard encoded string of the file content; no specific limitations are imposed here. Its core function is to inject a clear file content type identifier into the original file content byte stream.

[0079] Combined file data refers to the byte sequence or string formed by combining the fourth preset prefix with the file content according to predetermined rules.

[0080] The third preset hash algorithm can be any of the cryptographic hash algorithms such as SHA256, SM3, xxHash, or MD5, and is not limited here.

[0081] In one feasible approach, firstly, the byte representation of a fourth preset prefix (e.g., FILE) is combined with the original byte stream of the file content in a predetermined order to form combined file data; then, the combined file data is hashed according to a selected third preset hash algorithm to obtain a stable, irreversible first content hash value (or first content hash string), and this first content hash value is used as a second hash element representing the regular file content.

[0082] For example, suppose a regular file contains the byte stream of the text string "HelloWorld!". Adding the fourth predefined prefix "FILE" before this byte stream yields combined file data. Using the SHA-256 algorithm, this combined file data is calculated, and let's assume the first content hash value is "e6f8d92b...". This first content hash value is the second hash element corresponding to the regular file.

[0083] In one embodiment, specifically step b3, which involves generating the second hash element based on the file content and the fourth preset prefix, the following steps are also included: b31b: Calculates the second content hash value corresponding to the file content based on the third preset hash algorithm; b32b: Concatenate the second content hash value with the fourth preset prefix to generate the second hash element.

[0084] In another possible approach, firstly, a third preset hash algorithm (e.g., SHA256) can be used to hash the file content itself, resulting in a second content hash value (or second content hash string). Then, a fourth preset prefix is ​​concatenated with this second content hash value (e.g., placing the fourth preset prefix before the hash value) to generate a second hash element.

[0085] This "hash first, then concatenate" method can also generate a file content hash element with a clear type identifier. Its core effect is consistent with the aforementioned methods: it allows hash elements of regular files to be clearly distinguished from hash elements of symbolic links, paths, or nested compressed files in the final set by their prefixes.

[0086] For example, following the previous example, the file with the content "HelloWorld!" is directly subjected to SHA-256 calculation to obtain the second content hash value, such as "dffd6021...". The fourth preset prefix "FILE" is concatenated with the second content hash value to generate the second hash element "FILEdffd6021...".

[0087] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0088] like Figure 3 As shown, in one embodiment, a method for comparing compressed files is provided, and this method is also applied to applications such as... Figure 1 The following steps are used as an example of the server shown: S201: Obtain the first compressed file and the second compressed file; S202: For the first compressed file, the hash value calculation method for compressed files described in the first aspect above is applied to calculate the corresponding first hash value; S203: For the second compressed file, the hash value calculation method for compressed files described in the first aspect above is applied to calculate the corresponding second hash value; S204: Determine whether the first compressed file and the second compressed file are the same based on the first hash value and the second hash value.

[0089] In one feasible approach, after obtaining the first and second compressed files to be compared, the server independently and completely executes the hash value calculation method for compressed files provided in the first aspect of this invention (i.e., including all steps and sub-steps from S101 to S105) for each file, thereby calculating a stable hash value for the first compressed file that depends only on its internal content and structure, denoted as the first hash value; similarly, it calculates the corresponding stable hash value for the second compressed file, denoted as the second hash value. Subsequently, the calculated first hash value and the second hash value are compared. If they are completely identical, the first and second compressed files are determined to be completely identical at the content level (including file sets, path structures, and the actual data of each file); if they are different, the contents of the two compressed files are determined to be different. Because the hash value generated by this calculation method is stable, it effectively eliminates interference from non-content factors such as compression algorithms, software versions, packaging order, and metadata. As long as the internal file content and directory structure are consistent, the calculated hash value remains the same, thereby achieving consistency determination of the compressed file content and significantly improving the accuracy and reliability of file comparison across environments and tools.

[0090] As shown in Tables 1 and 2, to verify the technical effect of the present invention, it is assumed that there are two compressed files, bsp.zip and bsp2.zip, both of which contain 7 identical files, except that the gpt.conf file is in a different position in the list.

[0091] Table 1: bsp.zip Note: The bsp.zip compressed package in Table 1 contains a total of 7 files.

[0092] Table 2: bsp2.zip Note: The bsp2.zip compressed package in Table 2 contains a total of 7 files.

[0093] If the traditional method is used to directly calculate the hash value of the binary streams of two files, two different hash values ​​will be obtained due to the different packing order, thus incorrectly determining that the file contents are different (as shown in Table 3).

[0094] Applying the compressed file comparison method described in the second aspect of this invention, the hash values ​​corresponding to bsp.zip and bsp2.zip are calculated respectively (as shown in Table 4). Although these two files are generated in different ways and have different internal file storage orders, since they contain exactly the same actual file content, the two calculated hash values ​​will be completely identical. By comparing these two hash values, since they are the same, it is finally determined that bsp.zip and bsp2.zip are identical in content.

[0095] Table 3: Comparison of Traditional Binary Hash Values Note: Table 3 shows hash values ​​calculated using the "sha256sum*" command. The hash values ​​of bsp.zip and bsp2.zip differ primarily because their binary data streams differ (specifically, their internal file storage order is different). This difference prevents traditional hash algorithms from accurately determining the consistency of their contents.

[0096] Table 4: Comparison of Stable Hash Values ​​of the Invention Note: Table 4 shows stable hash values ​​calculated using the method described in the first aspect of this invention. This method focuses only on the internal file content and directory structure of the compressed file, ignoring non-content factors such as packaging order and compression algorithm version. Therefore, bsp.zip and bsp2.zip, which have the same content, obtain the same hash value, thus accurately determining that bsp.zip and bsp2.zip are identical in content.

[0097] In summary, the above are merely examples and do not constitute a limitation of the present invention. Furthermore, the compressed file comparison method provided by the second aspect of the present invention effectively avoids misjudgments caused by the traditional direct comparison of the binary hash values ​​of compressed files, fully demonstrating the practical value and technological advancement of the present invention in the comparison of the consistency of compressed file content.

[0098] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0099] It should be noted that the compressed file comparison method provided in the embodiments of the present invention can also be applied to, for example... Figure 1 The application environment shown. Specifically, this compressed file comparison method can be applied to a compressed file comparison system, which may also include, for example, […]. Figure 1 The client and server shown communicate over a network to implement the steps of the compressed file comparison method; this is just an example.

[0100] like Figure 4 As shown, in one embodiment, a hash value calculation device for compressed files is provided, which corresponds one-to-one with the hash value calculation method for compressed files in the above embodiments. The hash value calculation device for compressed files includes a first acquisition module 301, a decompression module 302, a generation module 303, a splicing module 304, and a calculation module 305. Detailed descriptions of each functional module are as follows: The first acquisition module 301 is used to acquire the target compressed file and create a temporary directory for the target compressed file; The decompression module 302 is used to decompress the target compressed file to the temporary directory; The generation module 303 is used to traverse the file objects in the temporary directory and perform the following steps for each file object: generate a first hash element based on the relative path of the file object and add the first hash element to a preset data structure; generate a second hash element based on the file type of the file object and add the second hash element to the preset data structure; The splicing module 304 is used to traverse all hash elements in the preset data structure and splice them to obtain an integrated data block. The calculation module 305 is used to perform a hash operation on the integrated data block to obtain the target hash value of the target compressed file.

[0101] In one embodiment, the first acquisition module 301 is further configured to: Obtain the nesting depth value, which represents the number of compressed files corresponding to the decompression process from the target compressed file inwards layer by layer to the lowest nested compressed file; If the nesting depth value is greater than or equal to the preset nesting depth threshold, an error will be reported and the process will be terminated. If the nesting depth value is less than the preset nesting depth threshold, a temporary directory is created for the target compressed file.

[0102] In one embodiment, the generation module 303 is further configured to: Get the full path of the file object; The relative path is obtained by removing the path portion corresponding to the temporary directory from the complete path; A first hash element is generated based on the relative path and the first preset prefix.

[0103] In one embodiment, the generation module 303 is further configured to: Add the first preset prefix to the relative path to obtain a combined relative path; Based on the first preset hash algorithm, the first path hash value corresponding to the combined relative path is calculated and used as the first hash element; or, Based on the first preset hash algorithm, calculate the second path hash value corresponding to the relative path; The second path hash value is concatenated with the first preset prefix to generate the first hash element.

[0104] In one embodiment, the generation module 303 is further configured to: If the file type is a nested compressed file, the hash value calculation method described above is applied to calculate the compressed file hash value of the nested compressed file; the compressed file hash value is concatenated with the second preset prefix to generate a second hash element; If the file type is a symbolic link, then determine the symbolic link string corresponding to the symbolic link; based on the symbolic link string and the third preset prefix, generate a second hash element; If the file type is a regular file, then determine the file content corresponding to the regular file; based on the file content and the fourth preset prefix, generate a second hash element; The nested compressed file is a file object with a compressed format contained within the target compressed file; the regular file is a file object that stores actual data content and whose file type is neither the nested compressed file nor the symbolic link.

[0105] In one embodiment, the generation module 303 is further configured to: Add the third preset prefix to the symbolic link string to obtain the combined symbolic link string; Based on the second preset hash algorithm, the hash value of the first soft link corresponding to the combined path string is calculated and used as the second hash element; or, Based on the second preset hash algorithm, calculate the second soft link hash value corresponding to the soft link string; The hash value of the second soft link is concatenated with the third preset prefix to generate the second hash element.

[0106] In one embodiment, the generation module 303 is further configured to: The fourth preset prefix is ​​added to the file content to obtain combined file data; Based on the third preset hash algorithm, the first content hash value corresponding to the combined file data is calculated and used as the second hash element; or, Based on the third preset hash algorithm, calculate the second content hash value corresponding to the file content; The second content hash value is concatenated with the fourth preset prefix to generate the second hash element.

[0107] In one embodiment, the preset data structure includes a priority queue configured to automatically maintain the hash elements it stores in lexicographical order.

[0108] Specific limitations regarding the hash value calculation device for compressed files can be found in the limitations on the hash value calculation method for compressed files mentioned above, and will not be repeated here. Each module in the aforementioned hash value calculation device for compressed files can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independent of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0109] Thirdly, a compressed file comparison device is also provided, which corresponds one-to-one with the compressed file comparison method in the above embodiments. For example... Figure 5 As shown, the hash value calculation device for the compressed file includes a second acquisition module 401, a first calculation module 402, a second calculation module 403, and a determination module 404. Detailed descriptions of each functional module are as follows: The second acquisition module 401 is used to acquire the first compressed file and the second compressed file; The first calculation module 402 is used to calculate the corresponding first hash value for the first compressed file by applying the hash value calculation method of the compressed file described in the first aspect above. The second calculation module 403 is used to calculate the corresponding second hash value for the second compressed file by applying the hash value calculation method of the compressed file described in the first aspect above. The determining module 404 is used to determine whether the first compressed file and the second compressed file are the same based on the first hash value and the second hash value.

[0110] Specific limitations regarding the compressed file comparison device can be found in the limitations of the compressed file comparison method described above, and will not be repeated here. Each module in the aforementioned compressed file comparison device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the corresponding operations of each module.

[0111] In one embodiment, an electronic device is provided, the internal structure of which can be shown as follows: Figure 6 As shown. The computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. When executed by the processor, the computer program implements the steps of the hash value calculation method for compressed files described above, or, when executed by the processor, implements the steps of the compressed file comparison method described above.

[0112] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the hash value calculation method for compressed files described in the above embodiments. For example, Figure 2 S101-S105, as shown, will not be repeated here to avoid repetition; alternatively, when the processor executes the computer program, it implements the steps of the compressed file comparison method in the above embodiments, for example, Figure 3 S201-S204, as shown, will not be described again here to avoid repetition. Alternatively, when the processor executes the computer program, it implements the functions of each module / unit in this embodiment of the electronic device, for example, Figure 2 The function of the hash value calculation method for the compressed file shown is not repeated here to avoid duplication; or, Figure 3 The functionality of the compressed file comparison method shown is not repeated here to avoid duplication.

[0113] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements the steps of the hash value calculation method for compressed files described in the above embodiments, for example... Figure 2 S101-S105, as shown, will not be repeated here to avoid repetition; or, when the computer program is executed by the processor, it implements the steps of the compressed file comparison method in the above embodiments, for example, Figure 3 S201-S204, as shown, will not be described again here to avoid repetition. Alternatively, when the computer program is executed by the processor, it implements the functions of each module / unit in this embodiment of the electronic device described above, for example, for example, Figure 2 The function of the hash value calculation method for the compressed file shown is not repeated here to avoid duplication; or, Figure 3 The functionality of the compressed file comparison method shown is not repeated here to avoid duplication. Computer-readable storage media can be non-volatile or volatile.

[0114] Users skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0115] Technical users in this field can clearly understand that, for the sake of convenience and brevity, the above-mentioned division of functional units and modules is used as an example. In actual applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0116] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, users of ordinary skills in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for calculating the hash value of a compressed file, characterized in that, include: Obtain the target compressed file and create a temporary directory for the target compressed file; Decompress the target compressed file to the temporary directory; Traverse the file objects in the temporary directory and perform the following steps for each file object: generate a first hash element based on the relative path of the file object, and add the first hash element to a preset data structure; Based on the file type of the file object, a second hash element is generated and added to the preset data structure; Traverse all hash elements in the preset data structure and concatenate them to obtain an integrated data block; A hash operation is performed on the integrated data block to obtain the target hash value of the target compressed file.

2. The method for calculating the hash value of a compressed file as described in claim 1, characterized in that, The step of obtaining the target compressed file and creating a temporary directory for the target compressed file includes: Obtain the nesting depth value, which represents the number of compressed files corresponding to the decompression process from the target compressed file inwards layer by layer to the lowest nested compressed file; If the nesting depth value is greater than or equal to the preset nesting depth threshold, an error will be reported and the process will be terminated. If the nesting depth value is less than the preset nesting depth threshold, a temporary directory is created for the target compressed file.

3. The method for calculating the hash value of a compressed file as described in claim 1, characterized in that, The step of generating the first hash element based on the relative path of the file object includes: Get the full path of the file object; The relative path is obtained by removing the path portion corresponding to the temporary directory from the complete path; A first hash element is generated based on the relative path and the first preset prefix.

4. The method for calculating the hash value of a compressed file as described in claim 3, characterized in that, The step of generating the first hash element based on the relative path and the first preset prefix includes: Add the first preset prefix to the relative path to obtain a combined relative path; Based on the first preset hash algorithm, the first path hash value corresponding to the combined relative path is calculated and used as the first hash element; or, Based on the first preset hash algorithm, calculate the second path hash value corresponding to the relative path; The second path hash value is concatenated with the first preset prefix to generate the first hash element.

5. The method for calculating the hash value of a compressed file as described in any one of claims 1-4, characterized in that, The calculation of the second hash element based on the file type of the file object includes: If the file type is a nested compressed file, the hash value calculation method described above is applied to calculate the compressed file hash value of the nested compressed file; the compressed file hash value is concatenated with the second preset prefix to generate a second hash element; If the file type is a symbolic link, then determine the symbolic link string corresponding to the symbolic link; based on the symbolic link string and the third preset prefix, generate a second hash element; If the file type is a regular file, then determine the file content corresponding to the regular file; based on the file content and the fourth preset prefix, generate a second hash element; The nested compressed file is a file object with a compressed format contained within the target compressed file; the regular file is a file object that stores actual data content and whose file type is neither the nested compressed file nor the symbolic link.

6. The method for calculating the hash value of a compressed file as described in claim 5, characterized in that, The step of generating a second hash element based on the symbolic link string and the third preset prefix includes: Add the third preset prefix to the symbolic link string to obtain the combined symbolic link string; Based on the second preset hash algorithm, the hash value of the first soft link corresponding to the combined path string is calculated and used as the second hash element; or, Based on the second preset hash algorithm, calculate the second soft link hash value corresponding to the soft link string; The hash value of the second soft link is concatenated with the third preset prefix to generate the second hash element.

7. The method for calculating the hash value of a compressed file as described in claim 5, characterized in that, The step of generating a second hash element based on the file content and a fourth preset prefix includes: The fourth preset prefix is ​​added to the file content to obtain combined file data; Based on the third preset hash algorithm, the first content hash value corresponding to the combined file data is calculated and used as the second hash element; or, Based on the third preset hash algorithm, calculate the second content hash value corresponding to the file content; The second content hash value is concatenated with the fourth preset prefix to generate the second hash element.

8. The method for calculating the hash value of a compressed file as described in claim 1, characterized in that, The preset data structure includes a priority queue, which is configured to automatically maintain the hash elements it stores in lexicographical order.

9. A method for comparing compressed files, characterized in that, include: Obtain the first compressed file and the second compressed file; For the first compressed file, the hash value calculation method for compressed files as described in any one of claims 1-8 is applied to calculate the corresponding first hash value; For the second compressed file, the hash value calculation method for compressed files as described in any one of claims 1-8 is applied to calculate the corresponding second hash value; Based on the first hash value and the second hash value, determine whether the first compressed file and the second compressed file are the same.

10. A device for calculating the hash value of a compressed file, characterized in that, include: The first acquisition module is used to acquire the target compressed file and create a temporary directory for the target compressed file; The decompression module is used to decompress the target compressed file to the temporary directory; The generation module is used to traverse the file objects in the temporary directory and perform the following steps for each file object: generate a first hash element based on the relative path of the file object, and add the first hash element to a preset data structure; Based on the file type of the file object, a second hash element is generated and added to the preset data structure; The splicing module is used to traverse all hash elements in the preset data structure and splice them to obtain an integrated data block. The calculation module is used to perform hash calculations on the integrated data blocks to obtain the target hash value of the target compressed file.

11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the hash value calculation method for compressed files as described in any one of claims 1-8; or, when the computer program is executed by the processor, it implements the steps of the compressed file comparison method as described in claim 9.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method for calculating the hash value of a compressed file as described in any one of claims 1-8, or, when the computer program is executed by the processor, it implements the steps of the method for comparing compressed files as described in claim 9.

Images