Specific field text file custom dictionary auxiliary Huffman compression method
This domain-specific text file compression method, optimized with a custom dictionary and Huffman coding, solves the problem of insufficient compression ratio of general compression algorithms in specific domains, achieving efficient text file compression and decompression, suitable for server logs, configuration files, and IoT sensor data, etc.
Patent Information
- Application Number
- CN202511424915.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-30
- Publication Date
- 2026-02-27
AI Technical Summary
Existing general compression algorithms do not achieve high compression rates for text in specific domains. Traditional Huffman coding cannot utilize phrase-level repetition patterns and lacks user customization capabilities, resulting in limited compression performance.
A domain-specific text file custom dictionary-assisted Huffman compression method is adopted. By combining user-defined dictionary and optimized Huffman encoding with block processing strategy and efficient string matching algorithm, text replacement and encoding optimization are achieved.
It significantly improves the compression rate to 70-80% and supports flexible adaptation to text from different fields, meeting the needs of efficient compression and decompression, and is suitable for scenarios such as server logs, configuration files and IoT sensor data.
Smart Images

Figure CN121580974A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of data compression, and particularly relates to a Huffman compression method assisted by a self-defined dictionary for a text file in a specific field. BACKGROUND
[0002] With the rapid development of information technology, the amount of text data generated by various application systems is growing exponentially, especially in the fields of server log management, Internet of Things data collection, and configuration file storage, the amount of text file data generated daily can reach TB level. The storage and transmission of these massive text data have brought huge cost pressure to enterprises, not only requiring a large amount of storage space, but also occupying valuable network bandwidth resources. Therefore, how to effectively compress text files to reduce storage space occupation and transmission bandwidth demand has become a technical problem that the industry needs to solve.
[0003] Existing text compression technologies mainly include two categories: general-purpose compression algorithms and special-purpose compression algorithms. General-purpose compression algorithms such as ZIP, GZIP, BZIP2, etc. are based on LZ77, LZ78 or their variants, although they have a wide range of applications, but for structured text files in specific fields, the compression rate can usually only reach 40-60%, which is difficult to meet the demand for high compression rate. Although traditional Huffman coding is a classic lossless compression algorithm, it can perform variable-length coding according to character frequency, but it only codes at the character level and cannot fully utilize the large number of repeated phrases and fixed formats in specific field texts, resulting in limited compression effect. In addition, existing compression schemes lack flexibility and cannot allow users to customize compression strategies according to specific application scenarios, making it difficult to adapt to the particularity of different field texts.
[0004] Text files in specific fields often have obvious structured characteristics and high repeatability. For example, server log files contain a large number of repeated timestamp formats, IP address prefixes, HTTP status codes, and other fixed patterns; Internet of Things sensor data contains repeated device identifiers, data field names, and state descriptions; configuration files contain repeated parameter names, path information, and configuration items. If these domain-specific repeated patterns can be effectively identified and utilized, the compression efficiency will be greatly improved. However, the characteristics of different fields differ greatly, and it is difficult to design a general algorithm to automatically identify specific patterns in all fields, so a compression scheme that can utilize domain knowledge while maintaining algorithm universality is needed. SUMMARY
[0005] In view of the technical problems of low compression rate of general compression algorithm for specific field text, inability of traditional Huffman coding to utilize short phrase repetition mode, and lack of user customization capability in the prior art, the present application provides a specific field text file self-defined dictionary assisted Huffman compression method and system, which realizes efficient text compression by combining a user-defined field-specific dictionary and an optimized Huffman coding.
[0006] The technical solution of the present application is as follows: A specific field text file self-defined dictionary assisted Huffman compression method, comprising the following steps: Receiving a user-defined dictionary, the dictionary containing a plurality of short phrase-short code mapping relationships, wherein the short phrase is a string in the original text, and the short code is a shorter string used for replacement; Verifying the self-defined dictionary, the verification content including checking that the short code length is less than the corresponding short phrase length, verifying that the short code characters have no intersection with the original text character set, and checking that there is no prefix inclusion relationship between the short codes of different short phrases; Sorting the verified dictionary in descending order of short phrase length to form a replacement priority queue; Replacing the string in the input text file according to the order of the replacement priority queue, starting from the longest short phrase and replacing it with the corresponding short code in turn to generate a replaced text; Statistically analyzing the character frequency of the replaced text, and constructing a Huffman tree according to the statistical results, wherein the Huffman tree adopts a binary tree structure, and the nodes contain character values, frequency values, and left and right child node pointers; Generating Huffman coding for each character based on the Huffman tree, and converting the replaced text into an encoded bit stream; Generating a compressed file, which contains three parts: a file header metadata area, a dictionary information area, and a compressed data area, wherein the file header metadata area records the original file size and the number of dictionary entries, the dictionary information area stores the short phrase-short code mapping table, and the compressed data area stores the encoded bit stream; the compression rate calculation formula is used to evaluate the compression effect: Wherein represents the compression rate, represents the compressed file size (bytes), represents the original file size. The formula is used to quantify the efficiency of the compression algorithm, and the present application can achieve a compression rate of 40-50% in log file testing; the average encoding length calculation of Huffman coding is as follows: Wherein represents the average encoding length, represents the number of probability of occurrence of a character Huffman encoding length of the character, is the size of the character set.
[0007] 2. The compression method according to claim 1, wherein in the step of replacing strings in the input text file, a block processing strategy is adopted, the input text file is divided into a plurality of data blocks according to a predetermined size, each data block is independently processed for replacement, and a position marker array is maintained to record the replaced area during the replacement process.
[0008] Further, the step of constructing the Huffman tree specifically comprises: creating a leaf node for each character, the node frequency being the number of occurrences of the character; maintaining the node set using a minimum heap data structure; repeatedly performing the following operations until only one node is left in the heap: taking out the two nodes with the smallest frequency from the heap, creating a new internal node as the parent node of the two nodes, the new node frequency being the sum of the frequencies of the two child nodes, and inserting the new node into the heap; In the step of generating the Huffman encoding, the Huffman tree is traversed in a depth-first manner, with the left child path being recorded as 0 and the right child path being recorded as 1.
[0009] Further, the above method further comprises a decompression step: reading the file header metadata area of the compressed file to obtain the original file size and the number of dictionary entries; reading the phrase-short code mapping table from the dictionary information area to construct the reverse mapping dictionary of short code-phrase; reconstructing the Huffman tree according to the file header information; reading the encoded bit stream from the compressed data area and using the reconstructed Huffman tree for decoding: starting from the root node, selecting the left child node or the right child node according to the bit value for traversal, and outputting the corresponding character when reaching the leaf node; performing reverse replacement on the decoded text according to the short code length in descending order using the reverse mapping dictionary to restore the original text.
[0010] Further, the custom dictionary is stored using a HashMap data structure, with the key being the original phrase string and the value being the short code string for replacement; and the string replacement is implemented using the Aho-Corasick automaton or the Boyer-Moore algorithm or the KMP algorithm for multi-pattern string matching.
[0011] Further, the file header metadata area further includes version number information and Huffman tree structure serialization data, and the Huffman tree structure is stored in a pre-order traversal manner.
[0012] Further, the block processing adopts a streaming processing manner, and memory space is released immediately after each data block processing is completed.
[0013] A specific field text file custom dictionary assisted Huffman compression system comprises: A dictionary management module is configured to receive and verify a user-defined phrase-short code mapping dictionary, and sort the dictionary in descending order of phrase length. A text replacement module is configured to replace phrases with short codes in the input text according to the sorted dictionary. A Huffman encoding module comprises a frequency statistics submodule and an encoding tree construction submodule, and is configured to perform Huffman encoding on the replaced text. A file storage module is configured to organize and store a compressed file comprising a file header metadata area, a dictionary information area and a compressed data area.
[0014] In the above technical solution, first, a user-defined dictionary mechanism is established, allowing the user to define phrase-short code mapping relationships according to the characteristics of specific field text, and replacing long phrases that frequently appear with short codes. The system strictly verifies the dictionary provided by the user to ensure that the length of the short code is less than that of the original phrase, the characters of the short code and the character set of the original text are disjoint, and there is no prefix inclusion relationship between different short codes, thereby ensuring the effectiveness and reversibility of the replacement. The dictionary is sorted in descending order of phrase length to form a replacement priority queue, ensuring that long phrases are matched first and avoiding the problem of incorrect matching of short phrases.
[0015] Secondly, a block processing strategy is adopted to efficiently replace large text files. The system divides the input file into fixed-size data blocks, each block is independently processed for dictionary replacement, and the memory usage is effectively controlled. Within a single data block, each phrase is scanned and replaced in order according to the priority queue, and a position marker array is maintained to avoid repeated replacement. The replacement process can use efficient string matching algorithms such as Aho-Corasick automaton, Boyer-Moore or KMP, to achieve fast multi-pattern matching.
[0016] Then, the replaced text is subjected to optimized Huffman encoding. The system counts the frequency distribution of the replaced text, constructs a Huffman tree and generates a variable-length encoding table. Since the dictionary replacement has significantly reduced the text length and changed the character distribution, the high-frequency characters are more concentrated, and the efficiency of Huffman encoding is significantly improved. The bit stream after encoding is organized into a structured compressed file format together with the dictionary information and metadata.
[0017] Finally, the complete decompression process ensures the lossless restoration of data. During decompression, the system reads the metadata and dictionary information from the compressed file, reconstructs the Huffman tree and the reverse dictionary. The bit stream is first decoded into the replaced text through the Huffman tree, and then the short code is restored to the original phrase using the reverse dictionary, fully recovering the original text content.
[0018] Advantages of the present application: (1) Significant improvement in compression ratio: Through the synergistic optimization of dictionary replacement and Huffman coding, the compression ratio of specific domain text can reach 70-80%, which is much higher than the 40-60% of general compression algorithms. In the server log scenario, the actual compression ratio reaches 53%, and in the Internet of Things sensor data scenario, the compression ratio is as high as 77%.
[0019] (2) High flexibility: Users can customize special dictionaries according to different application scenarios, without modifying the algorithm to adapt to various specific domain texts, including but not limited to log files, configuration files, sensor data, medical records, etc.
[0020] (3) High processing efficiency: Using block processing and streaming processing technology, memory occupation is controllable, supporting large file compression. Optimized string matching algorithm ensures replacement efficiency, and the overall compression and decompression speed meets real-time processing requirements.
[0021] (4) Completely lossless: The compression and decompression process is completely reversible, ensuring data integrity, suitable for application scenarios with strict requirements for data accuracy.
[0022] (5) Easy to integrate: The system architecture is modularly designed, which can be easily integrated into existing data processing flow, supporting edge computing device deployment, effectively reducing data transmission and storage costs. BRIEF DESCRIPTION OF DRAWINGS
[0023] In order to more clearly illustrate the technical solutions in the present application or prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only a part of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.
[0024] Figure 1 For the Figure 1 : System architecture diagram, showing the four core modules of the compression system and their mutual relationship; Figure 2 For the compression flowchart of the present application, the complete processing flow from inputting the original text file to generating the compressed file is shown, including the judgment branch of dictionary verification; Figure 3For the dictionary replacement example of the present application, through the specific log file example, the content of the custom dictionary and the comparison effect before and after the text replacement are shown, and the compression ratio is marked; Figure 4 For the Huffman tree construction example of the present application, the Huffman tree structure constructed based on character frequency statistics is shown, including node weight, encoding path (0 / 1) and final encoding result. Figure 5 For the compression file structure diagram of the present application, the three-part structure of the compressed file is shown, and the size of each part is marked. DETAILED DESCRIPTION
[0025] The present application will be described in detail below in conjunction with the drawings and specific embodiments. It should be noted here that in order to make the embodiments more detailed, the following embodiments are the best, preferred embodiments, and other alternative ways can also be implemented by those skilled in the art for some known technologies; and the drawings are only used to describe the embodiments more specifically, and are not intended to limit the present application specifically.
[0026] It should be noted that in the specification, "one embodiment", "embodiment", "example embodiment", "some embodiments" and the like indicate that the described embodiments can include a specific feature, structure or property, but not necessarily every embodiment includes this specific feature, structure or property. In addition, when a specific feature, structure or property is described in conjunction with an embodiment, it should be within the knowledge of those skilled in the related art to realize this feature, structure or property in conjunction with other embodiments (whether or not explicitly described).
[0027] Generally, the terms can be understood at least in part from the use in context. For example, depending at least in part on the context, the term "one or more" as used herein can be used to describe any feature, structure or property that can exist singularly or in combination with other features, structures or properties. In addition, the term "based on" can be understood as not necessarily intended to convey a set of exclusive factors, but can instead, depending at least in part on the context, allow the existence of other factors not necessarily explicitly described.
[0028] Reference Figures 1 to 5 shown The present application provides a specific field text file custom dictionary assisted Huffman compression method, which realizes efficient lossless compression of specific field text files by combining user-defined dictionary preprocessing and Huffman coding optimization. This method is particularly suitable for text files with high repetition characteristics, such as server logs, configuration files, sensor data records, etc. The present embodiment will describe the implementation steps of the entire compression and decompression process.
[0029] I. System architecture and data structure design The compression system of the present application mainly includes a dictionary management module, a text replacement module, a Huffman coding module and a file storage module. The dictionary management module is responsible for receiving and verifying user-defined dictionaries, using HashMap data structure to store the phrase-short code mapping relationship, where the key is the original phrase string and the value is the short code string used for replacement. To ensure the correctness of the replacement, the system pre-processes the dictionary at initialization: first, sort the phrases in descending order of length to ensure that long phrases are matched first; second, verify the uniqueness and conflict-free of the short code, i.e. the short code cannot be a substring that may appear in the original text, and cannot be ambiguous with other short codes. The text replacement module uses a multi-pattern string matching algorithm to achieve efficient batch phrase replacement by constructing an Aho-Corasick automaton or using an optimized string replacement strategy. The Huffman coding module includes a frequency statistics submodule and a coding tree construction submodule. The frequency statistics uses an integer array to record the frequency of each character, and the coding tree uses a binary tree structure to store, with nodes containing character values, frequency values and left and right node pointers. The file storage module is responsible for organizing the compressed file format. The compressed file consists of three parts: the file header metadata area, the dictionary information area and the compressed data area. The header records version number, original file size, dictionary entry number, etc. The dictionary area stores the phrase-short code mapping table, and the data area stores the Huffman encoded bit stream.
[0030] II. Detailed implementation of the compression process The compression process starts with the user-defined dictionary stage. The user inputs the field-specific phrase-short code mapping through JSON format or graphical interface, for example, in the log file scenario, the mapping relationship such as {"ERROR:": "E", "INFO:": "I", "WARNING:": "W", "2025-08-": "D", "System failure": "SF"} can be defined. After the system receives the dictionary, it performs a verification process: checks whether the short code length is less than the original phrase length (to ensure compression effect), verifies whether the short code characters are disjoint with the original text character set (to avoid ambiguity in decompression), checks whether the short codes of different phrases have prefix inclusion relationship (to prevent replacement conflict). After verification, the system sorts the dictionary in descending order of phrase length to form a replacement priority queue.
[0031] The text replacement phase adopts a block processing strategy to adapt to large files and memory limit scenarios. For the input text file, the system divides the data block by 10MB size, and each data block is independently processed. Within a single data block, the system scans and replaces in order according to the sorted dictionary: first find all the positions of the longest phrase and replace it with the corresponding short code, then process the second longest phrase, and so on. This replacement strategy from long to short effectively avoids the problem of incorrect matching of short phrases. For example, when the dictionary contains "hello world"→"HW" and "hello"→"H" two mappings, the text "helloworld hello" will be replaced first "HW hello", and then replaced "HW H", and will not be incorrectly processed into "H worldH". During the replacement process, the system maintains a position marker array to record the replaced area and avoid repeated replacement.
[0032] After completing the dictionary replacement, enter the Huffman coding phase. The system first performs character frequency statistics on the replaced text, traverses the entire text and uses a hash table to record the frequency of each character. Based on the frequency statistics, a Huffman tree is constructed: a leaf node set is created, each character corresponds to a leaf node; use the minimum heap to maintain the node set, and each time take out the two nodes with the smallest frequency to merge into a new internal node, and the new node frequency is the sum of the frequencies of the two child nodes; repeat the merging process until only one root node is left. After the construction is completed, the Huffman code of each character is generated by depth-first traversal, and the left subtree path is recorded as 0 and the right subtree path is recorded as 1. After the code is generated, the system converts the original text into a bit stream: read the replaced text character by character, find the corresponding Huffman code, and write the code bit string to the output buffer. To support decompression, the system stores necessary meta information in the header of the compressed file: original file size, dictionary entry number, phrase-short code pair of each dictionary entry, Huffman tree structure (can use pre-order traversal serialization method).
[0033] Detailed implementation method of decompression process The decompression process is the reverse operation of compression. First, read the header of the compressed file and parse the metadata information including the original file size, dictionary information and Huffman tree structure. According to the header information, reconstruct the Huffman tree: if using pre-order traversal serialization, reconstruct the tree structure recursively according to the stored node sequence; if the character-code mapping table is stored, reconstruct the tree according to the coding rule. After reconstruction is completed, the system begins to decode the compressed data: read the bit stream from the compressed data area, start from the root node of the Huffman tree, select the left or right child node according to the bit value (0 or 1), and output the corresponding character when reaching the leaf node, and then start from the root node to decode the next character. This process continues until the total number of decoded characters reaches the original file size.
[0034] After Huffman decoding yields the dictionary-replaced text, the next step is to perform the dictionary inverse replacement. The system constructs a reverse dictionary, storing the short code-phrase mapping in a new HashMap. The inverse replacement also follows a long-to-short strategy, but here it's processed in descending order of short code length, ensuring that long codes are restored first. The decoded text is scanned, all short code occurrences are found, and replaced with the original phrase. For example, the text "HW H" is first restored from "HW" to "hello world", resulting in "helloworld H", then "H" is restored to "hello", finally restoring "hello world hello". After the inverse replacement, the system verifies that the size of the restored text matches the original file size, ensuring correct decompression.
[0035] To improve compression and decompression performance, this invention implements several optimization strategies. In the dictionary replacement stage, the Boyer-Moore or KMP algorithm is used to accelerate string matching, reducing the complexity of a single match from O(mn) to O(n+m), where m is the pattern string length and n is the text length. For dictionaries containing multiple phrases, an Aho-Corasick automaton is constructed to complete the matching of all patterns in a single scan, with a complexity of O(n+k), where k is the sum of the lengths of all pattern strings. In the Huffman coding stage, bitwise operations are used to optimize bitstream reading and writing: batch writing using byte buffers reduces the number of I / O operations; bit shifting and masking operations are used to efficiently process bits. For memory management, a memory pool technique is implemented to reuse frequently allocated small objects, reducing memory fragmentation; large files are processed using streaming to maintain a constant memory footprint.
[0036] The compression ratio calculation formula is a key component of the above technical solution, used to evaluate the compression effect: in Indicates compression ratio. Indicates the size of the compressed file (in bytes). This represents the original file size (in bytes). This formula is used to quantify the efficiency of the compression algorithm; this invention achieves a compression rate of 40-50% in log file tests. The calculation steps for the above formula are as follows: Step 1: Obtain the original file size |O|; Number of bytes read from the original text file; For example: Original log file size = 100,000 bytes (100KB); Step 2: Perform compression processing Perform dictionary replacement; Perform Huffman coding; Add file header information; Step 3: Get the size of the compressed file |C| Calculate the size of each part: File header metadata: 2,000 bytes; Dictionary information area: 3,000 bytes; Compressed data area: 42,000 bytes; Total size of the compressed file = 2,000 + 3,000 + 42,000 = 47,000 bytes Step 4: Substitute into the formula to calculate; CR = (1 - 47,000 / 100,000) × 100% = (1 - 0.47) × 100% = 0.53 × 100% = 53% Step 5: Interpretation of Results A compression rate of 53% means that the file size has been reduced by 53%. The compressed file is 47% of the original file size. Secondly, the formula for calculating the average code length of Huffman coding is as follows: in Indicates the average code length. Indicates the first The probability of each character appearing This indicates the Huffman code length of the character. Where is the character set size. This formula is used for theoretical analysis of coding efficiency; the closer the average code length is to the information entropy, the higher the coding efficiency. The steps for calculating the average code length of Huffman coding are as follows: Step 1: Count character frequencies Perform character frequency statistics on the replaced text, for example: Spaces: 45 The character 'E': 30 times Character 'I': 25 times Character 'D': 20 times Other characters: 80 times Total: 200 times Step 2: Calculate the probability p_i of character occurrence. p (space) = 45 / 200 = 0.225 p(E) = 30 / 200 = 0.150 p(I) = 25 / 200 = 0.125 p(D) = 20 / 200 = 0.100 p(other) = 80 / 200 = 0.400 Step 3: Construct the Huffman tree and obtain the encoding length l_i Based on the results of the Huffman tree construction: Space encoding: 00, length l = 2 'E' encoding: 010, length l = 3 'I' encoding: 011, length l = 3 'D' encoding: 10, length l = 2 Other encoding: 11, length l = 2 Step 4: Calculate the weighted encoding length of each character. Space: 0.225 × 2 = 0.450 E: 0.150 × 3 = 0.450 I: 0.125 × 3 = 0.375 D: 0.100 × 2 = 0.200 Other: 0.400 × 2 = 0.800 Step 5: Summation to obtain the average code length L_avg = 0.450 + 0.450 + 0.375 + 0.200 + 0.800 = 2.275 bits / character.
[0037] Extended computational examples (more complex scenarios): Suppose there are 8 different characters: Average encoding length L_avg = 2.825 bits / character Efficiency assessment: Information entropy calculation (theoretical optimal value): Taking the above 8 characters as an example: H = -(0.250×log20.250 + 0.200×log20.200 + ... + 0.040×log20.040) = 2.755 bits / character; Encoding efficiency: This indicates that Huffman coding is close to its theoretical optimum, achieving an efficiency of 97.5%. Example Example 1: Server Log File Compression Taking a typical Apache server access log file as an example, the original file size is 100KB, containing a large amount of repeated timestamps, IP addresses, HTTP status codes, and other information. The user first analyzes the log characteristics and defines the following dictionary mapping: {"[2025-08-05": "[D", "ERROR:": "E", "INFO:": "I", "WARNING:": "W", "192.168.": "IP", "GET / ": "G", "POST / ": "P", "HTTP / 1.1": "H1", " 200 OK": "OK", " 404 Not Found": "NF", " 500 Internal Server Error": "IE"}. The system receives the dictionary and verifies it, confirming that all short codes (such as "[D", "E", "IP", etc.) will not appear as independent content in the original log.
[0038] During text replacement, the original log entry "[2025-08-05 14:23:45] INFO: 192.168.1.100GET / index.html HTTP / 1.1 200 OK" was replaced with "[D14:23:45] I IP1.100 Gindex.html H1OK", reducing the length from 80 bytes to 38 bytes. After performing the replacement on the entire 100KB file, the file size was reduced to approximately 65KB. Next, Huffman encoding was performed, and the frequency of characters in the replaced text was analyzed. It was found that spaces, numbers, and a small number of letters occupied the majority of the frequencies. After constructing the Huffman tree, high-frequency characters such as spaces received short codes (e.g., "0"), while low-frequency characters received long codes. The encoded bitstream was further compressed to 45KB. Adding the header information for storing the dictionary and Huffman tree (approximately 2KB), the final compressed file size was 47KB, achieving a compression rate of 53%. During decompression, the system reads the header information to reconstruct the dictionary and Huffman tree, first decodes the bitstream into the replaced text, and then restores the original log content through the reverse dictionary. The entire decompression process takes about 30 milliseconds.
[0039] Example 2: IoT Sensor Data Compression Consider an Industrial Internet of Things (IIoT) scenario where a temperature sensor generates one data record per second, in the format "DeviceID:TMP001,Timestamp:2025-08-05T10:15:30,Temperature:25.3°C,Status:Normal". A day's data file is approximately 8.6MB, containing 86,400 records. A user-defined dictionary is used: {"DeviceID:TMP": "D", "Timestamp:2025-08-05T": "T", "Temperature:": "t", "°C,Status:Normal": "N", "°C,Status:Alert": "A", "°C,Status:Error": "E"}.
[0040] During compression, dictionary replacement yielded significant results due to the highly structured data. The original record "DeviceID:TMP001,Timestamp:2025-08-05T10:15:30,Temperature:25.3°C,Status:Normal" (80 characters) was replaced with "D001,T10:15:30,t25.3N" (21 characters), compressing the file to 26% of its original size. When processing the entire 8.6MB file, the system employed a block-based strategy, processing 10MB blocks at a time (only once in this example), keeping memory usage below 20MB. After dictionary replacement, the file was reduced to approximately 2.8MB. During the Huffman encoding stage, because the replaced text mainly contained numbers, colons, commas, and a small number of letters, the character distribution was relatively concentrated, and Huffman encoding further compressed the file to 1.9MB. Sensor data file compression rate calculation: Original file size |O| = 8,600,000 bytes (8.6MB) The compressed file size |C| = 2,000,000 bytes (2.0MB) CR = (1 - 2,000,000 / 8,600,000) × 100% = (1 - 0.2326) × 100% = 0.7674 × 100% = 76.74% ≈ 77% With header information added, the final compressed file is approximately 2.0MB, achieving a total compression rate of 77%, far exceeding the 50-60% compression rate of common compression algorithms.
[0041] In practical deployments, this compression solution is integrated into edge gateway devices. Sensor data is compressed before being uploaded to the cloud, significantly reducing network bandwidth requirements and transmission costs. Decompression is performed in the cloud data center, with a single file decompression time of approximately 600 milliseconds, meeting real-time analysis needs. Through long-term operational verification, this solution reduces data transmission costs by 70% and storage costs by 75% while ensuring data integrity.
[0042] This invention encompasses any substitutions, modifications, equivalent methods, and solutions made within the spirit and scope of this invention. To provide the public with a thorough understanding of this invention, specific details are described in detail in the following preferred embodiments; however, those skilled in the art will fully understand the invention even without these details. Furthermore, to avoid unnecessary misunderstanding of the essence of this invention, well-known methods, processes, procedures, components, and circuits are not described in detail.
[0043] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.
Claims
1. A domain-specific text file custom dictionary-assisted Huffman compression method, characterized in that, Includes the following steps: Receive a user-defined dictionary, which contains multiple phrase-short code mapping relationships, where the phrase is a string in the original text and the short code is a shorter string used for replacement; The custom dictionary is validated, including checking that the short code length is less than the corresponding phrase length, verifying that the short code characters have no intersection with the original text character set, and checking that there is no prefix inclusion relationship between the short codes of different phrases. The verified dictionaries are sorted in descending order of phrase length to form a replacement priority queue; The input text file is replaced according to the order of the replacement priority queue, starting from the longest phrase and sequentially searching and replacing it with the corresponding short code to generate the replaced text; The replaced text is statistically analyzed for character frequency. A Huffman tree is constructed based on the statistical results. The Huffman tree adopts a binary tree structure, and each node contains a character value, a frequency value, and pointers to left and right child nodes. Based on the Huffman tree, generate the Huffman code for each character, and convert the replaced text into an encoded bitstream; A compressed file is generated, which contains three parts: a file header metadata area, a dictionary information area, and a compressed data area. The file header metadata area records the original file size and the number of dictionary entries, the dictionary information area stores a phrase-short code mapping table, and the compressed data area stores the encoded bit stream. Compression ratio calculation formula, used to evaluate compression effect: in Indicates compression ratio. Indicates the size of the compressed file (in bytes). This represents the original file size. This formula is used to quantify the efficiency of the compression algorithm; in log file tests, this invention achieved a compression rate of 40-50%. The average encoding length of Huffman coding is calculated using the following formula: in Indicates the average code length. Indicates the first The probability of each character appearing This indicates the Huffman code length of the character. The size of the character set.
2. The compression method according to claim 1, characterized in that, In the step of replacing strings in the input text file, a block processing strategy is adopted, which divides the input text file into multiple data blocks of a predetermined size. Each data block is replaced independently, and a position marker array is maintained during the replacement process to record the replaced areas.
3. The compression method according to claim 1, characterized in that, The steps for constructing the Huffman tree specifically include: Create a leaf node for each character, with the node frequency being the number of times that character appears. Use a min-heap data structure to maintain the node set; Repeat the following operations until only one node remains in the heap: Take the two nodes with the lowest frequencies from the heap, create a new internal node as the parent node of these two nodes, the frequency of the new node is the sum of the frequencies of the two child nodes, and insert the new node into the heap; In the step of generating Huffman codes, the Huffman tree is traversed in a depth-first manner, with the left subtree path recorded as 0 and the right subtree path recorded as 1.
4. The compression method according to claim 1, characterized in that, It also includes a decompression step: Read the file header metadata area of the compressed file to obtain the original file size and the number of dictionary entries; Read the phrase-short code mapping table from the dictionary information area and construct the reverse mapping dictionary of short code-phrase; Reconstruct the Huffman tree based on the file header information; Read the encoded bitstream from the compressed data area and decode it using the reconstructed Huffman tree: starting from the root node, traverse the left or right child node according to the bit value, and output the corresponding character when the leaf node is reached; The decoded text is sorted in descending order of short code length and then reverse-substituted using a reverse mapping dictionary to restore the original text.
5. The compression method according to claim 1 or 4, characterized in that, The custom dictionary is stored using a HashMap data structure, with the key being the original phrase string and the value being the short code string used for replacement; the string replacement uses the Aho-Corasick automaton, Boyer-Moore algorithm, or KMP algorithm to achieve multi-pattern string matching.
6. The compression method according to claim 1, characterized in that, The file header metadata area also includes version number information and Huffman tree structure serialization data, which is serialized and stored using a preorder traversal method.
7. The compression method according to claim 2, characterized in that, The predetermined size is 10MB, and the block processing adopts a streaming processing method. The memory space is released immediately after each data block is processed.
8. A domain-specific text file custom dictionary-assisted Huffman compression system, characterized in that, include: The dictionary management module is used to receive and verify user-defined phrase-short code mapping dictionaries and sort them in descending order of phrase length. The text replacement module is used to replace phrases with short codes in the input text based on a sorted dictionary. The Huffman coding module, which includes a frequency statistics submodule and a coding tree construction submodule, is used to perform Huffman coding on the replaced text. The file storage module is used to organize and store compressed files, which include a file header metadata area, a dictionary information area, and a compressed data area.