A compression method, a decompression method, an electronic device, and a storage medium
Patent Information
- Application Number
- CN202510474052.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-15
- Publication Date
- 2026-10-23
AI Technical Summary
但是,目前的解压缩方案耗时较长,影响用户体验
Smart Images

Figure CN122969579A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of electronic equipment technology, and in particular to a compression method, a decompression method, an electronic device, and a storage medium. Background Technology
[0002] Data compression can reduce the storage space required for data. With the rapid development of data compression technology, the deflate algorithm (a lossless data compression algorithm) has become a core compression solution in many fields due to its high compression ratio and wide compatibility. For example, it can be used to compress office documents (such as documents with .docx / .xlsx / .pptx extensions), compress data during image encoding and decoding, and compress application installation packages (such as application installation packages with .hap / .apk extensions). Files compressed using deflate can include ZIP and GZIP formats. Currently, developers can use data compression libraries (such as zlib-chromium library, intelligent storage acceleration library, etc.) to compress data. Data compression algorithms are obtained from libraries such as the Intelligent Storage Acceleration Library (ISA-L), Compression Library, and zlib-ng Library, and then integrated into electronic devices to enable data compression functionality in applications within those devices.
[0003] After compressing the data, it needs to be decompressed to obtain the original data. However, current decompression methods are time-consuming, impacting user experience. Summary of the Invention
[0004] To reduce the time required for decompression, embodiments of this application provide a compression method, a decompression method, an electronic device, and a storage medium.
[0005] In a first aspect, embodiments of this application provide a compression method for an electronic device. The method includes: obtaining first Huffman-coded data corresponding to first data in data to be encoded, and second Huffman-coded data corresponding to second data in data to be encoded, wherein the first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman-coded data and the second Huffman-coded data is less than or equal to a first length, and both the first data and the second data are characters, or one of the first data and the second data is a character and the other data is a length parameter, with the length parameter located after the character; concatenating the first Huffman-coded data and the second Huffman-coded data to obtain third Huffman-coded data, the length of the third Huffman-coded data being equal to the first length; constructing an index relationship between the third Huffman-coded data and the first data and the second data; and using the first Huffman-coded data, the second Huffman-coded data, and the index relationship as compressed data corresponding to the first data and the second data.
[0006] Based on the compression method provided in the embodiments of this application, an index can be constructed corresponding to one character and one length parameter, or an index can be constructed corresponding to two characters. In this way, during decoding, there may be cases where one character and one length parameter are decoded in one table lookup, or two characters are decoded in one table lookup. This can effectively reduce the number of table lookups during the decoding process and shorten the decoding time.
[0007] In one possible implementation of the first aspect, corresponding to the first data including a first character and the second data including a second character, constructing an index relationship between the third Huffman encoded data and the first and second data includes: constructing an index relationship between the third Huffman encoded data and the first entry in a first index table corresponding to the data to be encoded, wherein the first entry includes a first code length field, a first character field, a second character field, and a first character quantity identifier field. The first code length field includes information corresponding to the sum of the data length of the first Huffman encoded data and the data length of the second Huffman encoded data; the first character field includes information corresponding to the first character, the second character field includes information corresponding to the second character; and the first character quantity identifier field includes the quantity information of the characters in the first entry.
[0008] Based on the compression method provided in this application embodiment, an index can be constructed corresponding to two characters. In this way, during decoding, there is a situation where two characters can be decoded in one table lookup, which can effectively reduce the number of table lookups during the decoding process and shorten the decoding time.
[0009] In one possible implementation of the first aspect, the first code length field is stored in the corresponding positions of bits 0 through 7 in the first entry.
[0010] In some embodiments, the first code length field can be stored in the corresponding positions of bits 0 to 7 in the first entry. It can be understood that when the first code length field is stored in the lower 8 bits of the entry, during the decoding process, when reading and decoding the first code length field, the uxtb extension operation can be used directly to retrieve the value. That is, the lower 8 bits of the value can be extracted from the WO register using the sub w4,w4,w0,uxtb instruction, and the code length corresponding to the lower 8 bits of the value is subtracted from W4. Here, the WO register is used to store the original value read from the entry, and W4 can be used to store the remaining undecoded data. Subtracting the code length corresponding to the lower 8 bits of the value from W4 ensures that the remaining undecoded data in W4 will have a reduced code length corresponding to the lower 8 bits of the value.
[0011] Thus, compared to some implementation schemes where the code length field is stored in higher bits and requires additional instructions to extract the code length field to a temporary register through shifting operations before calculation, this method can achieve decoding efficiency without additional bit field operations and the use of temporary registers.
[0012] In one possible implementation of the first aspect, corresponding to the first data including a third character and the second data including a first length parameter, constructing an index relationship between the third Huffman encoded data and the first and second data includes: constructing an index relationship between the third Huffman encoded data and the second entry in a first index table corresponding to the data to be encoded, wherein the second entry includes a second code length field, a third character field, a first length field, and a second character quantity identifier field; the second code length field includes information corresponding to the sum of the data length of the first Huffman encoded data and the data length of the second Huffman encoded data; the third character field includes information corresponding to the third character; the first length field includes information corresponding to the first length parameter; and the second character quantity identifier field includes information on the number of characters in the second entry.
[0013] Based on the compression method provided in this application, an index can be constructed corresponding to a character and a length parameter. In this way, during decoding, a character and a length parameter can be decoded in one table lookup, which can effectively reduce the number of table lookups during the decoding process and shorten the decoding time.
[0014] Furthermore, in the embodiments of this application, the length field (such as the first length field and the second length field mentioned later) stores the actual length of the matching string, that is, the binary value corresponding to the actual length. In this way, there is no need to look up an extra table to obtain the extra number of bits and calculate the actual length, which can further reduce the use of extra bit field operations and temporary registers and improve decoding efficiency.
[0015] In one possible implementation of the first aspect, the second code length field is stored in the corresponding positions of bits 0 through 7 in the second entry.
[0016] In one possible implementation of the first aspect, concatenating the first Huffman-coded data and the second Huffman-coded data to obtain the third Huffman-coded data includes: if the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is less than a first length, merging the first Huffman-coded data and the second Huffman-coded data to obtain the fourth Huffman-coded data, and obtaining the third Huffman-coded data by extending the fourth Huffman-coded data; if the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is equal to the first length, merging the first Huffman-coded data and the second Huffman-coded data to obtain the third Huffman-coded data.
[0017] In one possible implementation of the first aspect, the method further includes: obtaining the fifth Huffman-coded data corresponding to the third data in the data to be encoded, wherein the third data is the fourth character; and constructing an index relationship between the fifth Huffman-coded data and the third data.
[0018] In one possible implementation of the first aspect, constructing the index relationship between the fifth Huffman-coded data and the third data includes: constructing the index relationship between the fifth Huffman-coded data and the third entry in the first index table corresponding to the data to be encoded, wherein the third entry includes a third code length field, a fourth character field, and a third character quantity identifier field; the third code length field includes the data length information of the fifth Huffman-coded data; the fourth character field includes the information corresponding to the fourth character; and the third character quantity identifier field includes the quantity information of the characters in the third entry.
[0019] In one possible implementation of the first aspect, the method further includes: obtaining the sixth Huffman-coded data corresponding to the fourth data in the data to be encoded, wherein the fourth data is the second length parameter, and constructing an index relationship between the sixth Huffman-coded data and the second length parameter.
[0020] In one possible implementation of the first aspect, constructing the index relationship between the sixth Huffman encoded data and the second length parameter includes: constructing the index relationship between the sixth Huffman encoded data and the fourth entry in the first index table corresponding to the data to be encoded, wherein the fourth entry includes a fourth code length field, a second length field, and a fourth character count identifier field; the fourth code length field includes the data length information of the sixth Huffman encoded data; the second length field includes the information corresponding to the second length parameter; and the fourth character count identifier field includes the number of characters in the fourth entry.
[0021] In one possible implementation of the first aspect, the method further includes:
[0022] Obtain the seventh Huffman-coded data corresponding to the fifth data in the data to be encoded, wherein the seventh Huffman-coded data is greater than the first length, and the fifth data is the fifth character; construct the index relationship between the eighth Huffman-coded data in the seventh Huffman-coded data and the fifth entry of the first index table; wherein the eighth Huffman-coded data is the Huffman-coded data from the 1st to the Nth position in the seventh Huffman-coded data, where N is the numerical value corresponding to the first length; the fifth entry includes a fifth code length field, a first storage location field, a fifth character count identifier field, and an offset field; the fifth code length field includes the length information of the eighth Huffman data. The first storage location field includes the starting address of the second index table; the fifth character count field includes the character count information in the fifth table entry; the offset field includes the offset information of the address of the sixth table entry in the second index table relative to the starting address, and the offset information is determined based on the ninth Huffman encoded data in the seventh Huffman data, which is the Huffman encoded data after the Nth bit in the seventh Huffman encoded data; the sixth table entry includes a sixth code length field and a fifth character field; the sixth code length field is used to store the length information of the seventh Huffman encoded data; the fifth character field is used to store the information corresponding to the fifth character.
[0023] In one possible implementation of the first aspect, it further includes: obtaining the tenth Huffman encoded data corresponding to the end symbol; and constructing an index relationship between the tenth Huffman encoded data and the end symbol.
[0024] In one possible implementation of the first aspect, constructing the index relationship between the tenth Huffman encoded data and the end symbol includes: constructing the index relationship between the tenth Huffman encoded data and the seventh entry in the first index table corresponding to the data to be encoded; wherein the seventh entry includes a seventh code length field, an end symbol information field, and a sixth character quantity identifier field; the seventh code length field includes the data length information of the tenth Huffman encoded data; the end symbol information field includes the end symbol information; and the sixth character quantity identifier field includes the number of characters in the seventh entry.
[0025] Secondly, embodiments of this application provide a decompression method for an electronic device. The method includes: obtaining an eleventh Huffman-coded data of a first length in compressed data and an index relationship between the Huffman-coded data and corresponding data in the compressed data; determining, based on the eleventh Huffman-coded data and the index relationship, the first decoded data corresponding to the eleventh Huffman-coded data and the data length of the Huffman-coded data corresponding to the first decoded data, wherein the first decoded data includes first data and second data, the data length of the Huffman-coded data corresponding to the first decoded data includes the sum of the data length of the first Huffman-coded data corresponding to the first data and the data length of the second Huffman-coded data corresponding to the second data, the first data and the second data are adjacent data, and the sum of the data length of the first Huffman-coded data and the data length of the second Huffman-coded data is less than or equal to the first length, and both the first data and the second data are characters, or one of the first data and the second data is a character and the other data is a length parameter, and the length parameter is located after the character.
[0026] Based on the decompression method provided in the embodiments of this application, it is possible to decode one character and one length parameter by looking up the table once, or to decode two characters by looking up the table once. This can effectively reduce the number of table lookups during the decoding process and shorten the decoding time.
[0027] In one possible implementation of the second aspect, corresponding to the first data including a first character, the second data including a second character, and the index relationship including a first index table; determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship, including:
[0028] The first entry is obtained from the first index table based on 11-Huffman encoded data. The first entry includes a first code length field, a first character field, a second character field, and a first character count identifier field. The first code length field includes information corresponding to the sum of the data lengths of the first Huffman encoded data and the second Huffman encoded data. The first character field includes information corresponding to the first character, the second character field includes information corresponding to the second character, and the first character count identifier field includes the number of characters in the first entry. First data is determined based on the first character field, second data is determined based on the second character field, and the data length of the first Huffman encoded data corresponding to the first data and the sum of the data lengths of the second Huffman encoded data corresponding to the second data are determined based on the first code length field.
[0029] In one possible implementation of the second aspect, determining first data based on a first character field and determining second data based on a second character field includes: reading information at a preset position in a first table entry, the information at the preset position including a first character field and a second character field; writing the decoded data corresponding to the information at the preset position in the first table entry into a first storage location of the electronic device, the decoded data corresponding to the information at the preset position including first data corresponding to the first character field and second data corresponding to the second character field; and determining the write address corresponding to the next written data based on a first character quantity identifier field, wherein the write address corresponding to the next written data is located after the first storage location.
[0030] Based on the decompression method provided in this application, characters can be written by reading information from a preset position (e.g., bits 8 to 23), copying the decoded data corresponding to the information at the preset position, and writing the decoded data corresponding to the information at the preset position into the corresponding storage location. This achieves character writing through speculative character generalization operations, completing all possible character processing operations even when the table entry type is uncertain. This reduces the number of complex branch instructions, effectively reducing pipeline blocking caused by CPU data dependencies, improving the efficiency of CPU pipelined instruction processing, shortening decompression time, increasing decompression efficiency, and reducing CPU resource utilization. Furthermore, writing two characters at once can also effectively reduce character processing operations, further improving decompression efficiency.
[0031] In one possible implementation of the second aspect, the first code length field is stored in the corresponding positions of bits 0 through 7 in the first entry.
[0032] In some embodiments, the first code length field can be stored in the corresponding positions of bits 0 to 7 in the first entry. It can be understood that when the first code length field is stored in the lower 8 bits of the entry, during the decoding process, when reading and decoding the first code length field, the uxtb extension operation can be used directly to retrieve the value. That is, the lower 8 bits of the value can be extracted from the WO register using the sub w4,w4,w0,uxtb instruction, and the code length corresponding to the lower 8 bits of the value is subtracted from W4. Here, the WO register is used to store the original value read from the entry, and W4 can be used to store the remaining undecoded data. Subtracting the code length corresponding to the lower 8 bits of the value from W4 ensures that the remaining undecoded data in W4 will have a reduced code length corresponding to the lower 8 bits of the value.
[0033] Thus, compared to some implementation schemes where the code length field is stored in higher bits and requires additional instructions to extract the code length field to a temporary register through shifting operations before calculation, this method can achieve decoding efficiency without additional bit field operations and the use of temporary registers.
[0034] In one possible implementation of the second aspect, corresponding to the first data including a third character and the second data including a first length parameter, determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship includes: obtaining a second table entry from a first index table based on the eleventh Huffman encoded data, wherein the second table entry includes a second code length field, a third character field, a first length field, and a second character quantity identifier field. The second code length field includes data length information of the first Huffman encoded data, data length information of the second Huffman encoded data, and extended length parameter information. The third character field includes information corresponding to the third character. The first length field includes information corresponding to the first length parameter. The second character quantity identifier field includes the number of characters in the second table entry. The first data is determined based on the third character field, the second data is determined based on the first length field, and the sum of the data lengths of the first Huffman encoded data corresponding to the first data and the second Huffman encoded data corresponding to the second data is determined based on the second code length field.
[0035] In one possible implementation of the second aspect, determining the first data based on the third character field and the second data based on the first length field includes: reading information at a preset position in the second table entry, the information at the preset position in the second table entry including a portion of the third character field and the first length field; writing the decoded data corresponding to the information at the preset position in the second table entry into a second storage location of the electronic device, the decoded data at the preset position in the second table entry including the first data corresponding to the third character field; determining the write address corresponding to the next written data based on the second character quantity identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the first data in the second storage location; determining the second data based on the first length field and writing the second data after the storage location corresponding to the first data.
[0036] In one possible implementation of the second aspect, the second code length field is stored in the corresponding positions of bits 0 through 7 in the second entry.
[0037] In one possible implementation of the second aspect, the method further includes: obtaining fifth Huffman-coded data of a first length in the compressed data and the index relationship between the Huffman-coded data and the corresponding data in the compressed data; determining the second decoded data corresponding to the fifth Huffman-coded data and the data length of the Huffman-coded data corresponding to the second decoded data based on the fifth Huffman-coded data and the index relationship, wherein the second decoded data includes third data, wherein the third data is a fourth character. In another possible implementation of the second aspect, determining the second decoded data corresponding to the fifth Huffman-coded data and the data length of the Huffman-coded data corresponding to the second decoded data based on the fifth Huffman-coded data and the index relationship includes: obtaining a third entry from a first index table based on the fifth Huffman-coded data, wherein the third entry includes a third code length field, a fourth character field, and a third character quantity identifier field, the third code length field includes the data length information of the fifth Huffman-coded data, the fourth character field includes the information corresponding to the fourth character, and the third character quantity identifier field includes the quantity information of the characters in the third entry; determining the third data based on the fourth character field, and determining the data length of the Huffman-coded data corresponding to the third data based on the third code length field.
[0038] In one possible implementation of the second aspect, determining the third data based on the fourth character field includes: reading information at a preset position in the third table entry; writing the decoded data corresponding to the information at the preset position in the third table entry into the third storage location of the electronic device, wherein the decoded data corresponding to the information at the preset position in the third table entry includes the third data corresponding to the third character field; and determining the write address corresponding to the next written data based on the third character quantity identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the third data in the third storage location.
[0039] In one possible implementation of the second aspect, the method further includes: obtaining a sixth Huffman-coded data of a first length in the compressed data and an index relationship between the Huffman-coded data and the data to be encoded in the compressed data; determining the third decoded data corresponding to the sixth Huffman-coded data and the data length of the Huffman-coded data corresponding to the third decoded data based on the sixth Huffman-coded data and the index relationship, wherein the third decoded data includes fourth data, and the fourth data is a second length parameter.
[0040] In one possible implementation of the second aspect, determining the third decoded data corresponding to the sixth Huffman-coded data and the data length of the Huffman-coded data corresponding to the third decoded data based on the sixth Huffman-coded data and the index relationship includes: obtaining a fourth entry from a first index table based on the sixth Huffman-coded data, wherein the fourth entry includes a fourth code length field, a second length field, and a fourth character quantity identifier field, the fourth code length field includes the data length information of the sixth Huffman-coded data, the second length field includes the information corresponding to the second length parameter; the fourth character quantity identifier field includes the number of characters in the fourth entry; determining the fourth data based on the second length field, and determining the data length of the Huffman-coded data corresponding to the fourth data based on the fourth code length field.
[0041] In one possible implementation of the second aspect, the method further includes: obtaining the eighth Huffman-coded data of a first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data; determining the fifth entry in the first index table based on the eighth Huffman-coded data and the index relationship; the fifth entry includes a fifth code length field, a first storage location field, a fifth character count identifier field, and an offset field, wherein the fifth code length field includes the length information of the eighth Huffman data, the first storage location field includes the starting address of the second index table, the fifth character count identifier field includes the character count information in the fifth entry, and the offset field includes the offset information of the address of the sixth entry in the second index table relative to the starting address, the offset information being determined based on the ninth Huffman-coded data in the seventh Huffman data, wherein the ninth Huffman-coded data is the Huffman-coded data after the Nth bit in the seventh Huffman-coded data, and the eighth Huffman-coded data is the Huffman-coded data from the 1st bit to the Nth bit in the seventh Huffman-coded data, where N is the numerical value corresponding to the first length.
[0042] The sixth entry in the second index table is obtained based on the offset information and the starting position information of the second index table. The sixth entry includes a sixth code length field and a fifth character field. The sixth code length field is used to store the data length information of the seventh Huffman encoded data, and the fifth character field is used to store the information corresponding to the fifth character. The seventh Huffman encoded data includes the eighth Huffman encoded data and the ninth Huffman encoded data.
[0043] The fifth data is determined based on the fifth character field, and the length of the Huffman-coded data corresponding to the fifth data is determined based on the sixth code length field.
[0044] In one possible implementation of the second aspect, the method further includes: obtaining a tenth Huffman-coded data of a first length in the compressed data and an index relationship between the Huffman-coded data and the data to be encoded in the compressed data; determining the fourth decoded data corresponding to the tenth Huffman-coded data and the data length of the Huffman-coded data corresponding to the fourth decoded data based on the tenth Huffman-coded data and the index relationship, wherein the fourth decoded data includes an end-of-line character.
[0045] In one possible implementation of the second aspect, determining the fourth decoded data corresponding to the tenth Huffman encoded data and the data length of the Huffman encoded data corresponding to the fourth decoded data based on the tenth Huffman encoded data and the index relationship includes: obtaining the seventh entry from the first index table based on the tenth Huffman encoded data, wherein the seventh entry includes a seventh code length field, an end-of-character information field, and a sixth character quantity identifier field. The seventh code length field includes the data length information of the tenth Huffman encoded data, the end-of-character information field includes the end-of-character information, and the sixth character quantity identifier field includes the quantity information of the characters in the seventh entry; determining the end-of-character based on the end-of-character information field, and determining the data length of the Huffman encoded data corresponding to the end-of-character based on the seventh code length field.
[0046] Thirdly, embodiments of this application provide an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to perform the compression method in the first aspect and any possible implementation of the first aspect or the decompression method in the second aspect and any possible implementation of the first aspect.
[0047] Fourthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a first terminal device, implement a compression method as described in the first aspect and any possible implementation of the first aspect, or a decompression method as described in the second aspect and any possible implementation of the first aspect. Attached Figure Description
[0048] Figure 1 According to some embodiments of this application, a schematic diagram of a data compression and decompression scenario is shown;
[0049] Figure 2 According to some embodiments of this application, a schematic diagram of a data compression process and a data decompression process is shown;
[0050] Figure 3 According to some embodiments of this application, a schematic diagram of a character length index table is shown;
[0051] Figure 4aAccording to some embodiments of this application, a schematic diagram of a Huffman decoding process is shown;
[0052] Figure 4b According to some embodiments of this application, a schematic diagram of a Huffman decoding process that requires looking up a secondary index table is shown;
[0053] Figure 5 According to some embodiments of this application, a flowchart of a compression method is shown;
[0054] Figure 6 According to some embodiments of this application, a schematic diagram of a different table entry is shown;
[0055] Figure 7 According to some embodiments of this application, a flowchart of a decompression method is shown;
[0056] Figure 8 According to some embodiments of this application, a schematic diagram of the position of the next out pointer is shown;
[0057] Figure 9 A simplified flowchart of a decompression method is shown according to some embodiments of this application;
[0058] Figure 10 According to some embodiments of this application, a schematic diagram of the structure of an electronic device is shown;
[0059] Figure 11 According to some embodiments of this application, a schematic diagram of the structure of another electronic device is shown. Detailed Implementation
[0060] The illustrative embodiments of this application include, but are not limited to, a compression method, a decompression method, an electronic device, and a storage medium.
[0061] The electronic devices in this application embodiment can also be referred to as terminals, user equipment (UE), mobile stations (MS), mobile terminals (MT), etc. Terminal devices can be mobile phones, smart TVs, wearable devices, tablets, computers, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, or wireless terminals in smart homes, etc. The electronic devices in this application embodiment can also be servers, or other electronic devices that may require data compression / decompression functions.
[0062] Figure 1 This diagram illustrates a scenario of data compression and decompression.
[0063] For example, such as Figure 1 As shown, when the electronic device 100 responds to a user's compression operation on document 1010, it can compress document 1010 based on the compression method mentioned in the embodiments of this application to obtain compressed document 1020. When the terminal device responds to a user's decompression operation on compressed document 1020, it can decompress compressed document 1020 based on the decompression method mentioned in the embodiments of this application to obtain document 1010.
[0064] It should be noted that, Figure 1 The data compression and decompression scenarios illustrated are merely illustrative. The compression methods mentioned in this application embodiment can be used in any compression scenario, such as compressing office documents, compressing data during image encoding and decoding, and compressing application installation packages. The decompression methods mentioned in this application embodiment can be applied to any decompression scenario, such as decompressing office documents, decompressing data during image encoding and decoding, and decompressing application installation packages.
[0065] The following describes the data compression and decompression processes in some implementation schemes.
[0066] Figure 2The diagram illustrates a data compression and decompression process.
[0067] like Figure 2 As shown, the data compression process includes: obtaining the original data to be compressed, performing dictionary encoding, Huffman encoding, and verification processing on the original data in sequence, and obtaining compressed data.
[0068] The data decompression process includes: acquiring compressed data, performing Huffman decoding, dictionary decoding, and checksum processing on the compressed data in sequence, and obtaining decompressed data, i.e., the original data.
[0069] The principle of dictionary encoding is to use length and distance parameters to represent the position and length of the repeating string, thereby reducing the amount of data. The distance parameter represents the distance between the position of the first letter of the current string and the starting position of the preceding repeating string, and the length parameter represents the length of the repeating string.
[0070] For example, if the original data to be compressed is ABCDABC, which contains the repeating string ABC, then dictionary encoding of the original data ABCDABC will result in the encoded data ABCD(3,4). Here, 4 is a distance parameter, representing that the distance between the first letter (A) of the current repeating string (ABC) and the starting position of the preceding repeating string (ABC) is 4 characters; 3 is a length parameter, indicating that the length of the current repeating string is 3 characters. Thus, during dictionary decoding, the dictionary-encoded data ABCD(3,4) can also be decoded back to the original data ABCDABC based on this dictionary encoding principle.
[0071] The principle of Huffman coding is to represent frequently occurring symbols in the data to be Huffman coded (such as data obtained after dictionary encoding) with shorter binary codes and less frequently occurring symbols with longer binary codes, so as to achieve data compression.
[0072] The principle of checksums: During data compression, the data to be checked is divided into fixed-size blocks (e.g., bytes), and arithmetic or logical operations (e.g., summation or XOR) are performed to generate a checksum, which is then used as part of the compressed data. During decompression, the checksum can be recalculated using the same method and compared with the checksum in the compressed data to detect data corruption.
[0073] The following section provides a more detailed explanation of the Huffman coding and Huffman decoding process.
[0074] The Huffman coding process can include the encoding process and the process of constructing the index relationship between the encoded data and the original data. The encoding process will be introduced first below.
[0075] The encoding process can include representing frequently occurring symbols in the data to be Huffman encoded with shorter binary codes and less frequently occurring symbols with longer binary codes. For example, in the string D1 "BACAEFGCBI EADAGH" to be Huffman encoded, the character A appears 4 times, characters B, C, D, and E each appear 2 times, and characters F, G, H, and I each appear once. Therefore, string D1 can be Huffman encoded based on the frequency of each character. Examples of Huffman encoding string D1 are shown in Table 1.
[0076] Table 1:
[0077]
[0078]
[0079] As shown in Table 1, the Huffman code for character A is 00, and the Huffman code for character B is 010. The Huffman codes for the remaining characters are detailed in Table 1 and will not be repeated here. It can be seen from Table 1 that the code lengths for characters F, G, H, and I are greater than the code lengths for characters B, C, D, and E, and the code lengths for characters B, C, D, and E are greater than the code length for character A. After obtaining the Huffman code for each character in string D1, converting each character to its corresponding Huffman code according to the order of characters in string D1 yields the Huffman code for string D1 (0100001100101110011010110101111101001000011011110).
[0080] In addition, after obtaining the Huffman code corresponding to each character, it is necessary to construct an index relationship between the encoded data and the original data so that the original data can be decoded according to the index relationship later.
[0081] One method for constructing the index relationship between encoded data and original data is to extend the original Huffman code corresponding to the original data to a fixed-length Huffman code as the index (or bit index). The original data (or symbol decoded result) and the length of the original Huffman code corresponding to the original data (or bits consumed) are used as the index result to construct an index table (or linear table, encoding table, decoding table, etc.). The fixed length can be the maximum length of the Huffman code defined in the relevant standard, such as 15 bits. For ease of explanation, Table 2 illustrates an index relationship corresponding to string D1 using a fixed length of 4 bits as an example:
[0082] Table 2:
[0083]
[0084]
[0085] As shown in Table 2, for the character A in string D1, the corresponding Huffman code is 00, with a length of 2 bits. Since this is less than the fixed length of 4 bits, the character A is extended to 4 bits. The extended Huffman codes for the four characters A in D1 can be "0000, 0010, 0001, 0011". These extended Huffman codes can be used as four indices, and the four corresponding characters A and the original Huffman codes for the four characters A, using the bit depth of 2, can be used as the index results for the four indices.
[0086] For the character B in string D1, the corresponding Huffman code is 010, with a length of 3 bits. Since this is less than the fixed length of 4 bits, character B is extended to 4 bits. The extended values of the two characters B in D1 can be 0100 and 0101, respectively. This extended Huffman code can be used as two indices. The two corresponding characters B and the original Huffman codes of the two characters B, using the bit depth of 3, can be used as the index results for the two indices. The index construction method for characters C, D, and E is the same as that for character B, and will not be repeated here.
[0087] For characters F, G, H, and I in string D1, their length is 4 bits, which is equal to a fixed length of 4 bits, so no expansion is needed. For example, for character F, the Huffman code 1100 of character F can be used as the index, and the index result of character F and the original Huffman code of character F using 4 bits is used as the index result of Huffman code 1100. The index construction method for characters G, H, and I is the same as that for character F, and will not be repeated here.
[0088] After constructing the index relationship between the encoded data and the original data, the index relationship and the Huffman code corresponding to each character can be used together as compressed data to facilitate subsequent Huffman decoding.
[0089] When performing Huffman decoding, a lookup table method can be used. That is, a fixed length of Huffman code can be obtained sequentially from the Huffman encoded data, and the index result can be searched in the index table based on the fixed length of Huffman code, thereby decoding the data before encoding.
[0090] The following example illustrates the decoding process based on the lookup table method, using the decoding of a portion of the bitstream D11 (0100001100101110011011011011110) from the Huffman code (01000011001011101101101101101) of the string D1 as an example.
[0091] Table 3 illustrates a lookup process. As shown in Table 3, firstly, the first four bits (0100) of bitstream D11 are used as an index for the lookup. Based on the index table in Table 2, the corresponding index result is found to be the character B, using 3 bits. That is, the first three bits of bitstream D11 are the Huffman code corresponding to the character B. In the second lookup, the data from the fourth to the seventh bit of bitstream D11 (0001) is retrieved. Based on Table 2, the corresponding index result is found to be the character A, using 2 bits. That is, the fourth and fifth bits of bitstream D11 are the Huffman code corresponding to the character A. In the third lookup, the data from the sixth to the ninth bit of bitstream D11 (0110) is retrieved. Based on Table 2, the corresponding index result is found to be the character C, using 3 bits. This process continues until all characters are decoded. For example, decoding bitstream D11 yields the result BACAEFGCBI.
[0092] Table 3:
[0093]
[0094]
[0095] In some embodiments, a long fixed length can lead to an excessively large index table size and memory usage. Due to table size and memory limitations, some solutions construct the index table using a first-level table and a second-level table. For example, if the maximum number of bits for the index in the first-level table is set to 4, then indexes greater than 4 bits and their corresponding index results can be stored in the second-level table. For instance, if the Huffman-coded data for symbol J is 11111 and the Huffman-coded data for symbol H is 11110, then the index result corresponding to 11111 can be stored in the first-level table. This index result includes the storage location A1 of the index result corresponding to the fifth bit "1" in 11111 in the second-level table, as well as the extra bits corresponding to the second-level table (i.e., the number of bits beyond 4 bits, such as 1 bit). Similarly, the index result corresponding to 11110 can be stored in the first-level table. This index result includes the storage location A2 of the index result corresponding to the fifth bit "0" in 11110 in the second-level table, as well as the extra bits corresponding to the second-level table. The index result corresponding to 11111 (i.e., including the symbol decoding result J and the number of bits used, 5) is stored in storage location A1 of the second-level table, and the index result corresponding to 11110 (i.e., including the symbol decoding result H and the number of bits used, 5) is stored in storage location A2 of the second-level table. In this way, when performing Huffman decoding, for an index with more than 4 bits, the corresponding index result can be found in the second-level table based on the storage location in the first-level table.
[0096] It is understood that the index table shown in Table 2 above is merely an illustrative example of the content. In some implementations, during Huffman coding, the contents of the index table are all binary values for ease of reading and storage in the computer. For example, it is generally necessary to convert the data before encoding (original data) into values between 0 and 285 according to the character mapping table, length mapping table, and distance mapping table, and the index table will convert the values between 0 and 285 into binary values. In addition, when constructing the index table, two different types of index tables are constructed: one is a character length (literal / length) index table corresponding to the character and length parameters, and the other is a distance (dist) index table corresponding to the distance parameter.
[0097] The following example, using the data to be Huffman encoded as ABCD(3,4) encoded by the dictionary above, illustrates the detailed process of constructing the character length index table.
[0098] For example, if the data to be Huffman encoded is the dictionary-encoded data ABCD(3,4), then A, B, C, and D need to be converted into values between 0 and 255 according to the character mapping table, the length parameter 3 needs to be converted into a value between 257 and 285, the distance parameter 4 needs to be converted into a value between 0 and 29, and when constructing the index table, the above values need to be converted into binary values.
[0099] The character mapping table records each symbol and its corresponding value, with each symbol having a value range of 0-255. Table 4 illustrates a partial example of a character mapping table. As shown in Table 4, the conversion value for character A is 65, for character B it is 66, for character C it is 67, and for character D it is 68.
[0100] Table 4
[0101] character Convert numerical values ... ... A 65 B 66 C 67 D 68 E 69 F 70 ... ...
[0102] The length mapping table records the base length and extra bits for each actual length. The base length ranges from 257 to 285. The extra bits allow for representing larger actual lengths using a base length plus extra bits. Table 5 illustrates one such length mapping table. As shown in Table 5, when the actual length (parameter) is 3, the corresponding conversion value is a base length of 257 and 0 extra bits; when the actual length is 11, the corresponding conversion value is a base length of 265 and 0 extra bits; and when the actual length is 12, the conversion value is a base length of 265 and 1 extra bit. That is, the conversion value corresponding to the length parameter includes both the base length and the extra bits. For the dictionary-encoded data ABCD(3,4), looking up the length mapping table, the conversion value corresponding to the length parameter 3 is 257, and the extra bits are 0.
[0103] Table 5
[0104] Actual length Baselength Extra bits 3 257 0 4 258 0 11 + [0, 1], which is 11 - 12 265 1 ... ... ...
[0105] The distance mapping table records the base distance and extra bits for each actual distance. The base distance ranges from 0 to 29. The extra bits allow for representing more actual distances using a base distance plus an extra bit value. Table 6 illustrates one such distance mapping table. As shown in Table 6, when the actual distance is 4, the corresponding converted value is the base distance 3 plus 0 extra bits; when the actual distance is 5, the corresponding converted value is the base distance 4 plus 0 extra bits; and when the actual distance is 6, the corresponding converted value is the base distance 4 plus 1 extra bit. That is, the converted value of the distance parameter includes both the base distance and the extra bits. For the dictionary-encoded data ABCD(3,4), looking up the distance parameter 4 in the distance mapping table reveals that the converted value is the base distance 3 plus 0 extra bits.
[0106] Table 6:
[0107] actual distance Base distance Extra bits 1 0 0 4 3 0 5 + [0, 1], which means 5 - 6 4 1
[0108] In summary, when constructing the index table, for the dictionary-encoded data ABCD(4,3), character A needs to be converted to the binary code corresponding to the conversion value 65, character B needs to be converted to the binary code corresponding to the conversion value 66, character C needs to be converted to the binary code corresponding to the conversion value 67, character D needs to be converted to the binary code corresponding to the conversion value 68, length parameter 3 needs to be converted to the binary code corresponding to the conversion value 257, and distance parameter 4 needs to be converted to the binary code corresponding to the base distance value 3 and the extra bits 0.
[0109] It is understandable that during Huffman coding, a terminator can be added to the data to be encoded, and the terminator can be Huffman coded accordingly, so that the decoding process can be terminated based on the terminator during decoding. The conversion value corresponding to the terminator is 256.
[0110] Based on the Huffman coding process mentioned earlier, for example, if we need to represent frequently occurring symbols in the data to be Huffman coded with shorter binary codes and less frequently occurring symbols with longer binary codes, then performing Huffman coding on the dictionary-coded data ABCD(3,4) and the terminator, the resulting Huffman codes are shown in Table 7. As shown in Table 7, since each data item in the dictionary-coded data appears only once, the Huffman code lengths are equal, for example, 4 bits each. According to Table 7, the Huffman code corresponding to ABCD(3,4) is 00110100011010001001. After adding the terminator, the resulting coded data can be, for example, 001101000110100010011010.
[0111] Table 7
[0112]
[0113]
[0114] The following section provides a detailed introduction to the specific fields in the character length index table (taking the first-level table as an example).
[0115] Figure 3 This diagram illustrates a character length index table. Each row in the index table corresponds to an index, and each row is 32 bits in size. The fields included in each row (i.e., the table entry fields) may include a sign value (val) field, an opcode (op) field, and a bit length (bits) field.
[0116] The `val` field, stored in bits 16 to 31, can include the binary value corresponding to the converted value between 0 and 285 of the data to be Huffman encoded (e.g., data after dictionary encoding). For example, if a row represents a character, the symbol value field can include the binary value corresponding to the character (literal). Similarly, if a row represents a length parameter, the symbol value field can include the binary value corresponding to the length parameter. If a row represents a terminator, the symbol value field can include the binary value corresponding to the terminator or contain no value. Furthermore, if a row represents a lookup in a second-level table, the symbol value field can include the storage location of the corresponding entry in the second-level table, such as the starting address of the second-level table (2nd table base).
[0117] The `op` field, stored in bits 8 through 15, includes an operation type identifier indicating the type of operation to be performed upon reading this identifier during decoding. For example, an identifier of 00000000 indicates that the character corresponding to the value of the symbol value field is used directly as the decoding result. A value of 1 in bit 12 indicates that the value of the symbol value field needs to be read as the base length, and additional bits need to be read. A value of 1 in bits 13 and 14, and 0 in bit 12, indicates that the decoding process for this data block needs to be terminated. The `offset` bits represent the offset of the corresponding entry address in the second-level table relative to the starting address of the second-level table, indicating that an index result needs to be read from the second-level table.
[0118] When an entry corresponds to a character, the bit length field in the entry can include the number of bits used for the character. When an entry corresponds to a length parameter, the bit length field can include the extra bits in the converted value corresponding to the length parameter. When an entry corresponds to a position in a second-level table, the bit length field can include the offset information of the position of the corresponding entry in the second-level table relative to the starting address. Specifically, the number of bits used for the character, the offset information of the position of the corresponding entry in the second-level table relative to the starting address, are located in bits 0 to 7, and the extra bits corresponding to the length are located in bits 5 to 7.
[0119] For example, for the dictionary-encoded data ABCD(3,4), the contents of the constructed character length table can be shown in Table 8.
[0120] Table 8
[0121]
[0122] As shown in Table 8, the index corresponding to character A is the Huffman code 0011. The index result includes: a symbol value field of 01000001 (corresponding to the decimal value 65, i.e., the character A); an opcode of 00000000, which indicates that the character corresponding to the value of the symbol value field is used directly as the decoding result; and a bit length of 4, indicating that the Huffman code length corresponding to character A is 4. The index relationship corresponding to characters B, C, and D is described in the same way as that for character A, and will not be repeated here.
[0123] The index corresponding to the length parameter 3 is Huffman code 1001. The index result includes: the sign value field 100000001 (corresponding to the base length 4 in the converted value of the length parameter); the opcode is 00010000, which indicates that the value of the sign value field needs to be read as the base length, and that additional bits need to be read; the number of additional bits is 0 (corresponding to the number of extra bits in the converted value of the length parameter), indicating that no additional bits need to be read.
[0124] The distance index table is constructed in a similar way to the character length index table, so it will not be described in detail here.
[0125] The following section provides a detailed explanation of the Huffman decoding process based on the Huffman coding process described above.
[0126] Figure 4a A schematic diagram of a Huffman decoding process is shown, such as... Figure 4a As shown, the decoding process includes obtaining a fixed-length bitstream from the bitstream to be decoded as an index, performing Huffman decoding based on a character length (litera / length) index table, i.e., searching for an entry in the character length (litera / length) index table, and determining the operation type based on the content of the op field in the entry. It can be understood that the fixed length in this embodiment can be 1-15 bits.
[0127] For example, if the identifier corresponding to the 'op' field in a table entry directly uses the character corresponding to the value of the symbol field as the decoding result, then the range of the decimal value corresponding to the binary code of the 'val' field is determined to be 0-255, meaning the 'val' field is the character code. In this case, the actual character corresponding to the character code is output and copied. For example, if the dictionary-encoded data is ABCD(3,4), the Huffman code corresponding to it is D2(0011010001101000100110101011). Using the first four bits 0011 in D2 as an index, and finding the index result in Table 8 where the 'op' field is 00000000 and the decimal value corresponding to the binary value of the 'val' field is 65, then the character A corresponding to 65 is output.
[0128] If the identifier corresponding to the `op` field in a table entry indicates that the value of the symbol value field needs to be read as the base length, and that additional bits need to be read, then the `val` field is determined to be the length code (where the value range of the length code is 257-285). The base length is obtained based on the content of the `val` field, and the additional bits obtained from the bit count field are used as the length offset. The actual length parameter is then obtained based on the length offset and the base length. For example, if the dictionary-encoded data is ABCD(4,3), the Huffman code corresponding to it is D2(0011010001101000100110101011). Using the 17th to 20th bits (1001) of D2 as an index, the `op` field in the index result found in Table 8 is 00010000, the decimal value corresponding to the binary value of the `val` field is 257, and there is an additional bit of 0. Based on the additional bit, the length offset is 0. Based on the base length of 257, the corresponding length parameter is 3. Since the length offset is 0, no additional length needs to be added; that is, the final actual length parameter is 3.
[0129] After decoding the actual length parameter, a fixed-length bitstream can be obtained from the bitstream to be decoded. The distance Huffman lookup table is then performed to retrieve the distance parameter. For example, the base distance and extra bits need to be obtained from the corresponding entry in the distance index table, and the extra bits are used as the distance offset. The actual distance parameter is then obtained based on the distance offset and the base distance. The decoding process for the distance parameter is similar to that for the length parameter, and will not be elaborated here. Then, based on dictionary encoding principles, the distance parameter, and the length parameter, the corresponding string is determined, and the string is copied and written to the corresponding storage location.
[0130] If the identifier corresponding to the 'op' field in the table entry indicates that decoding needs to be terminated, then the decoding of this current data block ends. For example, if the dictionary-encoded data is ABCD(3,4), and the corresponding Huffman code is D2(0011010001101000100110101011), then by using the last four digits 1011 in D2 as an index, and finding that the 'op' field in the index result retrieved from Table 8 is 01100000, then the decoding process for this data block ends, and the decoding of the next data block begins.
[0131] As mentioned earlier, in some cases, both primary and secondary index tables will be constructed. Therefore, there may be situations where it is necessary to search the secondary index table. Figure 4b This diagram illustrates a Huffman decoding process that requires looking up a secondary index table. For example... Figure 4bAs shown, if the OP field in the corresponding entry of the character length index table found by the index is the offset information (offset bits) of the address of the corresponding entry in the second-level table relative to the starting address of the second-level table, it indicates that the index result needs to be read from the second-level table. At this time, it is necessary to search the second-level table to obtain the index result. For example, the index result may include the length code, the end code, and the character code.
[0132] As can be seen from the above decoding process, currently each table lookup can only obtain one decoding item, such as a character or a length parameter, resulting in a large number of indexing operations and a long decoding process.
[0133] To address the aforementioned issues, this application provides a compression method. During Huffman coding, first Huffman-coded data corresponding to first data in the data to be encoded, and second Huffman-coded data corresponding to second data in the data to be encoded, are obtained. If the first and second data are adjacent, and the sum of their lengths is less than or equal to a first length (e.g., the fixed length mentioned above), the first and second Huffman-coded data can be concatenated to obtain third Huffman-coded data, where the length of the third Huffman-coded data is equal to the first length. Then, an index relationship is constructed between the third Huffman-coded data and the first and second data. The first and second data can both be characters, or one of the first and second data can be a character and the other a length parameter, with the length parameter following the character. The first Huffman-coded data, the second Huffman-coded data, and the index relationship are then used as the compressed data corresponding to the first and second data.
[0134] For example, if in the data ABCD(3,4) to be encoded, the Huffman code for character A is 00, for character B it is 01, for character C it is 1010, for character D it is 10, and for length parameter 3 it is 11. If the fixed length of the index in the character length index table is 4, then when constructing the index table, the Huffman codes for characters A and B can be merged into 0001 and used as the index. The binary values corresponding to characters A and B are stored in the corresponding entries of the character length index table. During decoding, characters A and B can be obtained by searching the character length index table based on this index. Similarly, when constructing the character length index table, the Huffman codes for characters D and length parameter 3 can be merged into 1011 and used as the index. The binary values corresponding to characters D and length parameter 3 are stored in the corresponding entries of the character length index table. During decoding, characters D and length parameter 3 can be obtained by searching the corresponding entries of the character length index table based on this index.
[0135] As mentioned earlier, currently each table lookup can only retrieve one decoded item, such as a character or a length parameter, resulting in numerous indexing operations and a lengthy decoding process. Based on the compression method provided in this application, an index can be constructed corresponding to one character and one length parameter, or an index can be constructed corresponding to two characters. This allows for situations where a single table lookup retrieves one character and one length parameter, or two characters, effectively reducing the number of table lookups and shortening the decoding time.
[0136] Correspondingly, this application provides a decompression method, including: obtaining Huffman-coded data of a first length in compressed data and the index relationship between the Huffman-coded data and corresponding data in the compressed data (e.g., the index relationship between Huffman-coded data and each entry in a character length index table); determining the decoded data corresponding to the Huffman-coded data of the first length and the data length of the Huffman-coded data corresponding to the decoded data based on the Huffman-coded data of the first length and the index relationship. The decoded data may include first data and second data. The data length of the Huffman-coded data corresponding to the decoded data includes the sum of the data length of the first Huffman-coded data corresponding to the first data and the data length of the second Huffman-coded data corresponding to the second data. The first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman-coded data and the second Huffman-coded data is less than or equal to the first length. Furthermore, both the first data and the second data are characters, or one of the first data and the second data is a character and the other is a length parameter, with the length parameter following the character.
[0137] Based on the decompression method provided in the embodiments of this application, it is possible to decode one character and one length parameter by looking up the table once, or to decode two characters by looking up the table once. This can effectively reduce the number of table lookups during the decoding process and shorten the decoding time.
[0138] For example, in the above example, the Huffman codes corresponding to characters A and B can be merged into 0001 and used as an index. The binary values corresponding to characters A and B can be stored in the entry corresponding to that index in the character length index table. Similarly, the Huffman codes corresponding to characters D and length parameter 3 can be merged into 1011 and used as an index. The binary values corresponding to characters D and length parameter 3 can be stored in the entry corresponding to that index in the character length index table.
[0139] For ease of description, the Huffman-coded data of the first length in the compressed data is referred to as the eleventh Huffman-coded data. During decoding, if the eleventh Huffman-coded data is 0001, the corresponding table entry can be determined based on 0001 and the index relationship between the Huffman-coded data in the compressed data and the entries in the character length index table. The decoded data can then be obtained from the information in that corresponding table entry. For example, the decoded data may include characters A and B. If the eleventh Huffman-coded data is 1011, the corresponding table entry can be determined based on 1011 and the index relationship between the Huffman-coded data in the compressed data and the entries in the character length index table. The decoded data can then be obtained from the information in that corresponding table entry. For example, the decoded data may include character D and the length parameter 3. This allows for decoding one character and one length parameter in a single table lookup, or decoding two characters in a single table lookup, effectively reducing the number of table lookups during the decoding process and shortening the decoding time.
[0140] In some embodiments, obtaining the Huffman-coded data length information corresponding to the decoded data can facilitate obtaining the first length of data to be decoded next from the compressed data based on the Huffman-coded data length information corresponding to the decoded data.
[0141] For example, if the Huffman-coded data to be decoded in the compressed data is 00011011 and the first length is 4, after decoding 0001 for the first time, the data length information of the Huffman-coded data corresponding to 0001 is 4. Then, starting from the fifth bit in the Huffman-coded data 00011011, the first length of the Huffman-coded data to be decoded, i.e., 1011, can be obtained and decoded.
[0142] The compression methods mentioned in the embodiments of this application will be described in detail below.
[0143] Figure 5 The schematic diagram illustrates a compression method according to an embodiment of this application, as follows: Figure 5 As shown, the compression methods include:
[0144] 101: Obtain the first Huffman encoded data corresponding to the first data in the data to be encoded, and the second Huffman encoded data corresponding to the second data in the data to be encoded, wherein the first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman encoded data and the second Huffman encoded data is less than or equal to the first length, and both the first data and the second data are characters, or one of the first data and the second data is a character and the other data is a length parameter, and the length parameter is located after the character.
[0145] It is understood that the data to be encoded mentioned in the embodiments of this application can be data after dictionary encoding. Therefore, the data to be encoded may include characters, length parameters, and distance parameters. For example, part of the data to be encoded in the embodiments of this application may include ABCD(3,4), where A, B, C, and D are all characters, 4 is the length parameter, and 4 is the distance parameter.
[0146] In some embodiments, Huffman coding can be performed on the data to be encoded to obtain Huffman-coded data corresponding to each data point. For example, the first Huffman-coded data corresponding to the first data point in the data to be encoded, and the second Huffman-coded data corresponding to the second data point in the data to be encoded, etc., can be obtained. The method for obtaining the Huffman-coded data corresponding to each data point can be as described above, and will not be repeated here.
[0147] In some embodiments, if the first data and the second data are adjacent data, and the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is less than or equal to the first length, and both the first data and the second data are characters, then the first Huffman-coded data and the second Huffman-coded data can be concatenated to obtain third Huffman-coded data, the length of which is equal to the first length. The first length can be a preset index length; for example, it can be the maximum length of Huffman coding defined in relevant standards, such as 15 bits. For ease of understanding, this application uses a first length of 4 bits as an example to illustrate the compression and decompression methods in this application.
[0148] In some embodiments, if the first data and the second data are adjacent data, and the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is less than or equal to the first length, and one of the first data and the second data is a character and the other data is a length parameter, and the length parameter is located after the character, then the first Huffman-coded data and the second Huffman-coded data can be concatenated to obtain the third Huffman-coded data, and the length of the third Huffman-coded data is equal to the first length.
[0149] For example, if in the data to be encoded, part ABCD(3,4) has the following Huffman codes: A = 00, B = 01, C = 1010, D = 10, and length parameter 3 = 11, then when constructing the character length index table, the Huffman codes for characters A and B can be merged into 0001 and used as the index, and the Huffman codes for characters D and length parameter 3 can be merged into 1011 and used as the index.
[0150] It is understood that the data to be encoded mentioned in the embodiments of this application can also be data that has not undergone dictionary encoding. In this case, the data to be encoded can only include characters, that is, both the first data and the second data are characters. The compression method and decompression method can refer to the relevant descriptions in the embodiments of this application that do not involve compression methods related to length parameters. Subsequent embodiments will be described using data to be encoded that has undergone dictionary encoding as an example.
[0151] 102: Concatenate the first Huffman-coded data and the second Huffman-coded data to obtain the third Huffman-coded data. The length of the third Huffman-coded data is equal to the length of the first Huffman-coded data.
[0152] In some embodiments, concatenating first Huffman-coded data and second Huffman-coded data to obtain third Huffman-coded data includes: if the sum of the lengths of the first and second Huffman-coded data is less than a first length, merging the first and second Huffman-coded data to obtain fourth Huffman-coded data, and obtaining the third Huffman-coded data by extending the fourth Huffman-coded data. If the sum of the lengths of the first and second Huffman-coded data is equal to the first length, merging the first and second Huffman-coded data to obtain the third Huffman-coded data.
[0153] For example, if in the partial data ABCD(3,4) to be encoded, the Huffman code for character A is 00 and the Huffman code for character B is 01, and the first length is 4, and the sum of the data lengths of the Huffman codes for characters A and B is equal to the first length, then the Huffman codes for characters A and B can be merged into 0001 and used as an index. If in the partial data ABCD(3,4) to be encoded, the Huffman code for character A is 00 and the Huffman code for character B is 0, and the first length is 4, and the sum of the data lengths of the Huffman codes for characters A and B is less than the first length, then the Huffman codes for characters A and B can be merged into 000, and 000 can be extended to 0000 or 0001.
[0154] 103: Construct the index relationship between the third Huffman encoded data and the first and second data.
[0155] In some embodiments, if the first data includes a first character and the second data includes a second character, constructing an index relationship between the third Huffman-coded data and the first and second data may include: constructing an index relationship between the third Huffman-coded data and the first entry in a first index table corresponding to the data to be encoded. The first entry includes a first code length field, a first character field, a second character field, and a first character count identifier field.
[0156] The first code length field includes information corresponding to the sum of the lengths of the first Huffman encoded data and the lengths of the second Huffman encoded data. For example, if the first data is the aforementioned character A, the second data is character B, the Huffman encoded data corresponding to character A is 00, the Huffman encoded data corresponding to character B is 01, and the sum of the lengths of the Huffman encoded data corresponding to character A and character B is 4, then the first code length field can include the binary value corresponding to 4.
[0157] The first character field includes the information corresponding to the first character, and the second character field includes the information corresponding to the second character. For example, if the first data is the aforementioned character A and the second data is character B, then the first character field includes the binary value corresponding to character A, and the second character field includes the binary value corresponding to character B.
[0158] The first character count identifier field contains information about the number of characters in the first table entry. It can be understood that when both the first and second data are characters, the number of characters in the first table entry is 2, and the first character count identifier field includes the binary value corresponding to 2.
[0159] In some embodiments, the first code length field can be stored in the corresponding positions of bits 0 to 7 in the first entry. It can be understood that when the first code length field is stored in the lower 8 bits of the entry, during the decoding process, when reading and decoding the first code length field, the uxtb extension operation can be used directly to retrieve the value. That is, the lower 8 bits of the value can be extracted from the WO register using the sub w4,w4,w0,uxtb instruction, and the code length corresponding to the lower 8 bits of the value is subtracted from W4. Here, the WO register is used to store the original value read from the entry, and W4 can be used to store the remaining undecoded data. Subtracting the code length corresponding to the lower 8 bits of the value from W4 ensures that the remaining undecoded data in W4 will have a reduced code length corresponding to the lower 8 bits of the value.
[0160] Thus, compared to some implementation schemes where the code length field is stored in higher bits and requires additional instructions to extract the code length field to a temporary register through shifting operations before calculation, this method can achieve decoding efficiency without additional bit field operations and the use of temporary registers.
[0161] In some embodiments, the first character field is stored in the corresponding positions of bits 8 to 15 in the first entry, the second character field is stored in the corresponding positions of bits 16 to 23 in the first entry, and the first character quantity identifier field is stored in the corresponding positions of bits 28 to 29 in the first entry. It is understood that in some embodiments, the positions of the first character field, the second character field, and the first character quantity identifier field in the first entry are merely illustrative, and their positions in the first entry can also be other than those of bits 30 to 31. For example, the first character quantity identifier field could be located in the corresponding positions of bits 30 to 31, etc. This application does not limit the scope of these embodiments.
[0162] Figure 6 In (a), the first entry is 32 bits, and the first code length field (e.g.) Figure 6 In (a), the field corresponding to BIT_COUNT is stored in the first character field (e.g., the position of the zeroth to seventh bit in the first table entry). Figure 6 The field corresponding to SYMO in (a) is stored in the corresponding positions of bits 8 to 15 in the first entry, and the second character field (e.g.) Figure 6 Taking the example of SYM1 corresponding to (a) being stored in the corresponding positions of bits 16 to 23 in the first entry, and the first character quantity identifier field being stored in the corresponding positions of bits 28 to 29 in the first entry, a schematic diagram of one type of first entry is illustrated. It can be understood that... Figure 6 The 2 described in the corresponding positions of bits 28 to 29 in (a) is merely illustrative. In the actual index table, the corresponding positions of bits 28 to 29 are the binary values corresponding to 2. It is understood that the contents of the index table in this embodiment are all binary values, and will not be elaborated further.
[0163] like Figure 6 As shown in (a), the first entry may further include a first length quantity identifier field, used to store the quantity information of the length parameters in the first entry. It can be understood that when both the first and second data are characters, the quantity of the length parameters in the first entry is 0, and the first length quantity identifier field includes the binary value corresponding to 0. The first length field can be stored in the corresponding positions of bits 30 to 31 in the first entry.
[0164] In some embodiments, Figure 6 The x field shown in (a) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0165] In some embodiments, if the first data includes a third character and the second data includes a first length parameter, constructing an index relationship between the third Huffman-coded data and the first and second data includes: constructing an index relationship between the third Huffman-coded data and the second entry in the first index table corresponding to the data to be encoded. The second entry includes a second code length field, a third character field, a first length field, and a second character count identifier field.
[0166] The second code length field includes information corresponding to the sum of the lengths of the first Huffman-coded data and the lengths of the second Huffman-coded data. For example, if the first data is the character D mentioned above, the second data is the length parameter 3, the Huffman code corresponding to the character D is 10, and the Huffman code corresponding to the length parameter 3 is 11, then the sum of the lengths of the first Huffman-coded data and the lengths of the second Huffman-coded data is 4, and the second code length field includes the binary value corresponding to 4.
[0167] The third character field includes information corresponding to the third character, and the first length field includes information corresponding to the first length parameter. For example, if the first data is the character D mentioned above, and the second data is the length parameter 3, then the first character field includes the binary value corresponding to the character D, and the second character field includes the binary value corresponding to the length parameter 3.
[0168] The second character count field contains information about the number of characters in the second entry. It can be understood that if there is only one character in the second entry, then the character count for the second entry is 1, and the second character count field includes the binary value corresponding to 1.
[0169] In some embodiments, the second code length field is stored in the corresponding positions of bits 0 through 7 in the second entry.
[0170] In some embodiments, the third character field is stored in the corresponding positions of bits 8 to 15 in the second entry, the second length field is stored in the corresponding positions of bits 16 to 24 in the second entry, and the second character quantity identifier field is stored in the corresponding positions of bits 28 to 29 in the second entry. It is understood that in some embodiments, the positions of the third character field, the first length field, and the second character quantity identifier field in the second entry are merely illustrative, and their positions in the second entry can also be other than those described in this embodiment.
[0171] Figure 6 In (b), the second entry is 32 bits, and the second code length field (e.g.) Figure 6The field corresponding to BIT_COUNT in (b) is stored in the corresponding positions of bits 0 to 7 in the second entry, the third character field is stored in the corresponding positions of bits 8 to 15 in the second entry, and the second length field (e.g. Figure 6 Taking the example of the LEN field in (b) being stored in the corresponding positions of bits 16 to 24 in the second entry and the second character quantity identifier field being stored in the corresponding positions of bits 28 to 29 in the second entry, a schematic diagram of a second entry is illustrated.
[0172] like Figure 6 As shown in (b), the second entry may further include a second length quantity identifier field, used to store the quantity information of the length parameter in the second entry. It can be understood that when one of the first data and the second data is a character and the other is a length parameter, the quantity of the length parameter in the second entry is 1, and the first length quantity identifier field includes the binary value corresponding to 1. The second length field can be stored in the corresponding positions of bits 30 and 31 in the second entry.
[0173] In some embodiments, Figure 6 The x field shown in (b) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0174] 104: Use the first Huffman encoded data, the second Huffman encoded data, and the index relationship as the compressed data corresponding to the first and second data.
[0175] In this embodiment, the Huffman-coded data corresponding to each piece of data in the data to be encoded, along with the index relationship between the Huffman-coded data and the data to be encoded, can be used together as the compressed data of the data to be encoded. For example, the first Huffman-coded data corresponding to the first piece of data, the second Huffman-coded data corresponding to the second piece of data, and the index relationship between the third Huffman-coded data and the first and second pieces of data can be used as the compressed data corresponding to the first and second pieces of data.
[0176] The index relationship between Huffman-coded data and the data to be encoded can be represented by constructing a table of Huffman-coded data and its corresponding index. For example, the index table can include the first index table mentioned above, which can be a character length index table.
[0177] In some embodiments, the index table may further include a distance index table. The distance index table stores the relevant entries corresponding to the distance parameters. For example, each entry in the distance index table may include a code length field, a distance parameter field, and a character count identifier field. The code length field includes data length information corresponding to the distance parameter (e.g., the binary value corresponding to the data length), the distance parameter field includes information corresponding to the distance parameter (e.g., the binary value corresponding to the distance parameter), and the character count identifier field includes the number of characters in the entry (e.g., the binary value corresponding to all characters being 0). The character length index table and the distance index table may include a first-level index table and a second-level index table.
[0178] As mentioned earlier, currently each table lookup can only retrieve one decoded item, such as a character or a length parameter, resulting in numerous indexing operations and a lengthy decoding process. Based on the compression method provided in this application, an index can be constructed corresponding to one character and one length parameter, or an index can be constructed corresponding to two characters. This allows for situations where a single table lookup retrieves one character and one length parameter, or two characters, effectively reducing the number of table lookups and shortening the decoding time.
[0179] Furthermore, the code length fields in each entry (e.g., the first code length field, the second code length field, and other code length fields mentioned later) can be stored in the corresponding positions of bits 0 to 7 in the entry. It can be understood that when the code length field is stored in the lower 8 bits of the entry, during the decoding process, when reading and decoding the first code length field, the uxtb extension operation can be directly used to retrieve the value. That is, the value of the lower 8 bits can be extracted from the WO register using the sub w4,w4,w0,uxtb instruction, and the code length corresponding to this lower 8 bit value can be subtracted from W4. Compared to some implementations where the code length field is stored in higher bits, requiring additional instructions to extract the code length field to a temporary register through shifting operations before subtraction, this approach eliminates the need for additional bit field operations and the use of temporary registers, improving decoding efficiency.
[0180] Furthermore, in the embodiments of this application, the length field (such as the first length field and the second length field mentioned later) stores the actual length of the matching string, that is, the binary value corresponding to the actual length, which corresponds to the total length represented by the aforementioned length code and the extra bits. In this way, there is no need to look up the table to obtain the extra number of bits and calculate the actual length, which can further reduce the use of extra bit field operations and temporary registers and improve decoding efficiency.
[0181] It is understood that in this embodiment of the application, when the Huffman-coded data corresponding to the data to be encoded is equal to the first length mentioned above, the Huffman-coded data can be directly constructed without merging, and an index relationship between the Huffman-coded data and the corresponding uncoded data can be constructed, for example, an index relationship between the Huffman-coded data and the corresponding table entry in the first index table can be constructed.
[0182] When the Huffman-coded data corresponding to the data to be encoded is less than the first length mentioned above, but there is no Huffman-coded data that can be merged, the Huffman-coded data can be directly extended to obtain Huffman-coded data of the first length, and an index relationship can be constructed between the extended Huffman-coded data and the corresponding data to be encoded. For example, an index relationship can be constructed between the extended Huffman-coded data and the corresponding entry in the first index table.
[0183] When the number of Huffman codes corresponding to the data to be encoded is greater than the first length mentioned above, an index relationship between the Huffman encoded data and the corresponding data to be encoded can be constructed by building a secondary index table.
[0184] Thus, the compression method in this application embodiment may also include constructing an index relationship for a character in the data to be encoded, constructing an index relationship for a length parameter in the data to be encoded, constructing an index relationship for a terminator, and constructing a secondary index table for a character, a length parameter, or a terminator in the data to be encoded.
[0185] The following describes a method for constructing an index relationship for a character (e.g., referred to as third data) in the data to be encoded. This method may include:
[0186] Obtain the fifth Huffman-coded data corresponding to the third data in the data to be encoded, where the third data is the fourth character. Construct an index relationship between the fifth Huffman-coded data and the third data, where the fifth Huffman data is the Huffman data of the first length. For example, the third data can be the character C. If the Huffman-coded data corresponding to the third data is 1010, then 1010 can be the fifth Huffman-coded data corresponding to the third data. If the Huffman-coded data corresponding to the third data is 101, then the Huffman-coded data corresponding to the third data needs to be expanded. The expanded first-length Huffman-coded data (e.g., 1010) is the fifth Huffman-coded data corresponding to the third data.
[0187] In some embodiments, constructing the index relationship between the fifth Huffman encoded data and the third data may include: constructing the index relationship between the fifth Huffman encoded data and the third entry in the first index table corresponding to the data to be encoded, wherein the third entry includes a third code length field, a fourth character field, and a third character quantity identifier field.
[0188] The third code length field includes the data length information of the fifth Huffman encoded data; for example, if the third data is the character C, and the fifth Huffman encoded data corresponding to the third data is 1010, that is, the data length of the fifth Huffman encoded data is 4, then the third code length field includes the binary value corresponding to 4.
[0189] The fourth character field includes information corresponding to the fourth character; for example, if the fourth character is the character C, the fourth character field includes the binary value corresponding to the character C.
[0190] The third character quantity identifier field includes the quantity information of characters in the third table entry. For example, if the quantity of characters in the third table entry is 1, then the third character quantity identifier field includes the binary value corresponding to 1.
[0191] In some embodiments, the third code length field may be stored in the corresponding positions of bits 0 through 7 in the third entry.
[0192] In some embodiments, the fourth character field is stored in the corresponding positions of bits 8 to 15 in the third entry, and the third character quantity identifier field is stored in the corresponding positions of bits 28 to 29 in the third entry. It is understood that in some embodiments, the positions of the fourth character field and the third character quantity identifier field in the third entry are merely illustrative, and their positions in the third entry can also be other than those specified in the embodiments of this application.
[0193] Figure 6 In (c), the second entry is 32 bits, and the third code length field (e.g.) Figure 6 The diagram illustrates a third table entry, with the field corresponding to BIT_COUNT in (c) stored in the corresponding positions of bits 0 to 7 in the third table entry, the fourth character field stored in the corresponding positions of bits 8 to 15 in the third table entry, and the third character quantity identifier field stored in the corresponding positions of bits 28 to 29 in the third table entry.
[0194] like Figure 6 As shown in (c), the third entry may also include a third length quantity identifier field, used to store the quantity information of the length parameters in the third entry. It can be understood that if the quantity of length parameters in the third entry is 0, the third length quantity identifier field includes the binary value corresponding to 0. The third length field can be stored in the corresponding positions of bits 30 and 31 in the third entry.
[0195] In some embodiments, Figure 6 The x field shown in (c) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0196] The following describes a method for constructing an index relationship for a length parameter (e.g., referred to as the fourth data) in the data to be encoded. This method may include:
[0197] Obtain the sixth Huffman encoded data corresponding to the fourth data in the data to be encoded. The fourth data is the second length parameter. Construct the index relationship between the sixth Huffman encoded data and the second length parameter.
[0198] In some embodiments, constructing an index relationship between the sixth Huffman encoded data and the second length parameter includes: constructing an index relationship between the sixth Huffman encoded data and the fourth entry in the first index table corresponding to the data to be encoded, wherein the fourth entry includes a fourth code length field, a second length field, and a fourth character count identifier field.
[0199] The fourth code length field includes the data length information of the sixth Huffman encoded data; for example, if the fourth data is the length parameter 5, and the sixth Huffman encoded data is the Huffman data 1000 corresponding to the length parameter 5, that is, the data length of the sixth Huffman encoded data is 4, then the fourth code length field includes the binary value corresponding to 4.
[0200] The second length field includes information corresponding to the second length parameter; for example, the fourth data is the length parameter 5, and the fifth character field includes the binary value corresponding to the length parameter 5.
[0201] The fourth character count field contains information about the number of characters in the fourth entry. For example, if the number of characters in the fourth entry is 0, the fourth character count field will contain the binary value corresponding to 0.
[0202] Figure 6 In (d), the fourth entry is 32 bits, and the fourth code length field (e.g.) Figure 6 The diagram illustrates a fourth table entry, with the field corresponding to BIT_COUNT in (d) stored in the corresponding positions of bits 0 to 7 in the fourth table entry, the second length field stored in the corresponding positions of bits 16 to 24 in the second table entry, and the fourth character quantity identifier field stored in the corresponding positions of bits 28 to 29 in the fourth table entry.
[0203] like Figure 6 As shown in (d), the fourth entry may also include a fourth length quantity identifier field, used to store the quantity information of the length parameter in the fourth entry. It can be understood that the quantity of the length parameter in the fourth entry is 1, and the fourth length quantity identifier field includes the binary value corresponding to 1. The fourth length field can be stored in the corresponding positions of bits 30 and 31 in the fourth entry.
[0204] In some embodiments, Figure 6The x field shown in (d) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0205] The following describes a method for constructing a secondary index table for a single character (e.g., the fifth data) in the data to be encoded. The method may include:
[0206] Obtain the seventh Huffman-coded data corresponding to the fifth data in the data to be encoded, where the seventh Huffman-coded data is greater than the first length, and the fifth data is the fifth character; construct the index relationship between the eighth Huffman-coded data in the seventh Huffman-coded data and the fifth entry of the first index table; where the eighth Huffman-coded data is the Huffman-coded data from the 1st to the Nth position in the seventh Huffman-coded data, and N is the numerical value corresponding to the first length. The fifth entry includes a fifth code length field, a first storage location field, a fifth character count identifier field, and an offset field.
[0207] The fifth code length field includes the length information of the eighth Huffman data. It can be understood that the length of the eighth Huffman data is the first length; for example, if the first length is 4, then the fifth code length field includes the binary value corresponding to 4.
[0208] The first storage location field includes the starting address of the second index table, which could be, for example, the address of the first row of the second index table. The first index table can be called a first-level index table, and the second index table can be called a second-level index table.
[0209] The fifth character count identifier field includes the number of characters in the fifth table entry. It can be understood that there are no characters in the fifth table entry, and the characters exist in the sixth table entry of the second index table. Therefore, the number of characters in the fifth table entry is 0, and the fifth character count identifier field includes the binary value corresponding to 0.
[0210] The offset field includes the offset information of the address of the sixth entry in the second index table relative to the starting address. The offset information is determined based on the ninth Huffman encoded data in the seventh Huffman data, which is the Huffman encoded data after the Nth bit in the seventh Huffman encoded data.
[0211] In some embodiments, corresponding offsets can be assigned to data in the Huffman-coded data that exceeds the first length, and the position of the entry in the secondary index table corresponding to the Huffman-coded data can be determined based on the offsets.
[0212] For example, if the Huffman encoded data for the character E is 10001 and the Huffman encoded data for the character F is 10000, and both the Huffman encoded data for characters E and F exceed the first length of 4, then an offset of 0 can be assigned to the fifth bit 1 in 10001, and an offset of 1 can be assigned to the fifth bit 1 in 10000. The entry in the first row of the second index table is then used as the entry in the second index table corresponding to 10001. The entry in the second row of the second index table is then used as the entry in the second index table corresponding to 10000. For example, if the seventh Huffman encoded character is the aforementioned character E, then the offset field includes the binary value corresponding to 0.
[0213] Thus, when decoding the seventh Huffman code, the sixth entry can be determined as the entry corresponding to the first row of the second index table based on the binary value corresponding to offset field 0 and the starting address of the second index table.
[0214] In some embodiments, the sixth entry includes a sixth code length field and a fifth character field; the sixth code length field is used to store the length information of the seventh Huffman encoded data; the fifth character field is used to store the information corresponding to the fifth character.
[0215] In some embodiments, the sixth entry may include 32 bits, with the fifth code length field stored in the corresponding positions of bits 0 to 7 in the fifth entry, the first storage position field stored in the corresponding positions of bits 8 to 23 in the fifth entry, the fifth character quantity identifier field stored in the corresponding positions of bits 28 to 29 in the fifth entry, and the offset field stored in the corresponding positions of bits 24 to 27 in the fifth entry.
[0216] Figure 6 In (e), the fifth entry is 32 bits, and the fifth code length field (e.g.) Figure 6 The field corresponding to (e)BIT_COUNT is stored in the corresponding positions of bits 0 to 7 in the fifth entry, and the first storage position field (e.g.) Figure 6 The field corresponding to SUB_TBL_BASE in (e) is stored in the corresponding positions of bits 8 to 23 in the fifth entry; the fifth character quantity identifier field is stored in the corresponding positions of bits 28 to 29 in the fifth entry; the offset field (e.g.) Figure 6 Taking the field corresponding to SUB_BITS in (e) as an example, which is stored in the corresponding positions of bits 24 to 27 in the fifth table entry, a schematic diagram of the fifth table entry is shown.
[0217] In some embodiments, Figure 6 The x field shown in (e) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0218] In some embodiments, Figure 6 In the entry shown in (e), the positions of bits 30-31 can be the binary values corresponding to 3. The entry indicates that there is neither a length parameter nor character information. The positions of bits 30-31 can also be empty fields or other arbitrary identifiers. This application embodiment does not limit this.
[0219] In some embodiments, the sixth code length field is stored in the corresponding positions of the tenth to fifteenth bits in the sixth entry, and the fifth character field is stored in the corresponding positions of the zeroth to ninth bits in the sixth entry.
[0220] Figure 6 (f) uses a sixth-code-length field (e.g.) Figure 6 The field corresponding to BIT_COUNT in (f) is stored in the corresponding positions of bits 10 to 15 in the sixth table entry, and the fifth character field (e.g.) Figure 6 Taking the field corresponding to SYM in (f) as an example, which is stored in the corresponding positions of bits 0 to 9 in the sixth table entry, a schematic diagram of the sixth table entry is shown.
[0221] The following describes a method for constructing an index relationship for the terminator. The method may include: obtaining the tenth Huffman encoded data corresponding to the terminator; and constructing an index relationship between the tenth Huffman encoded data and the terminator.
[0222] In some embodiments, constructing the index relationship between the tenth Huffman encoded data and the end symbol includes: constructing the index relationship between the tenth Huffman encoded data and the seventh entry in the first index table corresponding to the data to be encoded; wherein the seventh entry includes a seventh code length field, an end symbol information field, and a sixth character quantity identifier field;
[0223] The seventh code length field includes the data length information of the tenth Huffman encoded data; for example, if the data length of the tenth Huffman encoded data is 4, then the seventh code length field includes the binary value corresponding to 4.
[0224] The terminator information field includes terminator information; for example, the terminator information field includes the binary value corresponding to the terminator 256. In some embodiments, the terminator information field may also include the binary value corresponding to 0.
[0225] The sixth character count field includes the number of characters in the seventh entry. For example, if the number of characters in the seventh entry is 0, then the sixth character count field includes the binary value corresponding to 0.
[0226] In some embodiments, the seventh entry may include 32 bits, with the seventh code length field stored in the corresponding positions of bits 0 to 7 in the seventh entry, the associative information field stored in the corresponding positions of bits 8 to 23 in the fifth entry, and the fifth character quantity identifier field stored in the corresponding positions of bits 28 to 29 in the seventh entry.
[0227] Figure 6 In (g), the seventh entry is 32 bits, and the seventh code length field (e.g.) Figure 6 The diagram illustrates a seventh entry, with the field corresponding to (g)BIT_COUNT stored in the corresponding positions of bits 0 to 7 in the seventh entry, the end-of-entry character information field stored in the corresponding positions of bits 8 to 23 in the fifth entry, and the fifth character quantity identifier field stored in the corresponding positions of bits 28 to 29 in the seventh entry.
[0228] In some embodiments, Figure 6 The x field shown in (g) can be an empty field, or other content can be added according to actual needs. This application embodiment does not limit this.
[0229] In some embodiments, Figure 6 In the entry shown in (g), the positions of bits 30-31 can be the binary value corresponding to 3. The entry indicates that there is neither a length parameter nor character information. The positions of bits 30-31 can also be empty fields or other arbitrary identifiers. This application embodiment does not limit this.
[0230] Corresponding to the compression method described above, the decompression method in the embodiments of this application will be described in detail below.
[0231] Figure 7 The schematic diagram illustrates a decompression method according to an embodiment of this application, as shown below. Figure 7 As shown, the decompression methods include:
[0232] 201: Obtain the eleventh Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the corresponding data in the compressed data.
[0233] In some embodiments, the compressed data can be compressed data obtained by the compression method described above, or it can be referred to as compressed data to be Huffman decoded. The index relationship between the Huffman-coded data and the corresponding data in the compressed data can be the index relationship between the Huffman-coded data and the entries in the corresponding index table.
[0234] 202: Based on the eleventh Huffman encoded data and the index relationship, determine the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data. The first decoded data includes first data and second data. The data length of the Huffman encoded data corresponding to the first decoded data includes the sum of the data lengths of the first Huffman encoded data corresponding to the first data and the second Huffman encoded data corresponding to the second data. The first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman encoded data and the second Huffman encoded data is less than or equal to a first length. Furthermore, both the first data and the second data are characters, or one of the first data and the second data is a character and the other is a length parameter, with the length parameter following the character.
[0235] In some embodiments, both the first data and the second data can be characters. For example, as mentioned in the example 101 above, if the eleventh Huffman encoded data is 0001, the corresponding table entry can be determined based on 0001 and the index relationship between the Huffman encoded data in the compressed data and each entry in the character length index table, and the decoded data can be obtained from the information in the corresponding table entry. For example, the decoded data may include characters A and B, and the sum of the data lengths of characters A and the corresponding Huffman encoded data can be decoded to be 4.
[0236] In some embodiments, one of the first data and the second data is a character, and the other data is a length parameter, with the length parameter following the character.
[0237] For example, if the eleventh Huffman encoded data is 1011, the corresponding table entry can be determined based on 1011 and the index relationship between the Huffman encoded data in the compressed data and each entry in the character length index table. The decoded data can be obtained from the information in the corresponding table entry. For example, the decoded data can include the character D and the length parameter 3, and the sum of the data lengths of the Huffman encoded data corresponding to the character D and the length parameter 3 can be decoded to be 4.
[0238] In some embodiments, if the first data includes a first character, the second data includes a second character, and the index relationship includes a first index table; determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship includes:
[0239] The first entry is obtained from the first index table based on the 11-Huffman encoded data. The first entry includes a first code length field, a first character field, a second character field, and a first character count identifier field. The first code length field includes information corresponding to the sum of the data lengths of the first Huffman encoded data and the data lengths of the second Huffman encoded data. The first character field includes information corresponding to the first character. The second character field includes information corresponding to the second character. The first character count identifier field includes the number of characters in the first entry.
[0240] First data is determined based on the first character field, second data is determined based on the second character field, and the sum of the data lengths of the first Huffman-coded data corresponding to the first data and the second Huffman-coded data corresponding to the second data is determined based on the first code length field.
[0241] The contents of the first table entry are described in the section on compression methods, and will not be repeated here.
[0242] In some embodiments, determining first data based on a first character field and determining second data based on a second character field may include:
[0243] The information at a preset position in the first table entry is read. This preset position information includes a first character field and a second character field. The decoded data corresponding to the preset position information in the first table entry is written to the first storage location of the electronic device. The decoded data corresponding to the preset position information includes first data corresponding to the first character field and second data corresponding to the second character field. The write address corresponding to the next written data is determined based on the first character count identifier field. This write address is located after the first storage location.
[0244] It is understood that the preset position mentioned in this application embodiment can be the maximum data range of the storage location corresponding to the character information in each entry of the first index table. For example, the preset position mentioned in this application embodiment can be the position from the eighth bit to the twenty-third bit in the entry. In this way, it can be guaranteed that if there is character information in the entry, the character information can be read from the preset position. For example, when there is two characters in an entry, that is, corresponding to the first entry mentioned above, the information corresponding to the two characters can be read from the preset position. When there is one character in an entry, such as corresponding to the second entry mentioned above, the information corresponding to the one character and some other information unrelated to the character information can be read from the preset position. When there is zero characters in an entry, such as corresponding to the fourth entry mentioned above, the information unrelated to the character information can be read from the preset position.
[0245] It can be understood that reading the information at the preset position of the first table entry can be used to read the position information of bits 8 to 23 of the second table entry. Since the first character field and the second character field in the first table entry are stored in bits 8 to 23, the first character field and the second character field can be read, and the decoded data of the first character field and the second character field can be written to the second storage location.
[0246] In this embodiment of the application, if the number of characters represented by the first character identifier field is 2, then the write address corresponding to the next written data is located after the first storage location, that is, after the number of two characters.
[0247] In this embodiment of the application, the write address corresponding to the next written data can be identified by the next out pointer. For example, as... Figure 8 As shown in (a), the next out pointer is located after the character D. If the eleventh Huffman encoded data is decoded and the number of characters represented by the first character identifier field (CNT) is 2, and the decoded data of the first and second character fields is FG, then the data written is FG, and the position of the next out pointer is as follows. Figure 8 As shown in (b), the position is after G, that is, after the next data is written to G.
[0248] In some embodiments, if the first data includes a third character and the second data includes a first length parameter, determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship includes: obtaining a second entry from a first index table based on the eleventh Huffman encoded data, wherein the second entry includes a second code length field, a third character field, a first length field, and a second character quantity identifier field. The second code length field includes data length information of the first Huffman encoded data, data length information of the second Huffman encoded data, and extended length parameter information. The third character field includes information corresponding to the third character. The first length field includes information corresponding to the first length parameter. The second character quantity identifier field includes the number of characters in the second entry. Determining the first data based on the third character field, determining the second data based on the first length field, and determining the sum of the data length of the first Huffman encoded data corresponding to the first data and the data length of the second Huffman encoded data corresponding to the second data based on the second code length field.
[0249] In some embodiments, determining first data based on a third character field and second data based on a first length field includes: reading information at a preset position in a second table entry, wherein the information at the preset position in the second table entry includes a portion of the third character field and the first length field; writing the decoded data corresponding to the information at the preset position in the second table entry into a second storage location of the electronic device, wherein the decoded data at the preset position in the second table entry includes the first data corresponding to the first character field; determining the write address corresponding to the next written data based on a first character count identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the first data in the second storage location; determining the second data based on the first length field and writing the second data after the storage location corresponding to the first data.
[0250] It can be understood that reading the information at the preset position of the second entry can be equivalent to reading the position information from the eighth to the twenty-third bit of the second entry. Since the third character field in the second entry is stored in bits eight through fifteen, and the first length field is stored in bits sixteen through twenty-four, a portion of the third character field and the first length field can be read. Furthermore, the decoded data of this portion of the third character field and the first length field can be written to the second storage location.
[0251] In this embodiment of the application, if the number of characters represented by the second character identifier field is 1, then the write address corresponding to the next written data is located after the storage location corresponding to the first data in the second storage location, that is, after the storage location of 1 character.
[0252] In this embodiment of the application, the write address corresponding to the next written data can be identified by the next out pointer. For example, as Figure 8 As shown in (c), if the number of characters represented by the second character identifier field CNT is 1, the decoded data (i.e., the written data) corresponding to part of the third character field and the first length field is EX, and the position of the next out pointer is after E, that is, after the next written data is written to E, X is overwritten.
[0253] As mentioned earlier, currently each table lookup can only yield one decoded item, such as a character or a length parameter, resulting in numerous indexing operations and a lengthy decoding process. The decompression method provided in this application embodiment allows for situations where a single table lookup decodes one character and one length parameter, or two characters, effectively reducing the number of table lookups and shortening the decoding time.
[0254] Corresponding to the compression method in this application embodiment, it may include constructing an index relationship for a character in the data to be encoded, constructing an index relationship for a length parameter in the data to be encoded, constructing an index relationship for a terminator, and constructing a secondary index table for a character, a length parameter, or a terminator in the data to be encoded. The decompression method in this application embodiment may include decoding a single character, a length parameter, or a terminator, as well as decoding based on a secondary index table. These will be described separately below.
[0255] The following describes the case where a single character (e.g., the third data) is decoded. Decompression methods may include:
[0256] Obtain the fifth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the corresponding data in the compressed data; based on the fifth Huffman-coded data and the index relationship, determine the data length of the second decoded data corresponding to the fifth Huffman-coded data and the Huffman-coded data corresponding to the third decoded data, wherein the second decoded data includes the third data, and the third data is the fourth character.
[0257] In some embodiments, determining the second decoded data corresponding to the fifth Huffman encoded data and the data length of the Huffman encoded data corresponding to the second decoded data based on the fifth Huffman encoded data and the index relationship includes: obtaining a third entry from a first index table based on the fifth Huffman encoded data, wherein the third entry includes a third code length field, a fourth character field, and a third character quantity identifier field, the third code length field includes data length information of the fifth Huffman encoded data, the fourth character field includes information corresponding to the fourth character, and the third character quantity identifier field includes the number of characters in the third entry; determining third data based on the fourth character field, and determining the data length of the Huffman encoded data corresponding to the third data based on the third code length field.
[0258] The relevant content of the third item is as described above and will not be repeated here.
[0259] In some embodiments, determining the third data based on the fourth character field includes: reading information at a preset position in the third entry; writing the decoded data corresponding to the information at the preset position in the third entry into the third storage location of the electronic device, wherein the decoded data corresponding to the information at the preset position in the third entry includes the third data corresponding to the third character field; and determining the write address corresponding to the next written data based on the third character quantity identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the third data in the third storage location.
[0260] It can be understood that reading the preset position information of the third table entry can be the position information of bits 8 to 23 of the third table entry. Since the third character field in the third table entry is stored in bits 8 to 15, the third character field can be read and stored in the third storage location. Since the third character count field indicates the number of characters as 1, the write address corresponding to the next data to be written can be located after the storage location corresponding to the third data in the third storage location. That is, the position of the next out pointer is located after the storage location corresponding to the third data.
[0261] The following describes the case where a length parameter (e.g., the fourth data point) is decoded. Decompression methods may include:
[0262] Obtain the sixth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data. Based on the sixth Huffman-coded data and the index relationship, determine the third decoded data corresponding to the sixth Huffman-coded data and the data length of the Huffman-coded data corresponding to the third decoded data. The third decoded data includes the fourth data, which is the second length parameter.
[0263] In some embodiments, determining the third decoded data corresponding to the sixth Huffman encoded data and the data length of the Huffman encoded data corresponding to the third decoded data based on the sixth Huffman encoded data and the index relationship includes:
[0264] The fourth entry is obtained from the first index table based on the sixth Huffman encoded data. The fourth entry includes a fourth code length field, a fifth character field, a second length field, and a fourth character quantity identifier field. The fourth code length field includes the data length information of the sixth Huffman encoded data, the fifth character field includes the information corresponding to the second length parameter, and the fourth character quantity identifier field includes the number of characters in the fourth entry.
[0265] The relevant content of the fourth item is as described above and will not be repeated here.
[0266] The fourth data is determined based on the second length field, and the data length of the Huffman-coded data corresponding to the fourth data is determined based on the fourth code length field.
[0267] In some embodiments, determining the third decoded data corresponding to the sixth Huffman encoded data and the data length of the Huffman encoded data corresponding to the third decoded data based on the sixth Huffman encoded data and the index relationship may further include: reading information at a preset position in the fourth entry and writing the decoded data corresponding to the information at the preset position in the fourth entry into the fourth storage location of the electronic device. The write address corresponding to the next written data is determined based on the fourth character count identifier field, wherein the write address corresponding to the next written data is located at the starting position in the fourth storage location.
[0268] It can be understood that reading the information at the preset position of the fourth entry can be equivalent to reading the position information from the eighth to the twenty-third bit of the fourth entry. Since the second length field in the fourth entry is stored in bits sixteen to twenty-four, a portion of the second length field can be read. Furthermore, the decoded data of this portion of the second length field can be written to the fourth storage location.
[0269] In this embodiment of the application, if the number of characters represented by the fourth character identifier field is 0, then the write address corresponding to the next written data is located at the beginning of the fourth storage location.
[0270] In this embodiment of the application, the write address corresponding to the next written data can be identified by the next out pointer. For example, as Figure 8 As shown in (d), the number of characters represented by the fourth character identifier field, CNT, is 0. The decoded data (i.e., the written data) corresponding to part of the second length field is XX. The position of the next out pointer is at the beginning of XX, that is, the next written data is written to the beginning of XX, overwriting XX.
[0271] The following describes the decoding based on a two-level index table. Decompression methods may include:
[0272] Obtain the eighth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data.
[0273] The fifth entry in the first index table is determined based on the eighth Huffman coded data and the index relationship. The fifth entry includes a fifth code length field, a first storage location field, a fifth character count identifier field, and an offset field. The fifth code length field includes the length information of the eighth Huffman data. The first storage location field includes the starting address of the second index table. The fifth character count identifier field includes the character count information in the fifth entry. The offset field includes the offset information of the address of the sixth entry in the second index table relative to the starting address. The offset information is determined based on the ninth Huffman coded data in the seventh Huffman data. The ninth Huffman coded data is the Huffman coded data after the Nth bit in the seventh Huffman coded data. The eighth Huffman coded data is the Huffman coded data from the 1st bit to the Nth bit in the seventh Huffman coded data, where N is the value corresponding to the first length.
[0274] The sixth entry in the second index table is obtained based on the offset information and the starting position information of the second index table. The sixth entry includes a sixth code length field and a fifth character field. The sixth code length field is used to store the data length information of the seventh Huffman encoded data, and the fifth character field is used to store the information corresponding to the fifth character. The seventh Huffman encoded data includes the eighth Huffman encoded data and the ninth Huffman encoded data.
[0275] The fifth data is determined based on the fifth character field, and the length of the Huffman-coded data corresponding to the fifth data is determined based on the sixth code length field.
[0276] The contents of the fifth and sixth entries can be as described above, and will not be repeated here.
[0277] In some embodiments, after determining the fifth entry in the first index table based on the eighth Huffman encoded data and the index relationship, the steps of reading the information at the preset position in the fifth entry, writing the decoded data corresponding to the information at the preset position in the fifth entry into the corresponding storage location of the electronic device, and determining the write address corresponding to the next written data based on the fifth character quantity identifier field can also be performed. These steps will not be elaborated here.
[0278] The following describes the decoding of the end-of-compression character. Decompression methods may include:
[0279] Obtain the tenth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data; determine the fourth decoded data corresponding to the tenth Huffman-coded data and the data length of the Huffman-coded data corresponding to the fourth decoded data based on the tenth Huffman-coded data and the index relationship, wherein the fourth decoded data includes an end character.
[0280] In some embodiments, determining the fourth decoded data corresponding to the tenth Huffman encoded data and the data length of the Huffman encoded data corresponding to the fourth decoded data based on the tenth Huffman encoded data and the index relationship includes: obtaining a seventh entry from a first index table based on the tenth Huffman encoded data, wherein the seventh entry includes a seventh code length field, an end-of-character information field, and a sixth character quantity identifier field, the seventh code length field including data length information of the tenth Huffman encoded data, the end-of-character information field including end-of-character information, and the sixth character quantity identifier field including the number of characters in the seventh entry; determining an end-of-character based on the end-of-character information field, and determining the data length of the Huffman encoded data corresponding to the end-of-character based on the seventh code length field.
[0281] The content of the seventh item can be as described above, and will not be repeated here.
[0282] Figure 9 A simplified flowchart illustrating a decompression method according to an embodiment of this application is shown. Figure 9 As shown, the decompression method in this embodiment can first look up the first-level index table of the character length table, such as the first index table mentioned in this embodiment, to obtain the corresponding table entry, then read the information at a preset position (e.g., the eighth bit to the twenty-third bit), copy the decoded data corresponding to the information at the preset position, and write the decoded data corresponding to the information at the preset position into the corresponding storage location. The information at the preset position may include the number of characters (lit_num) represented by the character quantity identifier field in the table entry. After obtaining lit_num characters, lit_num characters can be copied and written into the corresponding storage location.
[0283] If a table entry contains two characters (i.e., only characters and no length parameter), then after copying the two characters and writing them to the corresponding storage location, the next table lookup will be performed.
[0284] If the table entry includes a length parameter, that is, the length code corresponding to the length parameter (i.e., the binary value corresponding to the length parameter), then after decoding to obtain the length parameter, the first length of data to be decoded is obtained from the compressed data, and a distance Huffman lookup table is performed to obtain the distance parameter. Based on the dictionary encoding principle, the distance parameter and the length parameter, the corresponding string is determined, and the string is copied and written to the corresponding storage location.
[0285] If the table entry includes a terminator, that is, includes the terminator's corresponding terminator code (i.e., the binary value corresponding to the terminator), then the table lookup for that data block ends, and the table lookup for the next data block begins.
[0286] If the table entry contains information corresponding to a second-level table (such as the offset information segment mentioned above, the starting address of the second-level table, etc.), then the second-level table is searched to obtain the corresponding index result. For example, if the second-level table search yields a length code, then a distance Huffman lookup is performed to obtain the distance parameter. Based on the dictionary encoding principle, the distance parameter, and the length parameter, the corresponding string is determined, and the string is copied and written to the corresponding storage location. If the second-level table search yields an end code, then the table search for this data block ends, and the table search for the next data block begins. If the second-level table search yields a character code, then the decoded character code is copied, and the character is written to the corresponding storage location.
[0287] Understandable. Figure 4a and 4b The decompression method mentioned above requires determining whether to write characters using the OP field. If characters are needed, they are written; if a length parameter is needed, the length parameter is written. Figure 4a and 4b The decompression process requires branch instructions to determine whether to write a character. Understandably, the branching process is complex, impacting the efficiency of the CPU's pipelined instruction processing. This results in excessively long decompression times, affecting decompression efficiency and consuming significant CPU resources.
[0288] Based on the decompression method provided in this application, characters can be written by reading information from a preset position (e.g., bits 8 to 23), copying the decoded data corresponding to the information at the preset position, and writing the decoded data corresponding to the information at the preset position into the corresponding storage location. This achieves character writing through speculative character generalization operations, completing all possible character processing operations even when the table entry type is uncertain. This reduces the number of complex branch instructions, effectively reducing pipeline blocking caused by CPU data dependencies, improving the efficiency of CPU pipelined instruction processing, shortening decompression time, increasing decompression efficiency, and reducing CPU resource utilization. Furthermore, writing two characters at once can also effectively reduce character processing operations, further improving decompression efficiency.
[0289] Furthermore, based on the decompression method provided in the embodiments of this application, there may be cases where a single table lookup decodes one character and one length parameter, or a single table lookup decodes two characters. This can effectively reduce the number of table lookups during the decoding process, shorten the decoding time, and further improve decompression efficiency.
[0290] The hardware structure of the electronic device in this application embodiment will be described below using electronic device 100 as an example. It can be understood that... Figure 10 A schematic diagram of the structure of an electronic device 100 is shown. For example... Figure 10As shown, the electronic device 100 includes a processor 110, a power module 140, a memory 180, a mobile communication module 130, a wireless communication module 120, a sensor module 190, an audio module 150, a camera 170, an interface module 160, buttons 101, and a display screen 102, etc.
[0291] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.
[0292] Processor 110 may include one or more processing units, such as processing modules or circuits of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Micro-programmed Control Unit (MCU), Artificial Intelligence (AI) processor, or Field Programmable Gate Array (FPGA). Different processing units may be independent devices or integrated into one or more processors. Processor 110 may include storage units for storing instructions and data. In some embodiments, the storage unit in processor 110 is a cache memory 180. It is understood that the processor can be used to execute the encoding and decoding methods mentioned in the embodiments of this application.
[0293] Figure 11 This diagram illustrates another structural design of an electronic device 100 according to an embodiment of this application. For example... Figure 11 As shown, the electronic device 100 may include a software structure and a hardware structure. The software structure may include applications and an acceleration library. Applications may include various applications in the electronic device, such as mobile applications, which may include third-party applications, system applications, etc. The acceleration library may include a database of algorithms corresponding to compression and decompression methods, such as the zlib library, to support the compression and decompression functions of the applications. The hardware may include a processor, which can be used to execute the compression and decompression methods in this embodiment. The processor may be an ARM64 architecture processor, etc.
[0294] This application provides an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to perform the encoding and decoding methods mentioned in this application.
[0295] This application provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a first terminal device, the method on the first terminal device side of the interaction method in this application is implemented. Or, when the program or instructions are executed by a second terminal device, the encoding method and decoding method mentioned in this application are implemented.
[0296] This application provides a computer program product, including instructions, which, when executed, cause the encoding and decoding methods mentioned in this application to be implemented.
[0297] This application provides a chip including a processor coupled to a memory for executing computer programs or instructions stored in the memory, thereby enabling the chip to implement the encoding and decoding methods mentioned in this application.
[0298] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.
[0299] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor, a microcontroller, an application-specific integrated circuit, or a microprocessor.
[0300] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.
[0301] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, optical discs, read-only memory, magneto-optical disks, random access memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.
[0302] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.
[0303] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.
[0304] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.
[0305] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.
Claims
1. A compression method, characterized in that, For use in electronic devices, the method includes: Obtain the first Huffman encoded data corresponding to the first data in the data to be encoded, and the second Huffman encoded data corresponding to the second data in the data to be encoded, wherein the first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman encoded data and the second Huffman encoded data is less than or equal to the first length, and both the first data and the second data are characters, or one of the first data and the second data is a character and the other data is a length parameter, and the length parameter is located after the character; The first Huffman-coded data and the second Huffman-coded data are concatenated to obtain the third Huffman-coded data, the length of which is equal to the first length. Construct an index relationship between the third Huffman-coded data and the first and second data; The first Huffman-coded data, the second Huffman-coded data, and the index relationship are used as the compressed data corresponding to the first data and the second data.
2. The compression method according to claim 1, characterized in that, Corresponding to the first data including a first character and the second data including a second character, the step of constructing the index relationship between the third Huffman-coded data and the first and second data includes: Construct an index relationship between the third Huffman-coded data and the first entry in the first index table corresponding to the data to be encoded. The first table entry includes a first code length field, a first character field, a second character field, and a first character quantity identifier field; The first code length field includes information corresponding to the sum of the data length of the first Huffman encoded data and the data length of the second Huffman encoded data; The first character field includes information corresponding to the first character, and the second character field includes information corresponding to the second character; The first character quantity identifier field includes the quantity information of characters in the first table entry.
3. The compression method according to claim 2, characterized in that, The first code length field is stored in the corresponding positions of bits 0 to 7 in the first table entry.
4. The compression method according to claim 1, characterized in that, Corresponding to the first data including a third character, and the second data including a first length parameter, the step of constructing the index relationship between the third Huffman-coded data and the first and second data includes: Construct an index relationship between the third Huffman-coded data and the second entry in the first index table corresponding to the data to be encoded. The second table entry includes a second code length field, a third character field, a first length field, and a second character quantity identifier field; The second code length field includes information corresponding to the sum of the data length of the first Huffman encoded data and the data length of the second Huffman encoded data; The third character field includes information corresponding to the third character, and the first length field includes information corresponding to the first length parameter. The second character quantity identifier field includes the number of characters in the second table entry.
5. The compression method according to claim 4, characterized in that, The second code length field is stored in the corresponding positions of bits 0 to 7 in the second table entry.
6. The compression method according to any one of claims 1-5, characterized in that, The step of concatenating the first Huffman-coded data and the second Huffman-coded data to obtain the third Huffman-coded data includes: If the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is less than the first length, the first Huffman-coded data and the second Huffman-coded data are merged to obtain the fourth Huffman-coded data, and the third Huffman-coded data is obtained by extending the encoding of the fourth Huffman-coded data. If the sum of the lengths of the first Huffman-coded data and the second Huffman-coded data is equal to the first length, the first Huffman-coded data and the second Huffman-coded data are merged to obtain the third Huffman-coded data.
7. The compression method according to any one of claims 1-6, characterized in that, The method further includes: Obtain the fifth Huffman encoded data corresponding to the third data in the data to be encoded, wherein the third data is the fourth character; Construct an index relationship between the fifth Huffman-coded data and the third data.
8. The compression method according to claim 7, characterized in that, The construction of the index relationship between the fifth Huffman-coded data and the third data includes: Construct an index relationship between the fifth Huffman-coded data and the third entry in the first index table corresponding to the data to be encoded. The third entry includes a third code length field, a fourth character field, and a third character quantity identifier field; The third code length field includes the data length information of the fifth Huffman encoded data; The fourth character field includes information corresponding to the fourth character; The third character quantity identifier field includes the quantity information of the characters in the third table entry.
9. The compression method according to any one of claims 1-8, characterized in that, The method further includes: Obtain the sixth Huffman-coded data corresponding to the fourth data in the data to be encoded, wherein the fourth data is the second length parameter. Construct the index relationship between the sixth Huffman encoded data and the second length parameter.
10. The compression method according to claim 9, characterized in that, The construction of the index relationship between the sixth Huffman-coded data and the second length parameter includes: Construct an index relationship between the sixth Huffman-coded data and the fourth entry in the first index table corresponding to the data to be encoded. The fourth entry includes a fourth code length field, a second length field, and a fourth character quantity identifier field; The fourth code length field includes the data length information of the sixth Huffman encoded data; The second length field includes information corresponding to the second length parameter; The fourth character quantity identifier field includes the quantity information of the characters in the fourth table entry.
11. The compression method according to any one of claims 1-10, characterized in that, The method further includes: Obtain the seventh Huffman encoded data corresponding to the fifth data in the data to be encoded, wherein the seventh Huffman encoded data is greater than the first length, and the fifth data is the fifth character; Construct the index relationship between the eighth Huffman-coded data in the seventh Huffman-coded data and the fifth entry of the first index table; The eighth Huffman encoded data is the Huffman encoded data of the first to Nth bits of the seventh Huffman encoded data, where N is the value corresponding to the first length; The fifth entry includes a fifth code length field, a first storage location field, a fifth character quantity identifier field, and an offset field; The fifth code length field includes the length information of the eighth Huffman data; The first storage location field includes the starting address of the second index table; The fifth character quantity identifier field includes the character quantity information of the fifth table entry; The offset field includes offset information of the address of the sixth entry in the second index table relative to the starting address. The offset information is determined based on the ninth Huffman encoded data in the seventh Huffman data. The ninth Huffman encoded data is the Huffman encoded data after the Nth bit in the seventh Huffman encoded data. The sixth entry includes a sixth code length field and a fifth character field; The sixth code length field is used to store the length information of the seventh Huffman encoded data; The fifth character field is used to store the information corresponding to the fifth character.
12. The compression method according to any one of claims 1-11, characterized in that, Also includes: Retrieve the tenth Huffman encoded data corresponding to the end-of-character symbol; Construct the index relationship between the tenth Huffman encoded data and the terminator.
13. The compression method according to claim 12, characterized in that, The construction of the index relationship between the tenth Huffman encoded data and the terminator includes: Construct an index relationship between the tenth Huffman encoded data and the seventh entry in the first index table corresponding to the data to be encoded; The seventh entry includes a seventh code length field, an end character information field, and a sixth character quantity identifier field; The seventh code length field includes the data length information of the tenth Huffman encoded data; The terminator information field includes the terminator information; The sixth character quantity identifier field includes the quantity information of the characters in the seventh table entry.
14. A decompression method, characterized in that, For use in electronic devices, the method includes: Obtain the eleventh Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the corresponding data in the compressed data; Based on the eleventh Huffman encoded data and the index relationship, the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data are determined. The first decoded data includes first data and second data. The data length of the Huffman encoded data corresponding to the first decoded data includes the sum of the data length of the first Huffman encoded data corresponding to the first data and the data length of the second Huffman encoded data corresponding to the second data. The first data and the second data are adjacent data, and the sum of the data lengths of the first Huffman encoded data and the second Huffman encoded data is less than or equal to the first length. The first data and the second data are both characters, or one of the first data and the second data is a character and the other data is a length parameter, and the length parameter is located after the character.
15. The decompression method according to claim 14, characterized in that, The first data includes a first character, the second data includes a second character, and the index relationship includes a first index table; The step of determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship includes: Based on the eleven-Huffman encoded data, a first entry is obtained from the first index table. The first entry includes a first code length field, a first character field, a second character field, and a first character quantity identifier field. The first code length field includes information corresponding to the sum of the data length of the first Huffman encoded data and the data length of the second Huffman encoded data. The first character field includes information corresponding to the first character. The second character field includes information corresponding to the second character. The first character quantity identifier field includes the number of characters in the first entry. The first data is determined based on the first character field, the second data is determined based on the second character field, and the sum of the data lengths of the first Huffman-coded data corresponding to the first data and the second Huffman-coded data corresponding to the second data is determined based on the first code length field.
16. The decompression method according to claim 15, characterized in that, Determining the first data based on the first character field and determining the second data based on the second character field includes: Read information from a preset position in the first table entry, where the preset position information includes the first character field and the second character field; The decoded data corresponding to the information at the preset position in the first table entry is written into the first storage location of the electronic device. The decoded data corresponding to the information at the preset position includes the first data corresponding to the first character field and the second data corresponding to the second character field. The write address corresponding to the next written data is determined based on the first character count identifier field, wherein the write address corresponding to the next written data is located after the first storage location.
17. The decompression method according to claim 15 or 16, characterized in that, The first code length field is stored in the corresponding positions of bits 0 to 7 in the first table entry.
18. The decompression method according to claim 14, characterized in that, The first data includes a third character, and the second data includes a first length parameter. The step of determining the first decoded data corresponding to the eleventh Huffman encoded data and the data length of the Huffman encoded data corresponding to the first decoded data based on the eleventh Huffman encoded data and the index relationship includes: The second entry is obtained from the first index table based on the eleventh Huffman encoded data. The second entry includes a second code length field, a third character field, a first length field, and a second character quantity identifier field. The second code length field includes the data length information of the first Huffman encoded data and the data length information of the second Huffman encoded data, as well as the extended length parameter information. The third character field includes the information corresponding to the third character. The first length field includes the information corresponding to the first length parameter. The second character quantity identifier field includes the number of characters in the second entry. The first data is determined based on the third character field, the second data is determined based on the first length field, and the sum of the data lengths of the first Huffman-coded data corresponding to the first data and the second Huffman-coded data corresponding to the second data is determined based on the second code length field.
19. The decompression method according to claim 18, characterized in that, Determining the first data based on the third character field and determining the second data based on the first length field includes: Read the information at the preset position in the second table entry, where the information at the preset position in the second table entry includes the third character field and a portion of the first length field; The decoded data corresponding to the information at the preset position in the second table entry is written into the second storage location of the electronic device. The decoded data at the preset position in the second table entry includes the first data corresponding to the third character field. The write address corresponding to the next written data is determined based on the second character count identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the first data in the second storage location; The second data is determined based on the first length field and then written to the storage location corresponding to the first data.
20. The decompression method according to claim 18 or 19, characterized in that, The second code length field is stored in the corresponding positions of bits 0 to 7 in the second table entry.
21. The decompression method according to any one of claims 14-20, characterized in that, The method further includes: Obtain the fifth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the corresponding data in the compressed data; Based on the fifth Huffman encoded data and the index relationship, the second decoded data corresponding to the fifth Huffman encoded data and the data length of the Huffman encoded data corresponding to the second decoded data are determined, wherein the second decoded data includes third data, wherein the third data is a fourth character.
22. The decompression method according to claim 21, characterized in that, The step of determining the second decoded data corresponding to the fifth Huffman encoded data and the data length of the Huffman encoded data corresponding to the second decoded data based on the fifth Huffman encoded data and the index relationship includes: The third entry is obtained from the first index table based on the fifth Huffman encoded data. The third entry includes a third code length field, a fourth character field, and a third character quantity identifier field. The third code length field includes the data length information of the fifth Huffman encoded data. The fourth character field includes the information corresponding to the fourth character. The third character quantity identifier field includes the number of characters in the third entry. The third data is determined based on the fourth character field, and the data length of the Huffman-coded data corresponding to the third data is determined based on the third code length field.
23. The decompression method according to claim 22, characterized in that, Determining the third data based on the fourth character field includes: Read the information at a preset position in the third table entry, and write the decoded data corresponding to the information at the preset position in the third table entry into the third storage location of the electronic device. The decoded data corresponding to the information at the preset position in the third table entry includes the third data corresponding to the third character field. The write address corresponding to the next written data is determined based on the third character quantity identifier field, wherein the write address corresponding to the next written data is located after the storage location corresponding to the third data in the third storage location.
24. The decompression method according to any one of claims 14-23, characterized in that, The method further includes: Obtain the sixth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data; Based on the sixth Huffman encoded data and the index relationship, the third decoded data corresponding to the sixth Huffman encoded data and the data length of the Huffman encoded data corresponding to the third decoded data are determined, wherein the third decoded data includes fourth data, and the fourth data is a second length parameter.
25. The decompression method according to claim 24, characterized in that, The step of determining the third decoded data corresponding to the sixth Huffman encoded data and the data length of the Huffman encoded data corresponding to the third decoded data based on the sixth Huffman encoded data and the index relationship includes: The fourth entry is obtained from the first index table based on the sixth Huffman encoded data. The fourth entry includes a fourth code length field, a second length field, and a fourth character count identifier field. The fourth code length field includes the data length information of the sixth Huffman encoded data, the second length field includes the information corresponding to the second length parameter, and the fourth character count identifier field includes the number of characters in the fourth entry. The fourth data is determined based on the second length field, and the data length of the Huffman-coded data corresponding to the fourth data is determined based on the fourth code length field.
26. The decompression method according to any one of claims 14-25, characterized in that, The method further includes: Obtain the eighth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data; The fifth entry in the first index table is determined based on the eighth Huffman coded data and the index relationship. The fifth entry includes a fifth code length field, a first storage location field, a fifth character count identifier field, and an offset field. The fifth code length field includes the length information of the eighth Huffman data. The first storage location field includes the starting address of the second index table. The fifth character count identifier field includes the character count information in the fifth entry. The offset field includes the offset information of the address of the sixth entry in the second index table relative to the starting address. The offset information is determined based on the ninth Huffman coded data in the seventh Huffman data. The ninth Huffman coded data is the Huffman coded data after the Nth bit in the seventh Huffman coded data. The eighth Huffman coded data is the Huffman coded data from the 1st bit to the Nth bit in the seventh Huffman coded data, where N is the value corresponding to the first length. Based on the offset information and the starting position information of the second index table, the sixth entry in the second index table is obtained. The sixth entry includes a sixth code length field and a fifth character field. The sixth code length field is used to store the data length information of the seventh Huffman encoded data. The fifth character field is used to store the information corresponding to the fifth character. The seventh Huffman encoded data includes the eighth Huffman encoded data and the ninth Huffman encoded data. The fifth data is determined based on the fifth character field, and the data length of the Huffman-coded data corresponding to the fifth data is determined based on the sixth code length field.
27. The decompression method according to any one of claims 14-26, characterized in that, The method further includes: Obtain the tenth Huffman-coded data of the first length in the compressed data and the index relationship between the Huffman-coded data and the data to be encoded in the compressed data; Based on the tenth Huffman encoded data and the index relationship, the fourth decoded data corresponding to the tenth Huffman encoded data and the data length of the Huffman encoded data corresponding to the fourth decoded data are determined, wherein the fourth decoded data includes an end character.
28. The decompression method according to claim 27, characterized in that, The step of determining the fourth decoded data corresponding to the tenth Huffman encoded data and the data length of the Huffman encoded data corresponding to the fourth decoded data based on the tenth Huffman encoded data and the index relationship includes: The seventh entry is obtained from the first index table based on the tenth Huffman encoded data. The seventh entry includes a seventh code length field, an end character information field, and a sixth character quantity identifier field. The seventh code length field includes the data length information of the tenth Huffman encoded data. The end character information field includes the end character information. The sixth character quantity identifier field includes the number of characters in the seventh entry. The terminator is determined based on the terminator information field, and the data length of the Huffman-coded data corresponding to the terminator is determined based on the seventh code length field.
29. An electronic device, characterized in that, include: One or more processors; One or more memories; the one or more memories storing one or more programs, which, when executed by the one or more processors, cause the electronic device to perform the compression method of any one of claims 1-13 or the decompression method of any one of claims 14-28.
30. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by the first terminal device, implement the compression method as described in any one of claims 1-13 or the decompression method as described in any one of claims 14-28.