Method and device for generating hash value of burning configuration file

Abstract

The invention provides a method and a device for generating a hash value of a burning configuration file, and aims to improve the generation efficiency of a vehicle-mounted burning configuration file through a method for screening a target file after file name matching and performing block streaming calculation on the MD5 hash value of the target file. The method for generating the hash value of the burning configuration file comprises the steps that when the size of a target file to be written is larger than a preset value, a file name list in a [MD5CHECK] data block of an initial configuration file of a vehicle-mounted burning program is obtained; determining the file of which the file name in the file name list is consistent with the file name in the target folder as a target file; the MD5 hash value of the target file is calculated in a block streaming processing mode, and the first data block and the second data block are adjacently read data blocks; and writing the first data block, the second data block and the corresponding MD5 hash values into the [MD5CHECK] data block of the target file to obtain a burning configuration file.

Description

Technical Field

[0001] This application relates to the field of railway technology, and in particular to a method and apparatus for generating hash values ​​for burning configuration files. Background Technology

[0002] With the rapid development of railway signaling technology, the functions of on-board embedded systems are iterating at an accelerated pace, requiring frequent updates to the configuration files to adapt to new functions. To verify the integrity and authenticity of the updated configuration files and prevent tampering or damage during transmission or storage, hash value verification is necessary. Therefore, hash value generation is a crucial step in the configuration file update process.

[0003] Currently, the generation of the configuration file hash value relies on a full file loading: that is, the entire configuration file containing the new version is read and loaded into memory before the configuration file hash calculation is initiated. However, with the increasing complexity of in-vehicle functions and the significant increase in configuration file data, full loading will lead to a surge in data processing volume when updating large firmware files or multiple files in batches. This surge in data processing volume results in excessive memory usage, and the subsequent full hash calculation will keep the CPU under high load for a long time. The combination of these two factors creates a performance bottleneck, increasing the hash value generation time and thus reducing the efficiency of configuration file updates.

[0004] Therefore, there is an urgent need for a new method to generate hash values ​​for vehicle-mounted flashing configuration files in order to improve the efficiency of generating flashing configuration files. Summary of the Invention

[0005] This application provides a method and apparatus for generating hash values ​​of burning configuration files. The purpose is to improve the update efficiency of vehicle-mounted burning configuration files by filtering target files after matching filenames and performing block-based streaming MD5 hash value calculation on the target files.

[0006] To address the aforementioned technical problems, this application provides the following technical solutions: The first aspect of this application provides a method for generating a hash value for a burning configuration file, including: When the size of the target file to be written is greater than a preset value, the initial configuration file of the vehicle-mounted burning program is obtained, and the initial configuration file is parsed to obtain the list of filenames in the [MD5_CHECK] data block; Based on the target folder to be written, the file names in the file name list are matched with the file names in the target folder and its subfolders, and the files whose file names match are identified as target files; The target file is processed using a block-based streaming method to calculate the MD5 hash value. The block-based streaming method reads the contents of the target file in blocks of a fixed number of bytes, and calculates the MD5 hash value of the first data block when reading the second data block. The first data block and the second data block are adjacent data blocks to be read. Write the first data block, the second data block, the MD5 hash value of the first data block, and the MD5 hash value of the second data block into the [MD5_CHECK] data block of the target file to obtain the burning configuration file.

[0007] A second aspect of this application provides an apparatus for generating hash values ​​for burning configuration files, comprising: The selection unit is used to obtain the initial configuration file of the vehicle-mounted burning program when the size of the target file to be written is greater than a preset value, and to parse the initial configuration file to obtain the list of filenames in the [MD5_CHECK] data block; The filtering unit is used to match the file names in the file name list with the file names in the target folder and its subfolders based on the target folder to be written, and to determine the file names that match the file names as target files; The calculation unit is used to calculate the MD5 hash value of the target file in the filtering unit using a block-based streaming processing method. The block-based streaming processing method reads the content of the target file in blocks of a fixed number of bytes, and calculates the MD5 hash value of the first data block when reading the second data block. The first data block and the second data block are adjacent data blocks read. The generation unit is used to write the first data block, the second data block, the MD5 hash value of the first data block, and the MD5 hash value of the second data block from the calculation unit into the [MD5_CHECK] data block of the target file to obtain the burning configuration file.

[0008] A third aspect of this application provides a storage medium comprising a stored program, wherein, when the program is executed, it controls the device where the storage medium is located to execute the above-described method for generating a configuration file hash value.

[0009] The fourth aspect of this application discloses an electronic device, the device comprising at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the above-described method for generating a configuration file hash value.

[0010] Compared to existing technologies, the method for generating hash values ​​for burning configuration files provided in this application avoids a full traversal of the target folder and reduces the overhead of handling invalid files when updating large firmware files or multiple files in batches. At the same time, the target files are read in fixed byte blocks, and the hash value of the first data block is calculated simultaneously when reading the second data block, realizing parallel processing of file reading and hash calculation, shortening the overall time consumption, and starting the calculation without waiting for all files to be loaded, thereby improving the efficiency of updating vehicle-mounted burning configuration files. Attached Figure Description

[0011] The above and other objects, features, and advantages of exemplary embodiments of this application will become readily understood by reading the following detailed description with reference to the accompanying drawings. In the drawings, several embodiments of this application are illustrated by way of example and not limitation, with the same or corresponding reference numerals denoteing the same or corresponding parts, wherein: Figure 1 A flowchart illustrating a method for generating a configuration file hash value is shown schematically. Figure 2 A flowchart illustrating another method for generating the hash value of the burning configuration file is shown schematically; Figure 3 A schematic diagram of a device for generating configuration file hash values ​​is shown. Figure 4 A schematic diagram of another device for generating configuration file hash values ​​is shown. Detailed Implementation

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

[0013] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0014] With the rapid development of automotive electronics technology, the functions of in-vehicle embedded systems are becoming increasingly complex. The accuracy and efficiency of configuration file burning are crucial for the functional iteration and safe operation of in-vehicle devices. Current technologies rely on loading all files before calculating their hash values ​​during the configuration file update process. This involves directly reading the target folder containing the new version of the configuration file, loading all data in the target folder into memory, and then performing the hash calculation. However, this method is time-consuming when handling large firmware files or batch updates of multiple files, as it requires waiting for the entire file to load before starting the calculation.

[0015] Based on this, the applicant proposed a new method by optimizing the file processing workflow: first, accurately matching and filtering target files using a list of filenames in the initial configuration file; then, using block-based streaming processing to calculate MD5 hash values ​​in real time, avoiding full loading and invalid processing, thereby solving the problem of excessively long update times in existing technologies. The specific method is as follows: Figure 1 As shown, the details are as follows: Step 101: When the size of the target file to be written is greater than a preset value, obtain the initial configuration file of the vehicle-mounted burning program, and parse the initial configuration file to obtain the list of filenames in the [MD5_CHECK] data block.

[0016] In this step, the preset values ​​are not specifically limited; the specific values ​​are determined based on the content of the vehicle-mounted embedded system. The initial configuration file is the basic configuration file before the vehicle-mounted programming program runs. It contains information such as the programming target and verification rules, and is the core guiding document for the programming process. The [MD5_CHECK] data block is the core area in the vehicle-mounted programming configuration file specifically used to record the name of the configuration file to be programmed and its corresponding MD5 checksum. It is a key module to ensure the integrity of the programming configuration file and prevent file tampering. The format is usually a set of key-value pairs of "filename = MD5 value". In this embodiment, both the initial configuration file and the target file are in INI format.

[0017] Specifically, firstly, a visual GUI (computer operation display interface) was developed based on the Python Tkinter framework, integrating a dual-path selector component. One selector specifies the path to the "initial configuration file," while the other reserves the function of selecting the "target folder" later. Users can select the path by clicking the "Browse" button, and the system automatically caches the selected configuration file path to a local storage module (such as a temporary folder or in-memory database) to avoid repeated operations. Secondly, the ConfigParser tool is called to parse the initial configuration file under the cached path to obtain the list of filenames in the [MD5_CHECK] data block. The parsing process incorporates a new "two-level verification mechanism": The first level verifies the validity of the configuration file format. If the file is not in INI format (such as TXT or JSON), a pop-up message immediately appears stating "Configuration file format error, only INI format is supported." The second level verifies the existence of the [MD5_CHECK] data block. If this data block is detected as missing, a pop-up message appears stating "Configuration file is missing the [MD5_CHECK] core data block, please supplement and retry." If the verification passes, a key-value pair extraction algorithm extracts the filenames from all "filename-placeholder" key-value pairs in the [MD5_CHECK] data block. After removing invalid characters such as spaces and newlines, a structured list of filenames (such as a list or dictionary format) is generated and temporarily stored in a memory buffer to provide standardized data for subsequent file matching. The Tkinter framework is a built-in graphical user interface development toolkit for Python, requiring no additional installation, supporting cross-platform compatibility (Windows, Linux), and enabling the rapid construction of interactive interfaces with components such as buttons and selectors, lowering the barrier to entry for non-developers. ConfigParser is a Python module used to parse INI format configuration files. It can read "data blocks (such as [MD5_CHECK])" and "key-value pairs" in the configuration file, supports adding, deleting, modifying and querying configuration content, and is adapted to the standard format of vehicle-mounted flashing configuration files.

[0018] Step 102: Based on the target folder to be written, match the file names in the file name list with the file names in the target folder and its subfolders, and determine the file whose file name matches the target file.

[0019] In this step, the target folder is the directory where the flashing configuration file to be updated is stored. It may contain multiple levels of subfolders and is the source of the update files. The target file is the file whose filename is matched, confirmed to require MD5 verification, and written to the configuration file. It is the core processing object in the update process.

[0020] After obtaining the filename list in step 101, the selected target folder (containing the new version files to be burned) is traversed using either Depth-First Search (DFS) or Breadth-First Search (BFS) to obtain the names of all files. The filename list obtained in step 101 is then matched with the traversal results. The matching rule is to match the filename exactly (including the extension), ignoring path differences (because files may be stored in subfolders). During filtering, a filename hash table (such as a Pythonset set) is created, and matching files are quickly located through hash lookup. Invalid files not in the list are excluded, ultimately forming a target file list (including the complete path). If there are files with the same name, the file with the most recent modification time is selected first, or the file is filtered according to a preset path priority rule. Through the "intelligent matching + target file filtering" scheme, efficient and accurate matching between the filename list and target files is achieved, solving the problems of time-consuming manual file searching, matching failure after path changes, and confusion caused by multiple selections of files with the same name.

[0021] Step 103: Calculate the MD5 hash value of the target file using a block-based streaming processing method.

[0022] In this step, chunked streaming processing reads the contents of the target file in fixed-number-byte chunks. While reading the second data block, the MD5 hash value of the first data block is calculated. The first and second data blocks are read adjacently. The fixed-number of bytes is not limited here and is set according to the system settings. It is worth noting that the timestamp for calculating the MD5 hash of the last data block in chunked streaming processing is the time when the last data block has been read.

[0023] After selecting the target files in step 102, the MD5 hash value of each target file is calculated using a block-based streaming processing method. First, a fixed block size is set (e.g., 4KB, 8KB, which can be dynamically adjusted according to the vehicle system's memory configuration). The file content is read block by block using a file stream reading interface (e.g., C++'s `fread` or Python's `read` method). After each block is read, the MD5 hash algorithm interface (e.g., OpenSS's `MD5_Update` function) is immediately called to update the hash state (i.e., accumulate the hash value of the current block), without waiting for the entire file to finish loading. Once the file is fully read, the `hash_final` interface is called to generate the final target MD5 hash value (a 128-bit binary number, typically converted to a 32-bit hexadecimal string). During this process, multiple target files are processed in parallel using multi-threading to further improve efficiency.

[0024] It is worth noting that in this step, when the second data block is read, the MD5 value of the first data block is calculated. The first data block may include a first preset number of adjacent data blocks, and the second data block may include a second preset number of adjacent data blocks. The first preset number and the second preset number may be the same or different.

[0025] Step 104: Write the first data block, the second data block, the MD5 hash value of the first data block, and the MD5 hash value of the second data block into the [MD5_CHECK] data block of the target file to obtain the burning configuration file.

[0026] In this step, the burning configuration file is the final output file that integrates all necessary verification information and configuration parameters. It will be used to guide the vehicle-mounted burning program to perform accurate and secure write operations. The specific implementation process is as follows: First, the system reads the target file determined in step 102 and its final MD5 hash value calculated in step 103 through block streaming processing from the memory buffer. Then, it calls the configuration file processing engine (such as Python's ConfigParser module) to create a new configuration file structure or directly load a copy of the initial configuration file into memory. The engine first copies all original data blocks (such as [BOOT_PARAMS], [FLASH_SETTINGS], etc.) and their corresponding key-value pairs from the initial configuration file, except for the [MD5_CHECK] data block, to the new configuration file, ensuring that the underlying parameters and configuration instructions required for burning are completely preserved.

[0027] Next, the engine will specifically process the [MD5_CHECK] data block. It will create or clear and rewrite this data block, and write the filename of each target file (as the key) and its corresponding final MD5 hash value (as the value) line by line into the data block in the standard key-value pair format of "filename=MD5 value". This process ensures that the verification information corresponds precisely to the target file. To ensure the absolute reliability of the generated file, a write verification mechanism is introduced in this step. After the configuration file is written to the disk, the system will immediately read the newly generated burning configuration file again and reverse parse its [MD5_CHECK] data block. The system will perform a strict secondary comparison between the extracted MD5 value and the MD5 hash value calculated in step 103 cached in the memory buffer. If the comparison matches, the verification is passed, indicating that the burning configuration file is successfully generated and the process ends; if the comparison does not match, a rollback operation is automatically triggered, that is, the generated incomplete or incorrect configuration file is deleted, and the error information is recorded in the system log, and a pop-up window is displayed to the user interface prompting "Configuration file generation failed, please check the file integrity and try again". Ultimately, the successfully generated burning configuration file contains the latest and most accurate file verification information and stable device configuration parameters, providing a reliable data foundation for the accurate and efficient burning of vehicle-mounted devices.

[0028] In summary, the method for generating hash values ​​for flashing configuration files provided in this application avoids a full traversal of the target folder and reduces the overhead of handling invalid files by matching a list of filenames and filtering target files. Furthermore, it employs a block-based streaming method to calculate the MD5 hash value of the target files, allowing calculation to begin without waiting for the entire file to load, thus achieving parallel processing of file reading and hash calculation. This method shortens the overall time required for updating large firmware files or multiple files in batches, improving the efficiency of updating vehicle-mounted flashing configuration files.

[0029] Furthermore, this application provides a more detailed embodiment of hash value generation when updating configuration files in an in-vehicle embedded environment, such as... Figure 2 As shown, the details are as follows: Step 201: Obtain the list of filenames in the [MD5_CHECK] data block from the initial configuration file required by the vehicle-mounted burning program.

[0030] In this step, when the size of the target file to be written is greater than a preset value, the specific implementation method for obtaining the initial configuration file required for the vehicle-mounted burning program can be to select the initial configuration file through a computer operation display interface built with the Tkinter framework. The computer operation display interface is provided with a dual path selector, which is used to select the initial configuration file and the target folder respectively. After selection, the path of the initial configuration file and the path of the target folder are cached to the storage module.

[0031] Specifically, the initial configuration file acquisition combines the flexibility of the Tkinter framework with the practicality of automotive scenarios, resulting in an innovative and user-friendly solution, as follows: A lightweight GUI (display interface on a computer) is built using the Tkinter framework. The core component integrates a dual-path selector, enabling one-stop selection of the initial configuration file and the target folder. The interface layout uses a left-right split design: the left side is the "initial configuration file selection area," and the right side is the "target folder selection area." Each selection area includes a "path display box," a "browse button," and a "confirm button." Clicking the "browse button" calls Tkinter's filedialog module: the initial configuration file selector defaults to filtering .ini configuration files (limited by the filetypes parameter), and the target folder selector directly calls the askdirectory function to open the directory selection window. After selection, the path is automatically filled into the corresponding display box. Clicking the "confirm button" triggers caching logic, storing the two paths as key-value pairs (e.g., {"config_path": "xxx", "folder_path": "xxx"}) in the local storage module. By employing a dual-mode of "memory caching + file backup," paths are cached in memory in real-time via a global dictionary for immediate program access, while paths are written to the vehicle system's non-volatile storage (e.g., EEPROM or a small local JSON file) to prevent path loss after program restart. In addition, the interface adds a "path verification" function, which automatically checks whether the selected file / folder exists and whether it has read and write permissions. If an anomaly is found, a red warning pop-up window (including the reason for the error) will appear, and one-click reselection is supported to ensure the validity of the path. This solution achieves one-stop efficient selection of the initial configuration file and the target folder, avoids path loss through dual-mode caching, and performs real-time path verification to troubleshoot errors. It balances ease of operation with stability in in-vehicle scenarios, significantly improving the efficiency and accuracy of configuration file acquisition.

[0032] It is worth noting that parsing the initial configuration file to obtain the list of filenames in the [MD5_CHECK] data block includes: parsing the initial configuration file using ConfigParser; if no [MD5_CHECK] data block is detected after parsing, a warning pop-up window is displayed on the computer operation display interface to prompt the user that the configuration is missing; if the [MD5_CHECK] data block is detected, the list of filenames is extracted.

[0033] Specifically, the core of parsing the initial configuration file to obtain the list of filenames is to achieve structured parsing and exception handling through ConfigParser. The specific process is as follows: First, the parser instance is initialized by calling Python's ConfigParser module, and the "preserve case" configuration is enabled (to avoid filename case confusion). The initial configuration file selected by the user is read using the read() method (supports .ini format). Encoding adaptation logic is added during parsing (default UTF-8, automatically trying GBK encoding in case of exceptions) to prevent parsing failures caused by Chinese comments or special characters. Next, the parser's `has_section()` method checks if the `[MD5_CHECK]` data block exists. If the result is `False`, a warning pop-up window is immediately triggered on the GUI interface, titled "Configuration Missing," clearly stating "No `[MD5_CHECK]` data block detected. Please check the integrity of the configuration file." Two buttons, "Confirm" and "Reselect File," are provided for quick user processing. If the result is `True`, the `sections()` and `items()` methods are called to extract all key-value pairs under the data block. Key names are filtered to form a list of filenames (ignoring the old MD5 value after the equals sign), which is then converted into a deduplicated list data structure for subsequent file matching steps. Based on the above steps, adaptive encoding parsing avoids cross-platform file reading errors. Combined with pop-up interaction, it provides immediate feedback and rapid correction of anomalies. Simultaneously, accurate key name extraction ensures the integrity of the filename list, balancing parsing efficiency and user experience, perfectly adapting to the stability requirements of configuration file processing in automotive scenarios.

[0034] Step 202: Obtain the target file using fuzzy matching.

[0035] In this embodiment, a more specific implementation method for obtaining the target file is given, as follows: Based on os.walk() combined with fuzzy matching of filenames, the target folder is traversed through multiple levels of directories to determine the target file. The fuzzy matching method is case-insensitive. After extracting the filename from the filename list, the target folder and its subfolders are recursively searched for files with the same name. Once the first matching file is found, it is determined to be the target file.

[0036] Specifically, first, the Python os.walk() function is called to initialize a multi-level directory recursive scan task, using the target folder path selected by the user as the root directory for scanning. During execution, this function automatically traverses all subfolders under the root directory, returning the absolute path of the currently traversed folder, a list of subfolders, and a list of files, forming a hierarchical data structure of "directory-file". This ensures that all files within the target folder and its subfolders are covered without omission, solving the problem of missing subfolder files in traditional single-level directory scanning. During the scanning process, a fuzzy filename matching logic is simultaneously initiated: filenames to be matched are extracted one by one from the obtained structured filename list and converted to lowercase; simultaneously, each filename returned by the os.walk() function is also uniformly converted to lowercase, achieving case-insensitive fuzzy matching through string equality comparison, adapting to the case differences in filenames that may occur when different people operate in automotive scenarios (e.g., "Firmware.bin" and "firmware.bin" are considered the same file). To avoid processing chaos caused by multiple selections of files with the same name, a "priority matching termination mechanism" is designed: when the first matching file matching the conditions is found during the recursive scanning process for a certain filename, the search process for that filename in subsequent subfolders is immediately terminated, and the process is terminated using os.path.abspath. The `()` function retrieves the absolute path of the matching file and marks it as the target file. Simultaneously, it stores the target file's filename, absolute path, matching time, and other information in a structured list, providing a clear file index for subsequent block-based streaming MD5 hash value calculation. This improves matching efficiency and ensures the uniqueness and accuracy of the target file selection. It's worth noting that after matching the filenames in the filename list with the files in the target folder and its subfolders, for files with identical names, the historical MD5 hash value corresponding to that filename in the initial configuration file's `[MD5_CHECK]` data block is compared with the temporary MD5 value of the matched file (generated by quickly calculating the first 1KB of file header data). If they match, the file is considered an unchanged duplicate and requires no update; otherwise, it is confirmed as a valid file to be updated and retained as the target file.

[0037] Step 203: Calculate the MD5 hash value of the target file using a block-based streaming processing method.

[0038] In this embodiment, before calculating the MD5 hash value of the target file using a block-based streaming processing method, the following steps are included: determining the readability of the target file; if the target file is readable, performing the MD5 hash value calculation step; if the target file is unreadable, displaying an error pop-up window in the GUI interface to prompt the user.

[0039] Specifically, the readability of a target file is determined through a "dual verification + intelligent feedback" mechanism, balancing verification accuracy with ease of operation in in-vehicle scenarios. The specific process is as follows: First, basic permission verification is initiated: the Python function `os.access()` is called, passing in the absolute path of the target file and the `os.R_OK` (read permission flag) parameter, to check if the file has read permissions; simultaneously, the function `os.path.exists()` is called to verify if the file exists. If the file does not exist or does not have read permissions, it is directly determined to be unreadable. Second, for files that pass the basic verification, a deep availability verification is initiated: the file is attempted to be opened in "read-only + binary" mode ("rb"). If exceptions such as `FileNotFoundError` or `PermissionError` are triggered during the opening process, the exceptions are captured and the file is determined to be unreadable; if the file is successfully opened, the first 100 bytes of data are read and the file is immediately closed to verify that the file is not corrupted and the data can be read normally, ultimately determining that it is readable. The verification result feedback uses a layered GUI prompt: when the file is unreadable, the pop-up title is set to "File Unreadable," and the content provides precise prompts based on the exception type (e.g., "File does not exist, please check the path," "No read permission, please adjust permission settings," "File corrupted, cannot be read"), and a "Re-match File" button is provided; when the file is readable, the GUI status bar displays "[File name] has passed readability verification, MD5 to be calculated" in real time, and the file path is simultaneously added to the calculation queue to prepare for subsequent block-based streaming processing. This solution accurately determines the readability of the target file through dual verification, provides layered pop-up prompts for the reasons for exceptions, and updates the status bar progress synchronously. This avoids subsequent calculation errors, lowers the user's operational threshold, and adapts to the efficient troubleshooting and stable processing requirements of automotive scenarios.

[0040] In this embodiment, the target file is processed using a block-based streaming method to calculate the MD5 hash value, including: opening the target file in binary read mode and reading the fixed-size data blocks in a loop; updating the current hash state of the data block immediately after reading each data block and discarding the processed data block content to release memory; and generating the final MD5 digest value after the target file is read.

[0041] Specifically, first, the target file is opened in "read-only + binary" mode ("rb"), which avoids text encoding interference and accurately reads the raw data of binary files such as vehicle firmware, providing a foundation for accurate hash calculation. Next, a fixed data block size of 4096 bytes is set (to adapt to the memory resources of the vehicle embedded system and balance I / O efficiency and memory usage), and a hashlib.md5() hash object is initialized to store the real-time hash state. Then, a loop reading mechanism is started: the file content is read block by block using the generator pattern (iter(lambda: f.read(4096),b"")). After each block is read, the hash object's update() method is immediately called to update the current hash state. Simultaneously, Python's garbage collection mechanism automatically discards processed data blocks, releasing memory space and avoiding memory accumulation during large file processing. Once the entire file has been read, the hash object's hexdigest() method is called to generate a 32-bit hexadecimal final MD5 digest value. After the calculation is complete, the file handle is closed, and file resources are released. Ensuring calculation accuracy through binary reading, block processing and instant memory release adapt to the resource constraints of the vehicle system, and enabling parallel calculation without fully loading the file, significantly improving the MD5 calculation efficiency of large files and batch files, and reducing the risk of memory consumption.

[0042] Step 204: Write the MD5 hash value after processing the block stream into the [MD5_CHECK] data block of the target file to obtain the burning configuration file.

[0043] In this embodiment, after updating the hash value of the burning configuration file, the process includes: persistently storing the obtained burning configuration file, and sending a process completion notification to the user after storage is completed. The process completion notification is used to inform the user that the target burning configuration file has been generated.

[0044] Specifically, after the MD5 hash status and target MD5 hash value are written back to the initial configuration file [MD5_CHECK] data block, a "dual backup persistence + tiered notification" mechanism is initiated to ensure that the configuration file is securely stored and that users can monitor the process progress in real time. The specific implementation is as follows: First, persistent storage operations are performed: the file operation module is invoked to write the modified configuration file, named in the format "original filename_update time.ini" (e.g., "config_202411101630.ini"), to the non-volatile storage partition of the vehicle system (such as a specified directory of EEPROM or vehicle SSD), serving as the primary storage file. Simultaneously, a backup file in the format "original filename_backup.ini" (e.g., "config_backup.ini") is generated in the same directory. The backup file retains only the original configuration data before this update, forming a double-insurance storage structure of "primary file + backup file" to prevent configuration loss due to primary file write failure or corruption. During storage, file read / write permissions are locked using a file locking mechanism (such as Python's fcntl module) to prevent file content corruption caused by simultaneous operations by multiple processes.

[0045] Secondly, the system triggers a notification upon completion of the process: After the storage operation is completed, the system first pops up a modal notification window through the GUI interface, with the window titled "Configuration Update Complete" and clearly displaying "Target configuration file has been generated, main file path: XXX, backup file path: XXX, MD5 information of XX files updated this time." Simultaneously, the system calls the vehicle system's status bar notification interface to generate a persistent notification in the system status bar (which disappears automatically after 5 minutes), allowing users to click the status bar notification to jump to the configuration file storage directory. If the vehicle system supports voice broadcasting, a short voice notification is triggered simultaneously (e.g., "Configuration file update complete, please confirm use"). Through multi-dimensional notification methods, the system ensures users are promptly informed of the process results, adapting to the diverse operational needs of users in vehicle scenarios. The system ensures configuration storage security through "dual files (primary and backup) + file lock," avoiding write failures or multi-process conflicts. Multi-dimensional notifications—GUI pop-ups, status bar prompts, and voice broadcasts—ensure users are promptly informed of the results, adapting to vehicle scenarios and balancing data security with ease of operation.

[0046] It is worth noting that this application provides specific examples for the above embodiments, as follows: (1) Real-time scene background This embodiment applies to the software burning preprocessing scenario of the railway signaling system's onboard equipment safety computer platform (CVC-300C). It focuses on the core requirement of batch updating the MD5 hash value of the [MD5_CHECK] data block in the burning configuration file when iterating new software and data in an onboard embedded environment. The new file to be processed in this embodiment contains three core components: first, the firmware_v2.0.bin onboard firmware file, approximately 500MB in size, which is the core program file for the onboard equipment and must be kept intact to avoid equipment failure after burning; second, the app_config.xml application configuration file, approximately 2MB in size, which records the operating parameters of the onboard application, and its accuracy directly affects the application's functional compatibility; and third, the data_package.zip data compressed package, approximately 80MB in size, which contains basic data such as maps and log templates required by the onboard equipment and needs to be verified using MD5 to prevent data tampering.

[0047] The initial configuration file is a .ini file, which serves as the basic guidance file before the vehicle-mounted programming program runs. It contains three key data blocks: [GLOBAL], [UPDATE_BOARD_TYPE], and [MD5_CHECK]. The [GLOBAL] block defines basic parameters such as the programming mode and port; the [UPDATE_BOARD_TYPE] block specifies device information such as the device model and hardware version; and the [MD5_CHECK] block records the name of the configuration file to be programmed and its corresponding MD5 hash value. This is the core module ensuring the integrity of the programmed configuration file. Initially, the MD5 hash value of the file to be updated is the old version data, which needs to be updated to the new version's MD5 hash value using the method described in this application to meet the verification requirements of the vehicle-mounted programming program.

[0048] The hardware environment relied upon in this embodiment is an in-vehicle embedded computer, specifically configured with a CPU of ARM Cortex-A9, 2GB of memory, and 64GB of EEPROM. This configuration meets the resource constraints of the in-vehicle embedded environment. The software environment is a Python 3.8 runtime environment, integrating the Tkinter framework (for building GUI interactive interfaces), the ConfigParser module (for parsing INI format configuration files), the os module (for directory traversal and file operations), and the hashlib module (for MD5 hash value calculation). It is compatible with the Windows 10 IoT Enterprise operating system commonly used in in-vehicle systems, ensuring that the technical solution can run stably in the actual in-vehicle environment.

[0049] (2) Preparations before implementation File path and initial configuration settings: The initial configuration file is burning configuration.ini, stored in D:\Vehicle Burning System\Configuration Directory\Burning Configuration.ini, in INI format, conforming to the vehicle burning program reading standard, and contains three data blocks: [MD5_CHECK], [GLOBAL], and [UPDATE_BOARD_TYPE]. The [MD5_CHECK] data block records the old MD5 hash values ​​of the three files firmware_v2.0.bin, app_config.xml, and data_package.zip, which need to be updated to the new values ​​this time; the [GLOBAL] data block contains parameters such as burning mode, port, and timeout; the [UPDATE_BOARD_TYPE] block contains information such as device model, hardware version, and compatible software version. These two data blocks must remain unchanged during the update process to ensure the normal operation of the burning program. The target folder path for storing the new version files is D:\Vehicle Burning System\New Resource Directory\, and it uses a multi-level subdirectory classification for storage: firmware_v2.0.bin is stored in the firmware subdirectory, which is dedicated to storing the core vehicle firmware files to avoid file confusion; app_config.xml is stored in the configuration subdirectory for centralized management of application configuration files and to reduce the risk of accidental operation; data_package.zip is stored in the data subdirectory for convenient batch transmission and storage of compressed data files, which complies with the vehicle system file management specifications.

[0050] Tool Initialization and Environment Check. Upon launching the "Vehicle Burning Configuration Update Tool," the GUI interface loads automatically. The interface features a left-right split layout with a bottom status bar. The left-side "Initial Configuration File Selection Area" includes a path display box, a browse button, and a confirm button. The browse button calls the relevant module to pop up a file selection window, filtering for .ini format files by default. The confirm button triggers path caching and configuration parsing. The right-side "Target Folder Selection Area" has the same component layout as the left. The browse button pops up a directory selection window, and the confirm button triggers path caching and file matching. The bottom status bar displays the operation progress in real time and also includes a log viewing button. Clicking this button allows you to view detailed logs containing operation time, content, and results, facilitating troubleshooting.

[0051] After the tool starts, it automatically performs the following environment checks: First, a Python module integrity check verifies whether core modules such as Tkinter, ConfigParser, os, and hashlib are loaded correctly. If any are missing, a pop-up window will prompt the user and explain how to install them. Second, a storage permission check checks the read and write permissions of the initial configuration file directory and the target folder. If permissions are insufficient, a pop-up window will prompt the user and provide adjustment guidance. Third, a memory and storage space check ensures that the vehicle's computer has at least 512MB of remaining memory and the target folder has at least 1GB of remaining disk space. If these are insufficient, a pop-up window will prompt the user to release resources. If the environment check passes, the status bar will display "Environment check passed, you can start operating," and the user can proceed with subsequent selections. If the check fails, the problem must be resolved and the check repeated.

[0052] (3) Specific steps In the initial configuration file acquisition and parsing phase, the user first opens a window titled "Select Initial Configuration File" using the "Browse" button in the "Initial Configuration File Selection Area" on the left side of the GUI interface. This window filters .ini format files by default. The user navigates to the path D:\Vehicle Burning System\Configuration Directory\, selects the burning configuration .ini file, and clicks "OK." At this point, the "Path Display Box" on the interface will show the complete path of the file in real time. After the user clicks the "OK" button, the tool will activate the path caching logic, storing the initial configuration file path as key-value pairs in two locations: one is the vehicle system's EEPROM (non-volatile storage), which prevents the path from being lost after the tool restarts, ensuring the continuity of the entire process; the other is the tool's global memory dictionary, which facilitates quick access in subsequent configuration file parsing steps and avoids repeated EEPROM reading affecting efficiency. After the path caching is complete, the bottom status bar will display "Initial configuration file path cached, starting configuration file parsing." Next, the tool enters the configuration file parsing and encoding adaptation stage. It calls the ConfigParser module to initialize the parser instance. To ensure that the case of filenames and configuration parameters remains unchanged during parsing, a "case-preserving" configuration is enabled to avoid filename matching errors due to case conversion. The parser first attempts to read the burning configuration .ini file in the cache path using UTF-8 encoding. If an encoding error occurs during reading, such as the file actually being encoded in GBK, the tool automatically triggers encoding adaptation logic, switching to GBK encoding to reread the file. This ensures that Chinese comments, special characters, and other content can be correctly parsed, preventing configuration file parsing failures due to encoding issues. Afterward, it performs [MD5_CHECK] data block verification and filename list extraction. The parser calls relevant methods to check if the [MD5_CHECK] data block exists in the initial configuration file. This is the second level of verification in the "two-level verification" (the first level is the configuration file format validity verification). If the detection result indicates that the configuration file is missing, the tool will immediately display a warning pop-up window titled "Configuration Missing," stating "No [MD5_CHECK] data block detected. Please check the integrity of the configuration file and try again." The pop-up window has two buttons: "Confirm" and "Reselect File." Clicking "Reselect File" will return the user to the configuration file selection steps, allowing them to reselect a configuration file containing the [MD5_CHECK] data block. If the detection result indicates that the configuration file exists, the parser will call a method to extract all key-value pairs under that data block. It will then iterate through the key-value pairs to filter out the key names (i.e., the filename to be updated) and perform invalid character cleanup, removing any spaces, newlines, tabs, or other invalid characters from the key names to ensure the accuracy of the filename.After the cleanup is complete, a structured list of filenames ["firmware_v2.0.bin","app_config.xml", "data_package.zip"] is generated and temporarily stored in the tool's memory buffer to provide a standardized data source for subsequent file matching steps. At this time, the bottom status bar displays "Configuration file parsing successful, 3 filenames to be matched have been extracted, target folder can be selected", and the "Log View" window will record "[Time] Initial configuration file parsing completed, filenames to be matched firmware_v2.0.bin, app_config.xml, and data_package.zip extracted".

[0053] In the target folder selection and file matching filtering stage, the user clicks the "Browse" button in the "Target Folder Selection Area" on the right side of the GUI interface. The tool pops up a directory selection window titled "Select Target Folder." The user locates D:\Vehicle Burning System\New Resource Directory\ in the window and clicks "OK." The "Path Display Box" will then display the folder path in real time. After the user clicks the "OK" button, the tool triggers the target folder path caching logic, storing the path as key-value pairs in the EEPROM and the global dictionary in memory, managing it together with the initial configuration file path. At the same time, the tool automatically performs a target folder validity check, verifying the existence of the folder and whether it has read and write permissions through relevant functions. If the check passes, the bottom status bar displays "Target folder path has been cached, file matching begins"; if the folder does not exist or does not have permissions, a pop-up window will prompt the user "Target folder [path] does not exist / does not have read and write permissions, please select again," and return to the folder selection step. Subsequently, multi-level directory traversal and file information retrieval are performed. The tool calls relevant functions to perform a depth-first recursive traversal of the target folder. During the traversal, the function returns three parameters in sequence: the absolute path of the currently traversed directory, a list of subdirectories under that directory, and a list of files under that directory. By iterating over these three parameters, the tool achieves a complete traversal of the target folder and all its subfolders, ensuring that information on all files is obtained without omission. During the traversal, the tool stores information such as the absolute path, filename, and modification time of each file in a temporary list, forming a structured file information dataset to facilitate subsequent file matching operations. For example, when traversing D:\Vehicle Burning System\New Resource Directory\Firmware Subdirectory\, the absolute path of firmware_v2.0.bin is D:\Vehicle Burning System\New Resource Directory\Firmware Subdirectory\firmware_v2.0.bin, the filename is firmware_v2.0.bin, and the modification time is "2024-05-20 14:30:00", and this information is stored in the temporary list. Finally, fuzzy matching and target file determination are performed. The tool performs fuzzy matching based on the list of filenames and the file information dataset. The matching strategy follows the principle of "case-insensitive matching + priority matching termination" to ensure the accuracy and efficiency of the matching.First, case sensitivity is uniformized by converting each filename in the filename list in the memory buffer to lowercase, and simultaneously converting all filenames in the file information dataset to lowercase as well. This avoids matching failures due to case differences and accommodates different naming habits among different operators. Next, filename comparison and matching are performed by iterating through the filename list and comparing each filename with a filename in the file information dataset. If a match is found, the file is identified as a potential target file. Finally, a priority matching termination mechanism is executed. When a filename finds its first match, the search for that filename in subsequent subfolders is immediately terminated. This avoids confusion caused by multiple copies of the same filename and improves matching efficiency. The absolute path of the matched file is obtained using relevant functions, and it is marked as the final target file. The filename, absolute path, and modification time of the target file are stored in the target file list. In this embodiment, the complete information of three target files was successfully determined through the above matching process. After matching is complete, the bottom status bar displays "File matching complete, 3 target files found, readability verification begins," and the log window records "[Time] File matching complete, target file list: [File information list]."

[0054] During the target file readability verification and MD5 hash value calculation stages, a dual readability verification is first performed. To avoid subsequent MD5 calculation failures due to file corruption, insufficient permissions, or other issues, the tool executes a dual verification process of "basic permission verification + deep availability verification" for each file in the target file list. Basic permission verification checks whether the file has read permissions and whether it exists by calling relevant functions. If the file does not exist or lacks read permissions, it is directly determined to be unreadable. Deep availability verification attempts to open files that pass the basic permission verification in "read-only + binary" mode. If exceptions such as file non-existence, insufficient permissions, or mistaking a directory for a file are triggered during the opening process, these exceptions are captured, and the file is determined to be unreadable. If the file is successfully opened, the first 100 bytes of data are read, and the file is immediately closed to verify that the file is not corrupted and the data can be read normally, ultimately determining it to be readable. In this embodiment, all three target files pass dual verification, and the bottom status bar displays "All three target files have passed readability verification, starting MD5 hash value calculation." If a file becomes unreadable due to insufficient permissions, the tool will pop up an error window titled "File Unreadable," indicating "File [path] does not have read permissions. Please adjust permission settings and try again." The pop-up window has two buttons: "Re-verify" and "Re-match Files." Users can choose the corresponding operation based on the actual situation and re-execute the verification process after resolving the problem. Next, block-based streaming MD5 hash value calculation is performed. For the target files, the tool uses a block-based streaming processing method to calculate the MD5 hash value. This method does not require loading the entire file into memory, effectively reducing memory usage and adapting to the resource constraints of automotive embedded systems. During the initialization phase, the target file is opened in "read-only + binary" mode. This mode avoids interference from text encoding on the original file data and ensures the accuracy of MD5 hash value calculation, which is especially suitable for binary firmware files such as firmware_v2.0.bin. At the same time, a hash object is initialized to store the real-time hash calculation status, and a fixed block size of 4096 bytes is set. This size has been verified through multiple tests and can balance I / O read efficiency and memory usage under the hardware configuration of the vehicle system, avoiding frequent I / O operations caused by too small blocks or excessive memory usage caused by too large blocks. During the streaming processing phase, file data blocks are read in a loop using the generator pattern. The generator pattern enables on-demand reading of data blocks, avoiding the generation of large amounts of data at once that would consume memory. After each data block is read, the relevant methods of the hash object are immediately called to incorporate the information of the data block into the current hash state, enabling real-time updates of the hash value. Processed data blocks are automatically discarded through Python's garbage collection mechanism, freeing up memory space and ensuring that when processing the 500MB firmware_v2.0.bin file, memory usage remains at around 4KB, far below the memory limit of the in-vehicle system.During the exception handling phase, if disk errors or file corruption occur during data block reading and hash update, the tool captures the exception and immediately terminates the calculation process, closes the file handle to release resources, and simultaneously displays an error pop-up message to the user: "An exception occurred while calculating the MD5 hash value of file [filename]. Please check the file integrity or storage device status." The exception details are also recorded in the log window for subsequent troubleshooting. In the result generation phase, after all data blocks of the file have been read and processed, the relevant methods of the hash object are called to generate a 32-bit hexadecimal MD5 digest value. This format meets the requirements of the vehicle-mounted programming program for reading MD5 hash values. The file handle is closed to release file resources and prevent resource leaks. The calculated MD5 hash value is associated with the absolute path of the target file and stored to form a dictionary structure for subsequent MD5 hash value write-back operations. In the result processing and verification stage, after the MD5 hash values ​​of the three target files are calculated, the tool processes the calculation results and forms a table. At the same time, it performs preliminary verification of the results, such as checking whether the MD5 hash value length is 32 bits and whether it conforms to the hexadecimal format, to ensure the validity of the results. After the calculation results are verified, the bottom status bar displays "MD5 hash value calculation completed, a total of 3 valid MD5 hash values ​​were obtained, starting to write back to the configuration file", and the log window records "[Time] MD5 calculation completed, result: [MD5 result table]".

[0055] Finally, the MD5 hash value write-back and configuration file update stage begins. First, the MD5 hash value is written back to the [MD5_CHECK] data block. The tool then calls the ConfigParser module again to open the initial configuration file (.ini) in "read-write" mode, ensuring that it can both read the configuration file content and modify the information in the [MD5_CHECK] data block. By looping through the dictionary structure, the tool extracts the filename (parsed from the absolute path) and its corresponding MD5 hash value for each file. It then finds the entry in the [MD5_CHECK] data block corresponding to that filename and replaces the old MD5 hash value with the newly calculated one. During the write-back process, the tool strictly maintains the original format of the configuration file and the content of other data blocks, only modifying the MD5 hash value of the file to be updated in the [MD5_CHECK] data block. This avoids format corruption or other parameter modifications that could prevent the programming program from reading the configuration file correctly. After the write-back is complete, the [MD5_CHECK] data block will be updated to contain the new MD5 hash value. Next, persistent storage and backup of the configuration file are performed. To ensure the security and recoverability of the updated configuration file, the tool adopts an "atomic write + dual backup" persistent storage strategy. During atomic write, the modified configuration file content is first written to a temporary file located at D:\Vehicle Burning System\Configuration Directory\Burning Configuration_Temporary.ini. During the write process, a file locking mechanism is used to lock the temporary file to prevent file content corruption caused by simultaneous operations of multiple processes. After the write is completed, the integrity of the temporary file is verified, such as checking whether the file size and content are consistent with expectations. If the verification is successful, the original configuration file burning configuration.ini is deleted, and the temporary file is renamed to burning configuration.ini. This ensures that the configuration file update is either completely successful or does not modify the original file, avoiding damage to the original file due to power outages, storage errors, or other issues. Dual backups automatically generate two backup files after the atomic write operation: one is a "timestamp backup file," named in the format of "burn configuration_update time.ini," stored in the same path as the original configuration file, used to record the configuration content of each update for easy tracing of historical versions; the other is an "original backup file," named in the format of "burn configuration_original backup.ini," storing the content of the original configuration file before the update. If the updated configuration file has problems, it can be quickly restored to the state before the update through this backup file, reducing the loss of data due to failure. Finally, update completion notifications and result confirmations are provided. After the configuration file is persistently stored, the tool provides feedback to users on the update results through multi-dimensional notification methods to adapt to users' operating habits and information access needs in automotive scenarios.A GUI pop-up notification will appear as a modal notification window titled "Configuration Update Complete." The window clearly displays the update results, including the target configuration file, timestamp backup file, the path to the original backup file, and the number of files updated. The pop-up has three buttons: "Confirm," "Open Configuration File Directory," and "View Log." Clicking "Open Configuration File Directory" will directly take the user to the configuration file storage directory, while clicking "View Log" will open a log window to view detailed update logs. A persistent status bar notification will be generated in the vehicle system's status bar, displaying the message "Vehicle configuration file update complete, ready for vehicle programming." This notification will remain for 5 minutes before automatically disappearing to avoid occupying status bar space for an extended period and to ensure the user has sufficient time to receive the notification. If the vehicle system supports voice functionality, a voice announcement will also be triggered, stating "Vehicle configuration file update complete, please confirm use," supplementing the visual notification with auditory information to ensure the user is aware of the update results while operating other devices. After the user clicks the "Confirm" button to close the pop-up window, the status bar at the bottom of the tool displays "The configuration file update process is complete. You can exit the tool or perform a new update operation." At this point, the entire process of updating the vehicle-mounted flashing configuration file is complete. The updated configuration file can be directly used for the vehicle-mounted flashing program, ensuring the integrity and accuracy of the flashing configuration file.

[0056] Furthermore, as a response to the above Figure 1-2 In addition to the implementation of the method embodiment shown, this embodiment of the invention also provides a device for generating a hash value of a burning configuration file. This device is used to quickly and automatically determine the hash value of the updated burning configuration file during the updating process of a vehicle-mounted embedded configuration file. The embodiment of this device corresponds to the foregoing method embodiment. For ease of reading, this embodiment will not repeat the details of the foregoing method embodiment, but it should be clear that the device in this embodiment can implement all the contents of the foregoing method embodiment. Specifically, as shown... Figure 3 As shown, the device includes: The selection unit 31 is used to obtain the initial configuration file of the vehicle-mounted burning program when the size of the target file to be written is greater than a preset value, and to parse the initial configuration file to obtain the list of filenames in the [MD5_CHECK] data block; The filtering unit 32 is used to match the file names in the file name list in the selection unit 31 with the file names in the target folder and its subfolders based on the target folder to be written, and to determine the file whose file name matches as the target file; The calculation unit 33 is used to calculate the MD5 hash value of the target file in the filtering unit 32 using a block-based streaming processing method. The block-based streaming processing method reads the content of the target file in blocks of a fixed number of bytes, and calculates the MD5 hash value of the first data block when reading the second data block. The first data block and the second data block are adjacent data blocks read. Generation unit 34 is used to write the first data block, the second data block, the MD5 hash value of the first data block, and the MD5 hash value of the second data block from calculation unit 33 into the [MD5_CHECK] data block of the target file to obtain the burning configuration file. Further, such as... Figure 4 As shown, the selection unit 31 includes: The construction module 311 is used to select the initial configuration file through a computer operation user interface built using the Tkinter framework. The GUI interface is provided with a dual path selector, which is used to select the initial configuration file and the target folder respectively. After selection, the path of the initial configuration file and the path of the target folder are cached to the storage module.

[0057] Furthermore, such as Figure 4 As shown, the filtering unit 32 includes: The traversal module 321 is used to traverse the multi-level directories of the target folder based on os.walk() combined with the fuzzy matching method of filenames to determine the target file. The fuzzy matching method is case-insensitive for filenames. After extracting the filename from the filename list, it recursively searches for files with the same name in the target folder and its subfolders. After finding the first matching file, it determines the first matching file as the target file.

[0058] Furthermore, such as Figure 4 As shown, the judgment unit 35 includes: Module 351 is used to determine the readability of the target file; The judgment module 351 is used to perform the MD5 hash value calculation step if the target file is readable. The judgment module 351 is used to display an error pop-up window on the computer operation user interface to prompt the user if the target file is unreadable.

[0059] Furthermore, such as Figure 4 As shown, the computing unit 33 includes: Reading module 331 is used to open the target file in binary reading mode and read the fixed-size data blocks in a loop; The update module 332 is used to immediately update the current hash state of each data block read from the read module 331 and discard the processed data block content to free up memory. Module 333 is used to generate the final MD5 digest value after the target file is read in update module 332.

[0060] Furthermore, such as Figure 4 As shown, the selection unit 31 includes: Parsing module 312 is used to parse the initial configuration file using ConfigParser; The parsing module 312 is used to display a warning pop-up window in the GUI interface to prompt the user that the configuration is missing if no [MD5_CHECK] data block is detected after parsing. The parsing module 312 is used to extract a list of filenames if a [MD5_CHECK] data block is detected.

[0061] Furthermore, such as Figure 4 As shown, the generation unit 34 includes: The generation module 341 is used to persistently store the obtained burning configuration file and send a process completion notification to the user after storage is completed. The process completion notification is used to inform the user that the target burning configuration file has been generated.

[0062] Furthermore, embodiments of this application also provide a computing device, the computing device comprising: at least one processor, and a memory, wherein the memory stores instructions executable by the processor, the instructions being executed by the processor, thereby enabling the processor to perform the above-described operations. Figure 1-2 The method for generating the hash value of the burning configuration file described in [the document].

[0063] Furthermore, embodiments of this application also provide a readable storage medium for storing a computer program, wherein the computer program, when running, controls the device where the storage medium is located to perform the above-described actions. Figure 1-2 The method for generating the hash value of the burning configuration file described in [the document].

[0064] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0065] It is understood that the relevant features in the above methods and apparatus can be referenced interchangeably. Furthermore, the terms "first," "second," etc., in the above embodiments are used to distinguish between embodiments and do not represent the superiority or inferiority of any particular embodiment.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0067] The algorithms and displays provided herein are not inherently related to any particular computer, virtual system, or other device. Various general-purpose systems can also be used in conjunction with the teachings herein. The required structure for constructing such systems is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the invention.

[0068] In addition, the memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0069] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0070] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0071] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0072] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0073] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0074] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0075] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0076] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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 that element.

[0077] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The above descriptions are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for generating a hash value of a burn configuration file, characterized by, The application relates to a method for generating a burning configuration file of a vehicle-mounted burning program. When the size of a target file to be written is greater than a preset value, an initial configuration file of a vehicle-mounted burning program is acquired, and a file name list in an [MD5_CHECK] data block is acquired by parsing the initial configuration file; Based on a target folder to be written, the file names in the file name list are matched with the file names in the target folder and subfolders of the target folder, and files with matched file names are determined as target files; MD5 hash values of the target files are calculated by adopting a block stream processing mode, the block stream processing mode is that the content of the target files is read in fixed byte blocks, and when a second data block is read, the MD5 hash value of a first data block is calculated, the first data block and the second data block are adjacent read data blocks; The first data block, the second data block, the MD5 hash value of the first data block and the MD5 hash value of the second data block are written into the [MD5_CHECK] data block of the target file, and a burning configuration file is obtained.

2. The method of claim 1, wherein, The initial configuration file required by the vehicle-mounted burning program is acquired, and the initial configuration file is selected through a computer operation display interface built by adopting a Tkinter framework. The computer operation display interface is provided with a double-path selector, the double-path selector is used for selecting the initial configuration file and the target folder respectively, and the initial configuration file path and the target folder path are cached to a storage module after selection.

3. The method of claim 1, wherein, Based on the target folder to be written, the file names in the file name list are matched with the file names in the target folder and subfolders of the target folder, and files with matched file names are determined as target files, and the method comprises the following steps: Based on os.walk () and a fuzzy matching mode of file names, multi-level directories of the target folder are traversed to determine the target files, the fuzzy matching mode is that file names are not distinguished in terms of case, the file names are extracted from the file name list, and the same name files are searched in the target folder and subfolders thereof recursively, and after a first matched file is found, the first matched file is determined as the target file.

4. The method of claim 2, wherein, Before the MD5 hash values of the target files are calculated by adopting the block stream processing mode, the following steps are included: The readability of the target files is judged; If the target files are readable, the MD5 hash value calculation step is executed; If the target files are unreadable, an error pop-up window is displayed on the computer operation display interface to prompt a user.

5. The method of claim 1, wherein, The MD5 hash values of the target files are calculated by adopting the block stream processing mode, and the method comprises the following steps: The target files are opened in a binary reading mode, and the fixed-size data blocks are read in a loop; After each data block is read, the current hash state of the data block is updated immediately, and the processed data block content is discarded to release the memory; After the target files are read, the final MD digest value is generated.

6. The method of claim 1, wherein, The initial configuration file is parsed to acquire the file name list in the [MD5_CHECK] data block, and the method comprises the following steps: The initial configuration file is parsed by adopting a ConfigParser. If the [MD5_CHECK] data block is not detected after analysis, a warning pop-up is displayed on the computer operation display interface to prompt the user that the configuration is missing; If the [MD5_CHECK] data block is detected, the file name list is extracted.

7. The method of claim 1, wherein, After obtaining the burning configuration file, the following steps are included: The burning configuration file is stored persistently, and after the storage is completed, a process completion notification is sent to the user, which informs the user that the target burning configuration file has been generated.

8. A device for generating hash values ​​for burning configuration files, characterized in that, The steps include: The selection unit is configured to obtain the initial configuration file of the vehicle-mounted burning program when the size of the target file to be written is greater than a preset value, and parse the initial configuration file to obtain the file name list in the [MD5_CHECK] data block; The screening unit is configured to match the file names in the file name list with the file names in the target folder and its sub-folders based on the target folder to be written, and determine the files with matching file names as target files; The computing unit is configured to calculate the MD5 hash value of the target file in the screening unit using a block-based streaming processing method, which reads the content of the target file in fixed byte units, and calculates the MD5 hash value of the first data block when the second data block is read, wherein the first data block and the second data block are adjacent data blocks read. The generation unit is configured to write the first data block, the second data block, the MD5 hash value of the first data block, and the MD5 hash value of the second data block into the [MD5_CHECK] data block of the target file to obtain the burning configuration file.

9. A storage medium, characterized by The storage medium includes a stored program, wherein the program controls the device where the storage medium is located to execute the method for generating the hash value of the burning configuration file according to any one of claims 1-7 when the program is running.

10. An electronic device, comprising: The device includes at least one processor and at least one memory connected to the processor, and the processor and the memory communicate with each other through the bus; the processor is configured to call the program instructions in the memory to execute the method for generating the hash value of the burning configuration file according to any one of claims 1-7.

Images