Byte alignment methods, apparatus and devices

Abstract

This application provides a byte alignment method, apparatus, and device. The method includes: running a preset startup file, the startup file including a file path; determining a file to be processed based on the file path; obtaining multiple data blocks corresponding to the file to be processed, each data block including multiple data lines; and padding each data line in each data block according to a preset byte length to obtain an aligned file. Using the above steps can improve the processing efficiency when performing byte alignment on files.

Description

Technical Field

[0001] This application relates to the field of byte alignment technology, and in particular to a byte alignment method, apparatus and device. Background Technology

[0002] In the embedded software engineering integrated compilation environment, binary files are generated. These binary files need to be programmed into the microcontroller unit (MCU). However, during the programming process, when the binary file is an s19 file, the generated s19 file is 4-byte aligned. But when programming into the MCU through the system bootloader, it needs to be 32-byte aligned. Therefore, the s19 file needs to be changed to 32-byte aligned before it can be successfully programmed into the MCU.

[0003] Currently, 32-byte alignment of S19 files can be performed using Hexview, but manual processing is inefficient and costly. Summary of the Invention

[0004] This application provides a byte alignment method, apparatus, and device that can improve the efficiency of byte alignment processing for files.

[0005] In a first aspect, embodiments of this application provide a byte alignment method, including:

[0006] Run the preset startup file, which includes a file path;

[0007] Based on the file path, determine the file to be processed;

[0008] Obtain multiple data blocks corresponding to the file to be processed, each data block including multiple data rows;

[0009] Each data line in each data block is padded with a preset byte length to obtain an aligned file.

[0010] Secondly, this application provides a byte alignment device, comprising:

[0011] A startup module is used to run a preset startup file, the startup file including a file path;

[0012] The determination module is used to determine the file to be processed based on the file path;

[0013] The acquisition module is used to acquire multiple data blocks corresponding to the file to be processed, and each data block includes multiple data rows;

[0014] The alignment module is used to fill each data line in each data block according to a preset byte length to obtain an aligned file.

[0015] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0016] When the processor executes computer program instructions, it implements the byte alignment method as described in any of the embodiments of the first aspect.

[0017] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the byte alignment method as described in any of the embodiments of the first aspect.

[0018] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a byte alignment method as described in any of the embodiments of the first aspect above.

[0019] The byte alignment method, apparatus, device, and medium in this application embodiment include: running a preset startup file, the startup file including a file path; determining a file to be processed based on the file path; acquiring multiple data blocks corresponding to the file to be processed, each data block including multiple data lines; and filling each data line in each data block according to a preset byte length to obtain an aligned file. By running a startup file containing a file path to determine the file to be processed corresponding to the file path, automatic identification of the file to be processed is achieved. By acquiring multiple data blocks corresponding to the file to be processed and filling each data line in each data block according to a preset byte length to obtain an aligned file, automatic byte alignment of the file to be processed is achieved. In this application, by automatically completing the automatic alignment of the file to be processed, manual operation during the file processing process can be avoided, reducing the error rate during processing, reducing labor costs, and thus improving the efficiency of writing the file to be processed to the MCU. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating a byte alignment method provided in one embodiment of this application;

[0022] Figure 2 This is a schematic diagram of the data block format provided in an embodiment of this application;

[0023] Figure 3This is a schematic diagram of the structure of a byte alignment device provided in an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0025] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0026] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0027] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0028] In related technologies, binary files are generated in the embedded software engineering integrated compilation environment. These binary files need to be programmed into the MCU (Microcontroller Unit). However, the programming process presents the following problems: First, when the binary file is an s19 file, the generated s19 file is 4-byte aligned, but when programming to the MCU via the bootloader, 32-byte alignment is required. Therefore, the s19 file needs to be changed to 32-byte alignment before it can be successfully programmed into the MCU. Second, when the MCU is a bare board, multiple s19 files need to be programmed into the bare board before programming to the MCU via the bootloader, and these files can only be programmed one by one.

[0029] Currently, 32-byte alignment of s19 files can be manually performed using hexview. Specifically, hexview provides a Fill data Record function, which allows users to modify the address range and padding content of binary files. In addition, hexview also provides a merge function, which can merge two files. However, hexview can only perform manual modification and file merging, which leads to low manual processing efficiency and high labor costs. Furthermore, hexview is Windows software and cannot be used in Linux environments.

[0030] To address the problems of the prior art, embodiments of this application provide a byte alignment method, apparatus, and device. The byte alignment method provided in this application embodiment is described below.

[0031] Figure 1 A flowchart illustrating a byte alignment method provided in one embodiment of this application is shown. Figure 1 As shown, the method may specifically include the following steps:

[0032] Step 101: Run the preset startup file, which includes a file path;

[0033] In one embodiment of this application, the startup file may include a first startup sub-file, a second startup sub-file, and a third startup sub-file; the first startup sub-file includes the file path of the file to be processed. The second startup sub-file includes an algorithm for byte alignment of data in the file to be processed. The third startup sub-file is used to provide a runtime environment for the algorithm in the second startup sub-file.

[0034] Specifically, the startup files include test.bat, test.jar, and jre. The first startup sub-file is test.bat or test.sh, which includes the file path to the file to be processed. The file path refers to the storage address where the file to be processed is located. The second startup sub-file is test.jar, which includes an algorithm for byte alignment of the data in the file to be processed. The third startup sub-file is jre, which provides the runtime environment for the algorithm in the second startup sub-file.

[0035] Step 102: Determine the file to be processed based on the file path;

[0036] When starting the first startup subfile, the file to be processed can be directly determined based on the file path specified in the first startup subfile. When performing byte alignment within a file, only one file path is allowed. If only one file path is used, the first startup subfile is started, and simultaneously, the alignment algorithm in the second startup subfile is initiated through the first startup subfile to perform byte alignment on the file to be processed. When performing file merging operations, two or more file paths are allowed. If two or more file paths are used, the first startup subfile is started, and simultaneously, the file merging algorithm in the second startup subfile is initiated through the first startup subfile to merge multiple files to be processed.

[0037] It should be noted that when aligning the bytes of files to be processed, the file path in the first startup subfile can be set to the file path of the files to be processed. This allows direct access to the file corresponding to that file path. Specifically, when merging files to be processed, since multiple files need to be called simultaneously to generate a new file, multiple file paths need to be set in the first startup subfile. When setting these paths, first, the file paths of the files to be processed need to be set in the first startup subfile, and finally, a file path needs to be set to save the merged new file, ensuring that the new file is saved in the last set file path.

[0038] Step 103: Obtain multiple data blocks corresponding to the file to be processed, each data block including multiple data rows;

[0039] In step 103, a file alignment operation is performed, so there is only one file to be processed. Figure 2 The diagram shows a schematic of a data block format. A data block is the smallest unit of storage and processing in a database. The file to be processed is composed of multiple data blocks, specifically an S19 file. An S19 file refers to a program file with the .S19 extension generated in an embedded software engineering integrated compilation environment.

[0040] like Figure 2 As shown, each data block in the file to be processed consists of multiple data rows. Each row is arranged according to the length of its corresponding data field, the starting address of the data field, the data type of the data field, the data field itself, and the checksum. The length of each data field occupies one byte within the data row. Figure 2The first two digits of each data line are numbers, for example, "0E" in the second data line. The starting address of the data field occupies two bytes in the data line, for example, "0000" in the second data line. The data type of the data field occupies one byte in the data line, for example, "00" in the second data line. The checksum occupies one byte in the data line, for example, "BA" in the second data line. The byte position between the checksum and the data type is the data field, for example, "40AE912003F8D9FF92B9DCOFO090" in the second data line. Furthermore, the first data line in each data block is the starting data line, and the data field of the starting data line represents the starting address of that data block, for example... Figure 2 8030 in the address is the starting address of the data block.

[0041] Step 104: Fill each data line in each data block according to the preset byte length to obtain an aligned file.

[0042] When performing byte alignment, it is necessary to ensure that the number of bytes in the data field corresponding to each data row is a preset byte length. In this embodiment, 32-byte alignment is preferred, therefore, when padding, it is necessary to ensure that the number of bytes in the data field is 32 bytes. In addition to 32-byte alignment, this application can also be applied to 16-byte alignment.

[0043] In this application, the byte alignment method includes: running a preset startup file, the startup file including a file path; determining the file to be processed based on the file path; obtaining multiple data blocks corresponding to the file to be processed, each data block including multiple data lines; and filling each data line in each data block according to a preset byte length to obtain an aligned file. By running a startup file containing a file path to determine the file to be processed corresponding to the file path, automatic identification of the file to be processed is achieved. By obtaining multiple data blocks corresponding to the file to be processed and filling each data line in each data block according to a preset byte length to obtain an aligned file, automatic byte alignment of the file to be processed is achieved. In this application, by automatically completing the automatic alignment of the file to be processed, manual operation in the file processing process can be avoided, the error rate in the processing process can be reduced, the labor cost can be reduced, and thus the writing efficiency of the file to be processed to the MCU can be improved.

[0044] In one embodiment of this application, before the step of running the preset startup file, the following steps are included:

[0045] Determine the operating system on which the startup file is running;

[0046] The step of running the preset startup file includes:

[0047] According to the operating system, the corresponding command is used to start the startup file.

[0048] The operating systems mentioned include Windows and Linux. The first boot file in the bootloader specifically includes test.bat and test.sh. test.bat is the first boot file for Windows, and test.sh is the first boot file for Linux. Therefore, the operating system needs to be determined to correctly select the boot file.

[0049] Depending on the operating system, the startup file is launched using the corresponding command line. Specifically, the command line is a prompt in the operating system that prompts for command input. For Windows systems, the test.bat file is launched. For Linux systems, the test.sh file is launched.

[0050] In this embodiment, by setting different file paths in the preset startup file, the files to be processed can be flexibly changed. It can be used in both Windows and Linux environments, effectively improving the current limitation that byte alignment using hexview can only be performed in the Windows operating environment, thus expanding the application scenarios.

[0051] In one embodiment of this application, obtaining multiple data blocks corresponding to the file to be processed includes:

[0052] Determine the storage area where the file to be processed is located;

[0053] Obtain a preset marker in the storage area, and determine the storage area between adjacent preset markers as a data block;

[0054] Each data line in each data block is padded according to a preset byte length to obtain an aligned file, including:

[0055] For each first data line in multiple data lines of each data block, if the byte length of the data field of the first data line is less than the preset byte length, the data field is filled according to the preset byte length to obtain an aligned file. The first data line does not include the preset marker data line, and the byte length of the data field is the sum of the starting position of the data line including the preset marker and the length of the data field in the first data line.

[0056] In this embodiment, the storage area where the file to be processed is located is determined, and the storage area is the data block.

[0057] A preset marker is obtained from the storage area, and the storage area between adjacent preset markers is determined as a data block. There are six data types in the s19 file: 00 for data records, 01 for end-of-file records, 02 for extended segment address records, 03 for start-of-segment address records, 04 for extended linear address records, and 05 for start-of-linear address records. The data type represented by 04 can be used as a distinguishing identifier for each data block; a storage area containing two 04 data types constitutes a data block. For example, as... Figure 2 As shown, each data row contains two data types: 04 and 00. The data row containing 04 is the starting data row of each data block. Figure 2 All the data rows shown are data blocks.

[0058] When calculating whether the byte length of the data field in each first data row is less than the preset byte length, it is necessary to use the start bit of each data row and the preset byte length for calculation. The start bit of each first data row is a combination of the start address of the data block and the start address of each data row. For example, in... Figure 2 In the case where the first data line is 0E00000040AE912003F8D9FF92B9DC0F0090BA, the starting address of the data block is 8030, so the starting bit is 80300000; in the case where the first data line is 100100001D0226c60000000000000000000000000C8, the starting bit is 80300100; and in the case where the first data line is 1001100000000000000000000000000000000000000DF, the starting bit is 80300110.

[0059] To determine whether the byte length of the data field in each first data row is less than the preset byte length, firstly, the starting position of each first data row and the byte length can be added together in hexadecimal, then converted from hexadecimal to decimal, and finally, it is determined whether the decimal value is divisible by the preset byte length. If it is divisible, it means that the byte length of the data field in the first data row is equal to the preset byte length, and no padding is required; if it is not divisible, it means that the byte length of the data field in the first data row is less than the preset byte length, and padding is required. For example, in the case of the first data line: 0E00000040AE912003F8D9FF92B9DC0F0090BA, the starting bit is 80300000, and the byte length is 000E in hexadecimal. Then, adding the starting bit and the byte length and converting it to decimal gives 2150629390. If the preset byte length is 32 bytes, it cannot be divided by 32. However, it should be noted that since the length of the data field in 0E00000040AE912003F8D9FF92B9DC0F0090BA is 0E, and 0E represents a data field, no padding is required in this case. In the case of the first data line: 100100001D0226c60000000000000000000000000C8, the starting bit is 80300100, and the byte length is 0010 in hexadecimal. Then, after adding the starting bit and the byte length and converting it to decimal, it becomes 2150629648. When the default byte length is 32 bytes, it is not divisible by 32, which means that: 100110000000000000000000000000000000000DF needs to be padded. In the case of the first data line: 10011000000000000000000000000000000000000DF, the start bit is 80300110, and the byte length is 0010 in hexadecimal. Then, after adding the start bit and the byte length and converting it to decimal, it is 2150629664. When the default byte length is 32 bytes, it is divisible by 32, so no padding is required.

[0060] In this embodiment, by determining the data blocks in each file to be processed and sequentially filling the data fields of the first data row in each data block with data whose byte length is less than the preset byte length, byte filling of each data row is achieved, providing an alignment basis for byte alignment.

[0061] In one embodiment of this application, the step of padding each data line in each data block according to a preset byte length to obtain an aligned file includes:

[0062] Each data row in each data block is padded according to a preset byte length to obtain multiple aligned data rows;

[0063] Extract data fields sequentially from each aligned data row of each data block to obtain multiple data fields;

[0064] The data fields in each of the data blocks are rearranged to obtain an aligned file.

[0065] In this embodiment, the examples from the above embodiments are used. Since padding is only required in the case of the first data line: 100100001D0226c60000000000000000000000000C8, this case is used as an example for illustration.

[0066] When performing 32-byte padding, first determine if the first data row to be padded can be padded with 16 bytes. The method for determining this is the same as the method for determining 32-byte padding, except that the variable is whether it is divisible by 16. If the first data row can be padded with 16 bytes, then determine if the sum of the first data row to be padded and the next first data row is divisible by 32. If it is divisible by 32, then combine the next first data row with the first data row to be padded; if it is not divisible by 32, then add "0"s to the end of the data field to complete byte alignment.

[0067] As an example, if a value is not divisible by 32, zeros need to be added to the end of the data field during padding. The number of zeros added is the remainder of the quotient between the starting bit and the preset byte length. For example, if the starting bit is 80300110, which is 2150629648 in decimal, after dividing by 32, the remainder is 12, so 12 zeros are added to the data field. After padding, all data rows in the data block will be aligned.

[0068] As an example, when determining whether the combined first data row is divisible by 32, the starting address of the first data row to be padded can be added to its byte length, and then added to the byte length of the next first data row. Then, it can be determined whether it is divisible by 32. For example, if the first data row is 100100001D0226c60000000000000000000000000C8, the starting address is 80300100, the byte length is 0010, and the byte length of the next data row is 0010. The sum of these three values, expressed in hexadecimal, is 80300120, which is 2150629664 in decimal, meaning it is divisible by 32.

[0069] After populating the data rows, extract the data fields from each data row. Referring to the example above, in Figure 2 In the code, the data fields in “:100100001D0226c6000000000000000000000000C8” and “:100110000000000000000000000000000000000DF” can be extracted, which is “1D0226c60000000000000000000000000+0 ...

[0070] The extracted data fields are rearranged to obtain an aligned file. During rearrangement, the extracted data fields are rearranged with each data row allocated 32 bytes. After rearrangement, the length, starting address, and data type of each data field in each row are recorded again to obtain the aligned file. It should be noted that the data fields in the file to be processed are represented in hexadecimal, so every two characters constitute one byte. For example, in 40AE912003F8D9FF92B9DC0F0090, the bytes are 40, AE, 91, 20, 03, F8, D9, FF, 92, B9, DC, 0F, 00, and 90, respectively.

[0071] Specifically, in one embodiment of this application, rearranging the data fields in each data block to obtain an aligned file includes:

[0072] For each of the multiple data fields in the data block, bytes of the preset byte length are allocated in each data row of the data block to store one data field;

[0073] Record the length of the data field stored in each data row of the data block, the starting address of the data field, the data type of the data field, and the checksum to obtain the alignment file.

[0074] When performing 32-byte alignment, after extracting multiple data fields from the data block, 32 bytes of length are allocated to each data row in the data block. For example, if the set in the above embodiment is allocated, the data field of the rearranged data row will be "1D0226c60 ...

[0075] When recording the length of the data field stored in each data row, the length of each rearranged data row is 32 bytes, which is 20 in hexadecimal, because it has been refilled according to the preset byte length.

[0076] The starting address of the data field is the same as the starting address of the data row before rearrangement. For example, referring to the example above, the starting address before rearrangement is 80300100. Taking the last four bits as 0100, the starting address of the rearranged data row is 0100.

[0077] When determining the data type of a data field, it can be based on the data type of each data row before rearrangement. That is, the data type of the rearranged data row is the same as the data type before rearrangement. For example, if the data type of the data row before rearrangement is 00, then the data type of the rearranged data row will also be 00.

[0078] In summary, the rearranged data row excluding the checksum is: 200100001D0226c6000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

[0079] When determining the checksum, it is necessary to calculate based on all bytes except the checksum in each rearranged data row. This involves converting the hexadecimal string (excluding the checksum) in each row to a byte array, inverting the sum of the numbers within the byte array, converting it back to hexadecimal, and finally taking the last two digits of the hexadecimal representation as the checksum. For example, the checksum calculation process is as follows: 0x20 is 32 in decimal, 0x01 is 1 in decimal, and the decimal representations of 0x00...0x1D, 0x02, 0x26, and 0xc6 are calculated sequentially. The sum of these decimal representations is 300. Inverting 300 gives -300, which is then converted back to hexadecimal and the last two digits are taken as the checksum. The rearranged data row is 200100001D0226c600000000000000000000000000000000000000000000000000000000000000000000000D4.

[0080] In this embodiment, by running the alignment algorithm in the second startup subfile, the files to be processed are automatically aligned, avoiding manual modification and improving processing efficiency.

[0081] In one implementation, rearranging the data fields in each data block to obtain an aligned file further includes:

[0082] Retrieve each data block after rearrangement;

[0083] If there is an overlap in address range between the data blocks, the two overlapping data blocks will be merged.

[0084] In this embodiment, when determining the address range overlap of data blocks, the start address and end address of each data block can be obtained first. Then, the start address and end address can be compared to see if there is any overlap between any two data blocks. If there is an overlap, the two data blocks are merged into one data block. After all data blocks have been aligned, all data blocks are stored in the final alignment file.

[0085] By merging rearranged data blocks, file processing efficiency can be improved.

[0086] This application also provides a file merging process, which is implemented using a file merging algorithm. This algorithm is used to merge at least two files, followed by byte alignment, or byte alignment followed by merging; the specific steps are not limited here. The merging algorithm can be included in a second startup subfile, so that after the startup file runs, the merging algorithm in the second startup subfile can be automatically executed to perform the file merging process. Specifically, in one embodiment of this application, the files to be processed include a first file and a second file.

[0087] After determining the file to be processed based on the file path, the method further includes:

[0088] Obtain at least one first data block corresponding to the first file and at least one second data block corresponding to the second file;

[0089] If the first data block and the second data block have overlapping addresses, the first data block and the second data block are merged.

[0090] When the number of files to be processed includes two or more, the merging algorithm in the second startup sub-file is started. When merging the files to be processed, since multiple files to be processed need to be called simultaneously to generate a new file, multiple file paths need to be set in the first startup sub-file. When setting them, the file paths of the files to be processed to be called need to be set in the first startup sub-file first, and finally a file path is set to save the merged new file, so that the new file can be saved in the last set file path.

[0091] Since there are multiple files to be processed, and each file contains multiple data blocks, it is necessary to determine whether data blocks in different files are duplicated during file merging. Furthermore, if the address ranges of two data blocks overlap, the two data blocks are merged.

[0092] In one embodiment of this application, the step of merging the first data block and the second data block when their addresses overlap includes:

[0093] Obtain the first start address and the first end address of each of the first data blocks, and the second start address and the second end address of each of the second data blocks;

[0094] If the first data block and the second data block have overlapping addresses, the data rows in the first data block and the second data block will be merged.

[0095] The starting address of each data block can be obtained directly from the records in the data row, for example, Figure 2 The starting address of the data block is 8030. The ending address is the sum of the starting address of the last data line and the length of the last data line. For example, if the starting address of the last data line is 0x0110 and the length is 0x10, then the ending address of the data block is 0x120. Therefore, the address range of this data block is 0x0110-0x120; where 0x is in hexadecimal representation.

[0096] Address overlap includes two scenarios: one where the address ranges of two data blocks completely overlap, and the other where their address ranges partially overlap. In the case of complete overlap, either duplicate data block can be discarded. In the case of partial overlap, data blocks can be merged based on the address ranges of their data rows. For example, if the address range of the third data row in the first data block overlaps with the address range of the second data row in the second data block, then the first, second, and third rows of the first data block and the third, fourth, and fifth rows of the second data block can be merged to form a new data block.

[0097] It should be noted that if two data rows with overlapping address ranges, it means that the data portion of the data rows is the same. Therefore, discarding one of the data rows during merging will not result in data loss.

[0098] The byte alignment method provided in this application has the following beneficial effects:

[0099] (1) All modifications to data blocks in the file to be processed that do not have 32-byte alignment can be completed via the command line.

[0100] Compared to hexadecimal editors, this application can automatically align the bytes of the file to be processed by calling an alignment algorithm through the startup file.

[0101] (2) Multiple files to be processed can be merged via the command line.

[0102] Compared to hexadecimal editors, this application can automatically call the merging algorithm through the startup file to automatically merge the files to be processed. It can also support merging two or more files to be processed at the same time, which greatly improves the merging efficiency.

[0103] (3) Supports use in Linux operating system.

[0104] Compared to hexadecimal editors, the byte alignment method provided in this application can be used in both Windows and Linux operating systems, thus expanding the scope of application of this application.

[0105] Figure 3 A schematic diagram of a byte alignment device provided in one embodiment of this application is shown. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0106] Reference Figure 3 The byte alignment device 300 may include:

[0107] The startup module 301 is used to run a preset startup file, the startup file including a file path;

[0108] The determining module 302 is used to determine the file to be processed based on the file path;

[0109] The acquisition module 303 is used to acquire multiple data blocks corresponding to the file to be processed, and each data block includes multiple data rows;

[0110] Alignment module 304 is used to fill each data line in each data block according to a preset byte length to obtain an aligned file.

[0111] Optionally, the acquisition module 303 includes:

[0112] The first acquisition module is used to determine the storage area where the file to be processed is located;

[0113] The second acquisition module is used to acquire a preset marker in the storage area and determine the storage area between adjacent preset markers as a data block;

[0114] Accordingly, the alignment module 304 is specifically used for:

[0115] For each first data line in multiple data lines of each data block, if the byte length of the data field of the first data line is less than the preset byte length, the data field is filled according to the preset byte length to obtain an aligned file. The first data line does not include the preset marker data line, and the byte length of the data field is the sum of the starting position of the data line including the preset marker and the length of the data field in the first data line.

[0116] Optionally, the alignment module 304 includes:

[0117] The padding submodule is used to pad each data row in each data block according to a preset byte length to obtain multiple aligned data rows;

[0118] The extraction submodule is used to extract data fields sequentially from each aligned data row of each data block to obtain multiple data fields;

[0119] The rearrangement submodule is used to rearrange the data fields in each data block to obtain an aligned file.

[0120] Optionally, the rearrangement submodule includes:

[0121] An allocation unit is used to allocate bytes of a preset byte length in each data row of each data block to store one data field for multiple data fields in each data block;

[0122] A recording unit is used to record the length of the data field stored in each data row of the data block, the starting address of the data field, the data type of the data field, and the checksum, so as to obtain the alignment file.

[0123] Optionally, the byte alignment device further includes:

[0124] The third acquisition module is used to acquire at least one first data block corresponding to the first file and at least one second data block corresponding to the second file;

[0125] The merging module is used to merge the first data block and the second data block when there is address overlap.

[0126] Optionally, the merging module includes:

[0127] The acquisition submodule is used to acquire the first start address and the first end address of each of the first data blocks, and the second start address and the second end address of each of the second data blocks;

[0128] The merging submodule is used to merge the data rows in the first data block and the second data block if there is address overlap.

[0129] Optionally, the byte alignment device further includes:

[0130] The second determining module is used to determine the operating system that the startup file runs on;

[0131] The startup module 301 is specifically used for:

[0132] The startup file is launched using the corresponding command line according to the operating system.

[0133] The byte alignment device 300 provided in this application embodiment can implement the various processes implemented in the foregoing method embodiments, and will not be described again here to avoid repetition.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0135] Figure 4 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0136] The device may include a processor 401 and a memory 402 storing program instructions.

[0137] When processor 401 executes the program, it implements the steps in any of the above method embodiments.

[0138] For example, the program can be divided into one or more modules / units, one or more of which are stored in memory 402 and executed by processor 401 to complete this application. The one or more modules / units can be a series of program instruction segments capable of performing a specific function, which describe the execution process of the program in the device.

[0139] Specifically, the processor 401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0140] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 402 may include removable or non-removable (or fixed) media. Where appropriate, memory 402 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 402 is non-volatile solid-state memory.

[0141] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0142] The processor 401 implements any of the methods described above by reading and executing program instructions stored in the memory 402.

[0143] In one example, the electronic device may also include a communication interface 403 and a bus 410. The processor 401, memory 402, and communication interface 403 are connected via the bus 410 and communicate with each other.

[0144] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0145] Bus 410 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 410 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0146] Furthermore, in conjunction with the methods in the above embodiments, this application embodiment can provide a storage medium for implementation. This storage medium stores program instructions; when these program instructions are executed by a processor, they implement any of the methods in the above embodiments.

[0147] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0148] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0149] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on machine-readable media or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable media" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0150] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0151] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and program products according to embodiments of this disclosure. It should be understood that each block in 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 program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable byte-aligned means to produce a machine such that these instructions, executable via the processor of the computer or other programmable byte-aligned means, enable the implementation of the function / action specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified function or action, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0152] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A byte alignment method, characterized in that, include: Run a preset startup file, which includes a file path, an algorithm for byte alignment of data in the file to be processed, and the startup file is also used to provide a running environment for the algorithm; Based on the file path, the file to be processed is determined, and the file to be processed includes the S19 file; Obtain multiple data blocks corresponding to the file to be processed, each data block including multiple data rows; Each data line in each data block is padded with a preset byte length to obtain an aligned file; The step of filling each data line in each data block according to a preset byte length to obtain an aligned file includes: The starting position of the first data line in each data block is added to the byte length in hexadecimal to obtain the first data line after addition; The first data row after addition is converted to decimal, and it is determined whether the value after conversion to decimal is divisible by a preset byte length; If it cannot be divided evenly, it means that the byte length of the data field of the first data row is less than the preset byte length. 0 is padded to the end of the data field of the first data row to complete the byte alignment and obtain multiple aligned data rows. Data fields are extracted sequentially from each aligned data row of each data block to obtain multiple data fields, wherein the byte length of each data field is the sum of the start position of the data row with a preset marker and the length of the data field in the first data row; For each of the multiple data fields in the data block, bytes of the preset byte length are allocated in each data row of the data block to store one data field; Record the length of the data field stored in each data row of the data block, the starting address of the data field, the data type of the data field, and the checksum to obtain the alignment file.

2. The byte alignment method as described in claim 1, characterized in that, The step of obtaining multiple data blocks corresponding to the file to be processed includes: Determine the storage area where the file to be processed is located; Obtain a preset marker in the storage area, and determine the storage area between adjacent preset markers as a data block; The process of filling each data row in each data block with a preset byte length to obtain an aligned file includes: for each first data row in multiple data rows of each data block, if the byte length of the data field of the first data row is less than the preset byte length, filling the data field with the preset byte length to obtain an aligned file, wherein the first data row does not include the data row marked by the preset marker.

3. The byte alignment method as described in claim 1, characterized in that, The files to be processed include a first file and a second file. After determining the file to be processed based on the file path, the method further includes: Obtain at least one first data block corresponding to the first file and at least one second data block corresponding to the second file; If the first data block and the second data block have overlapping addresses, the first data block and the second data block are merged.

4. The byte alignment method as described in claim 3, characterized in that, The step of merging the first data block and the second data block when their addresses overlap includes: Obtain the first start address and the first end address of each of the first data blocks, and the second start address and the second end address of each of the second data blocks; If the first data block and the second data block have overlapping addresses, the data rows in the first data block and the second data block will be merged.

5. The byte alignment method as described in claim 1, characterized in that, Before the step of running the preset startup file, the method further includes: Determine the operating system on which the startup file is running; The step of running the preset startup file includes: The startup file is launched using the corresponding command line according to the operating system.

6. The byte alignment method as described in claim 1, characterized in that, The startup file includes a first startup sub-file, a second startup sub-file, and a third startup sub-file; The first startup sub-file includes the file path, the second startup sub-file includes an algorithm for byte alignment of data in the file to be processed, and the third startup sub-file is used to provide a running environment for the algorithm in the second startup sub-file.

7. A byte alignment device, characterized in that, include: A startup module is used to run a preset startup file, which includes a file path, an algorithm for byte alignment of data in the file to be processed, and the startup file is also used to provide a running environment for the algorithm. The determination module is used to determine the file to be processed based on the file path, wherein the file to be processed includes the S19 file; The acquisition module is used to acquire multiple data blocks corresponding to the file to be processed, and each data block includes multiple data rows; The alignment module is used to fill each data line in each data block according to a preset byte length to obtain an aligned file. It is also used to add the starting position of the first data line in each data block to the byte length in hexadecimal to obtain the first data line after addition; convert the first data line after addition to decimal and determine whether the value after conversion to decimal is divisible by the preset byte length; if it is not divisible, it means that the byte length of the data field of the first data line is less than the preset byte length, and 0 is filled to the end of the data field of the first data line to complete the byte alignment, thereby obtaining multiple aligned data lines. Data fields are sequentially extracted from each aligned data row of each data block to obtain multiple data fields, wherein the byte length of each data field is the sum of the start position of the data row including the preset marker and the length of the data field in the first data row; for multiple data fields in each data block, bytes of the preset byte length are allocated in each data row of the data block to store one data field; the length of the data field stored in each data row of the data block, the start address of the data field, the data type of the data field, and the checksum are recorded to obtain the alignment file.

8. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the byte alignment method as described in any one of claims 1-6.

Images