Data format conversion method and device, electronic equipment and storage medium

Abstract

The invention discloses a data format conversion method, and belongs to the technical field of data format conversion. According to the embodiment of the invention, the initial format of the initial data can be converted into the target format according to the format configuration information to obtain the target data; through versioned format configuration information, each conversion process of data can be associated to a specific configuration version, and full-link traceability is realized. Calling a simulator corresponding to the initial format to carry out format detection on the target data, and calling a simulator corresponding to the target format to carry out format detection on the initial data to obtain a bidirectional detection result; through real simulation of an interaction scene between a new system and an old system, potential compatibility problems can be effectively identified, and online accidents caused by anomalies are prevented. Generating a format conversion report according to the bidirectional detection result; the format conversion report is used for representing whether the initial format is compatible with the target format or not, and it is ensured that the behavior of the converted data on the target platform is predictable.

Description

Technical Field

[0001] This invention belongs to the field of data format conversion technology, and specifically relates to a data format conversion method, apparatus, electronic device and storage medium. Background Technology

[0002] Cross-platform data format conversion refers to the process of semantically preserving, structurally consistent, and efficiently and reliably converting data representations between systems with different operating systems, programming languages, hardware architectures, or communication protocols. Existing technologies primarily rely on static mapping configurations and protocol adaptation middleware to achieve cross-platform data format conversion. Because configuration information is stored in static files, users cannot determine whether the converted configuration is compatible with the old version. Once a configuration error occurs, it is difficult to roll back or locate the root cause of the problem, easily triggering a chain reaction of failures such as system crashes after upgrades, seriously threatening system stability and security. Summary of the Invention

[0003] The purpose of this invention is to provide a data format conversion method, apparatus, electronic device, and storage medium that can solve the problem of data conversion incompatibility.

[0004] In a first aspect, embodiments of the present invention provide a data format conversion method, the method comprising: Obtain initial data and format configuration information; According to the format configuration information, the initial data is converted from the initial format to the target format to obtain the target data; The simulator corresponding to the initial format is invoked to perform format detection on the target data, and the simulator corresponding to the target format is invoked to perform format detection on the initial data, to obtain a bidirectional detection result; A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

[0005] Optionally, the format conversion report includes a format compatibility report and a format incompatibility report; generating the format conversion report based on the bidirectional detection results includes: Based on the bidirectional detection results, determine whether the target data has missing fields, mismatched types, or failed encryption; If the target data field is missing, the type does not match, or encryption fails, generate a format incompatibility report; If the target data fields are complete, the types match, and encryption is successful, a format-compatible report is generated.

[0006] Optionally, the method further includes: If the initial format is incompatible with the target format, a repair suggestion is generated based on the bidirectional detection results; the repair suggestion is used to indicate that the target format should be modified to make the initial format compatible with the target format.

[0007] Optionally, the method further includes: If the initial format is compatible with the target format, the target data is compressed, and the compressed target data is transmitted across platforms.

[0008] Optionally, before converting the initial data from the initial format to the target format according to the format configuration information, the method further includes: The format configuration information is subjected to syntax and semantic validation. The step of converting the initial data from the initial format to the target format according to the format configuration information includes: If the syntax and semantic validation of the format configuration information pass, the initial data is converted from the initial format to the target format according to the format configuration information.

[0009] Optionally, the method further includes: Generate a configuration snapshot and version number corresponding to the format configuration information; the configuration snapshot is used to record the modification information of the initial data, and the version number is used to identify the configuration snapshot corresponding to the format configuration information.

[0010] Optionally, the method further includes: Generate a difference report between the initial data and the target data.

[0011] Secondly, embodiments of the present invention provide a data format conversion apparatus, the apparatus comprising: The initial data acquisition module is used to acquire initial data and format configuration information; The target format conversion module is used to convert the initial data from the initial format to the target format according to the format configuration information to obtain the target data; The detection result determination module is used to call the simulator corresponding to the initial format to perform format detection on the target data, and to call the simulator corresponding to the target format to perform format detection on the initial data, so as to obtain a bidirectional detection result; A conversion report generation module is used to generate a format conversion report based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

[0012] Optionally, the format conversion report includes a format compatibility report and a format incompatibility report; the conversion report generation module includes: The detection result judgment submodule is used to determine whether the target data has missing fields, mismatched types, or failed encryption based on the bidirectional detection results. The incompatible report generation submodule is used to generate an incompatible report in the event that the target data field is missing, the type does not match, or the encryption fails. The compatibility report generation submodule is used to generate a format-compatible report if the target data fields are complete, the type matches, and the encryption is successful.

[0013] Optionally, the device further includes: A repair suggestion generation module is used to generate repair suggestions based on the bidirectional detection results when the initial format is incompatible with the target format; the repair suggestions are used to indicate that the target format should be modified to make the initial format compatible with the target format.

[0014] Optionally, the device further includes: A cross-platform transmission module is used to compress the target data while ensuring that the initial format is compatible with the target format, and then transmit the compressed target data across platforms.

[0015] Optionally, prior to the target format conversion module, the apparatus further includes: The configuration information verification module is used to perform syntax and semantic verification on the format configuration information. The target format conversion module includes: The target format conversion submodule is used to convert the initial data from the initial format to the target format according to the format configuration information, provided that the syntax and semantic verification of the format configuration information are passed.

[0016] Optionally, the device further includes: A configuration snapshot generation module is used to generate a configuration snapshot and a version number corresponding to the format configuration information; the configuration snapshot is used to record the modification information of the initial data, and the version number is used to identify the configuration snapshot corresponding to the format configuration information.

[0017] Optionally, the device further includes: The difference report generation module is used to generate a difference report between the initial data and the target data.

[0018] Thirdly, embodiments of the present invention provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0019] Fourthly, embodiments of the present invention provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0020] The embodiments of the present invention have the following advantages: This invention can convert initial data from an initial format to a target format based on format configuration information to obtain the target data. Through versioned format configuration information, each data conversion process can be associated with a specific configuration version, achieving end-to-end traceability. The system calls the simulator corresponding to the initial format to perform format detection on the target data, and the simulator corresponding to the target format to perform format detection on the initial data, obtaining bidirectional detection results. By realistically simulating the interaction scenario between the old and new systems, potential compatibility issues such as missing fields, type mismatches, and encryption failures can be effectively identified, preventing online incidents caused by anomalies. A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial and target formats are compatible. By introducing a bidirectional simulation detection mechanism, the compatibility between the initial and target formats is verified simultaneously during the format conversion process, ensuring that the converted data behaves predictably on the target platform, improving system stability and security, while significantly reducing manual testing and debugging time and improving R&D efficiency. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the steps of a data format conversion method according to an embodiment of the present invention; Figure 2 This is a flowchart of another data format conversion method according to an embodiment of the present invention; Figure 3 This is a logic diagram of a data format conversion method according to an embodiment of the present invention; Figure 4 This is a structural block diagram of a data format conversion device according to an embodiment of the present invention. Detailed Implementation

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

[0023] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0024] The data format conversion method provided by the embodiments of the present invention will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0025] Reference Figure 1 The diagram illustrates a flowchart of a data format conversion method according to an embodiment of the present invention. The method may specifically include the following steps: Step 101: Obtain initial data and format configuration information; In this embodiment of the invention, the initial data to be converted and the format configuration information used to guide the conversion process can be obtained first. The initial data is a data instance encoded in a known data format, such as JSON, XML, Protobuf binary stream, MessagePack byte sequence, etc., and its content includes one or more fields and their values. The format configuration information is structured configuration data (such as JSON or YAML format), provided by the user through a graphical interface or API, and is used to define: the schema description of the initial format (including field names, types, nesting structure, optionality, etc.); the schema description of the target format; field mapping rules; data conversion strategies (such as type casting, default value filling, enumeration mapping); security strategies (encryption algorithm, key identifier, signature method); compression and transmission options; and the corresponding simulator identifier (used for subsequent compatibility testing).

[0026] Step 102: According to the format configuration information, convert the initial data from the initial format to the target format to obtain the target data; In this embodiment of the invention, after obtaining the initial data and format configuration information, a structured data conversion operation can be performed based on the field mapping rules, type conversion strategies, security strategies and serialization specifications defined in the format configuration information to parse the initial data encoded in the initial format and generate target data that meets the requirements of the target platform.

[0027] Step 103: Call the simulator corresponding to the initial format to perform format detection on the target data, and call the simulator corresponding to the target format to perform format detection on the initial data, to obtain bidirectional detection results; In this embodiment of the invention, to verify the interoperability between the initial format and the target format, a bidirectional simulation parsing test can be performed. Specifically, a simulator corresponding to the initial format is invoked to perform a forward compatibility test, parsing the target data based on the parsing rules of the historical version to test the compatibility of the old system with the new format data; a simulator corresponding to the target format is invoked to perform a reverse compatibility test, parsing the initial data based on the parsing rules of the current version to test the compatibility of the new system with the old format data; the structural integrity, field existence, type consistency, and security verification results in both parsing processes are recorded respectively to form a bidirectional test result.

[0028] The positive compatibility check includes: calling the simulator corresponding to the initial format (i.e., a lightweight parsing engine representing the parsing capabilities of the old version system or old platform), attempting to load and parse the target data generated by the current conversion process. This simulator strictly follows the historical schema definition, type constraints, and parsing logic of the initial format; checking for unrecognizable new fields, incompatible changes to field types, unsupported encryption algorithms or keys, and uncompressible compression formats.

[0029] Reverse compatibility testing includes: calling the simulator corresponding to the target format (i.e., the parsing engine representing the parsing capabilities of the new version system or new platform), attempting to load and parse the original initial data. This simulator is based on the latest schema and fault tolerance mechanism of the target format (such as supporting default value filling and handling missing optional fields); whether it can correctly handle missing fields, whether it has downgrade compatibility with obsolete fields in the old version data, and whether the old data is rejected due to security policy upgrades, etc.

[0030] Step 104: Generate a format conversion report based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

[0031] In this embodiment of the invention, a structured format conversion report can be automatically generated based on the bidirectional detection results. This report objectively and quantitatively characterizes the compatibility status between the initial and target formats. Overall compatibility conclusions include: fully compatible (both bidirectional parsing is successful, with no missing fields or semantic deviations); partially compatible (requires repair), with repairable risks (such as missing optional fields or type conversion issues); and incompatible (destructive changes), with unrecoverable errors (such as deletion of required fields or forced upgrades to encryption algorithms without a rollback mechanism).

[0032] Specific issues can also be categorized by detection direction, such as: issue type (missing field, type mismatch, encryption failure, compression not supported, invalid enumeration value, etc.); occurrence direction (forward (old system reading new data) or reverse (new system reading old data); severity level (high (block), medium (warning), low (information). Actionable engineering suggestions can also be provided for each risk item.

[0033] This invention can convert initial data from an initial format to a target format based on format configuration information to obtain the target data. Through versioned format configuration information, each data conversion process can be associated with a specific configuration version, achieving end-to-end traceability. The system calls the simulator corresponding to the initial format to perform format detection on the target data, and the simulator corresponding to the target format to perform format detection on the initial data, obtaining bidirectional detection results. By realistically simulating the interaction scenario between the old and new systems, potential compatibility issues such as missing fields, type mismatches, and encryption failures can be effectively identified, preventing online incidents caused by anomalies. A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial and target formats are compatible. By introducing a bidirectional simulation detection mechanism, the compatibility between the initial and target formats is verified simultaneously during the format conversion process, ensuring that the converted data behaves predictably on the target platform, improving system stability and security, while significantly reducing manual testing and debugging time and improving R&D efficiency.

[0034] Reference Figure 2 The diagram illustrates a flowchart of another data format conversion method according to an embodiment of the present invention. The method may specifically include the following steps: Step 201: Obtain initial data and format configuration information; In this embodiment of the invention, the initial data to be converted and the format configuration information used to guide the conversion process can be obtained first. The initial data is a data instance encoded in a known data format, such as JSON, XML, Protobuf binary stream, MessagePack byte sequence, etc., and its content includes one or more fields and their values. The format configuration information is structured configuration data (such as JSON or YAML format), provided by the user through a graphical interface or API, and is used to define: the schema description of the initial format (including field names, types, nesting structure, optionality, etc.); the schema description of the target format; field mapping rules; data conversion strategies (such as type casting, default value filling, enumeration mapping); security strategies (encryption algorithm, key identifier, signature method); compression and transmission options; and the corresponding simulator identifier (used for subsequent compatibility testing).

[0035] Step 202: Perform syntax and semantic verification on the format configuration information; In this embodiment of the invention, after obtaining the format configuration information and before performing data conversion, the configuration information can first be subjected to syntax and semantic verification to ensure that its structure is legal, its logic is consistent and it can be executed safely. Illegal, inconsistent or potentially risky configuration items can be detected and intercepted in advance to prevent incorrect configurations from being saved, converted or sent to the device.

[0036] The syntax validation includes: parsing the user-input configuration text using a standard JSON parsing library. If parsing fails, an error message is immediately returned indicating "Invalid configuration format"; checking the presence of required fields (field name, type, path, etc.) based on a predefined configuration schema template; returning an error message "Missing required field: XXX" if any required field is missing; checking the data type of each field to ensure it meets expectations; returning an error message "Field XXX type is incorrect, expected to be XXX, actually XXX" if the types do not match; and recursively checking the internal fields of nested structures (such as structs and arrays) to ensure they conform to the schema definition, preventing deep structure errors.

[0037] Semantic validation includes: a built-in extensible semantic rule engine; field mapping conflict detection: for example, checking if multiple source fields map to the same target field; if so, and a "merging strategy" (such as summation or concatenation) is not enabled, it is marked as "mapping conflict"; checking if a target field is not mapped but is marked as required: true, prompting "required field not assigned a value"; type conversion feasibility analysis: for example, if the source field type is string and the target type is int, checking if type conversion rules (such as regular expression extraction, default values) are configured; if not configured and there are no default values, prompting "potential type conversion failure risk"; supporting preset conversion functions; if the reference function does not exist, Error message: "Function not defined"; Encryption and compression strategy compatibility check: For example, check if the encryption and compression order is reasonable: generally, "compress first, then encrypt"; Protocol compatibility verification: For example, check if the number of fields exceeds the protocol limit (e.g., CoAP maximum 1KB load); Default value and null value handling strategy check: For example, for fields with required: true, if there is no default value and the source field may be empty, prompt "Default value or fault tolerance strategy needs to be set"; Version compatibility prediction (optional): For example, if the current configuration is an update of an existing version, the system automatically compares with the old version to identify whether fields that the old program depends on have been deleted; if so, prompt: "Field XXX has been deleted, which may affect the compatibility of the old program". Corresponding detection mechanisms can be added according to specific business needs.

[0038] Step 203: If the syntax and semantic verification of the format configuration information pass, the initial data is converted from the initial format to the target format according to the format configuration information to obtain the target data; In this embodiment of the invention, if the syntax and semantic verification of the format configuration information pass, a structured data conversion operation can be performed based on the field mapping rules, type conversion strategies, security strategies and serialization specifications defined in the format configuration information to parse the initial data of the initial format encoding and generate target data that meets the requirements of the target platform.

[0039] Step 204: Generate a configuration snapshot and version number corresponding to the format configuration information; the configuration snapshot is used to record the modification information of the initial data, and the version number is used to identify the configuration snapshot corresponding to the format configuration information; generate a difference report between the initial data and the target data; In this embodiment of the invention, after verifying the format configuration information and converting the data, a configuration snapshot and version number can be generated. The currently valid format configuration information is serialized to generate an immutable configuration snapshot. This snapshot can completely record all configuration content on which this conversion depends, such as: the schema definitions of the initial and target formats, field mapping rules, type conversion strategies, encryption / compression and transmission protocol configurations, simulator identifiers, and compatibility detection parameters. Simultaneously, a unique version number (e.g., v2.1.0) can be automatically generated or specified by the user to identify the configuration snapshot. The configuration snapshot and version number can be persistently stored in a distributed configuration version repository and bound to metadata such as the conversion task ID, timestamp, and operator, achieving full lifecycle traceability.

[0040] It can also perform a structured comparison between the initial data (source format) and the target data (converted format) to generate a difference report, which visually demonstrates the changes in data structure brought about by the format conversion. Difference analysis can be performed level by level based on field paths to identify the following types of changes: field additions, field deletions, field renamings, type changes, value transformations, etc. The difference report can be output in a structured format and can be linked to the configuration snapshot version to help developers understand the impact of the conversion; it supports automated regression test case generation; and it serves as one of the inputs for compatibility assessments.

[0041] Step 205: Call the simulator corresponding to the initial format to perform format detection on the target data, and call the simulator corresponding to the target format to perform format detection on the initial data, to obtain bidirectional detection results; In this embodiment of the invention, to verify the interoperability between the initial format and the target format, a bidirectional simulation parsing test can be performed. Specifically, a simulator corresponding to the initial format is invoked to perform a forward compatibility test, parsing the target data based on the parsing rules of the historical version to test the compatibility of the old system with the new format data; a simulator corresponding to the target format is invoked to perform a reverse compatibility test, parsing the initial data based on the parsing rules of the current version to test the compatibility of the new system with the old format data; the structural integrity, field existence, type consistency, and security verification results in both parsing processes are recorded respectively to form a bidirectional test result.

[0042] The positive compatibility check includes: calling the simulator corresponding to the initial format (i.e., a lightweight parsing engine representing the parsing capabilities of the old version system or old platform), attempting to load and parse the target data generated by the current conversion process. This simulator strictly follows the historical schema definition, type constraints, and parsing logic of the initial format; checking for unrecognizable new fields, incompatible changes to field types, unsupported encryption algorithms or keys, and uncompressible compression formats.

[0043] Reverse compatibility testing includes: calling the simulator corresponding to the target format (i.e., the parsing engine representing the parsing capabilities of the new version system or new platform), attempting to load and parse the original initial data. This simulator is based on the latest schema and fault tolerance mechanism of the target format (such as supporting default value filling and handling missing optional fields); whether it can correctly handle missing fields, whether it has downgrade compatibility with obsolete fields in the old version data, and whether the old data is rejected due to security policy upgrades, etc.

[0044] Step 206: Generate a format conversion report based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format; In one embodiment, the format conversion report includes a format compatibility report and a format incompatibility report; the step of generating the format conversion report based on the bidirectional detection results may further include the following sub-steps: Sub-step S11: Determine whether the target data has missing fields, mismatched types, or failed encryption based on the bidirectional detection results; Sub-step S12: In the event that the target data field is missing, the type does not match, or the encryption fails, a format incompatibility report is generated. Sub-step S13: If the target data fields are complete, the types match, and the encryption is successful, generate a format-compatible report.

[0045] In this embodiment of the invention, based on the bidirectional detection results, the system can automatically determine whether key compatibility issues such as missing fields, type mismatches, or encryption failures occur during the simulated parsing process of the target data, and generate a corresponding compatibility conclusion report accordingly. Specifically, the system can iterate through the parsing logs and structure comparison information returned by the initial format simulator and the target format simulator in the bidirectional detection results, and perform the following judgments: If any of the following situations occur in either direction of the detection, it is determined to be incompatible: missing fields, the target data lacks the required fields that the old system depends on, or the new system cannot obtain the necessary fields from the old data; type mismatch, the type of the same field after parsing does not match the expectation; encryption failure, the decryption is abnormal due to key version mismatch, algorithm incompatibility, or integrity verification failure. If no of the above problems occur in the bidirectional detection, that is: all required fields are complete, all field types are consistent with the target schema, and the encryption / decryption process is successfully completed, it is determined to be compatible.

[0046] When an incompatibility is determined, the system generates a format incompatibility report, which may include: a list of specific failures; the direction of occurrence (forward / reverse); the severity level of the error; and remediation suggestions (such as "add default values ​​for the target format" or "synchronize and update client keys"). When a compatibility is determined, a format compatibility report can be generated, which includes: a "compatibility" conclusion identifier; the configuration snapshot version number; a summary of successful bidirectional testing; and recommendations for safe deployment.

[0047] Step 207: If the initial format is incompatible with the target format, a repair suggestion is generated based on the bidirectional detection result; the repair suggestion is used to indicate that the target format should be modified to make the initial format compatible with the target format; In this embodiment of the invention, when it is determined that the initial format is incompatible with the target format (i.e., there are problems such as missing fields, type mismatch, or encryption failure), the bidirectional detection results can be further analyzed to automatically generate structured repair suggestions. These suggestions guide users or automated tools to modify the target format (or its corresponding format configuration information) to restore compatibility. The repair suggestions can also be directly adopted by the graphical configuration interface, applied to the current format configuration information with one click, and trigger a new round of conversion and compatibility verification, forming a closed loop of "detection—suggestion—repair—verification".

[0048] Step 208: If the initial format is compatible with the target format, compress the target data and transmit the compressed target data across platforms.

[0049] In this embodiment of the invention, once the initial format is determined to be compatible with the target format (i.e., a format compatibility report is generated), data compression and cross-platform distribution processes can be automatically triggered to improve transmission efficiency and resource utilization. Performing compression only after confirming compatibility avoids ineffective optimization or propagation of data with compatibility risks, ensuring the security principle of "verification before delivery." Specifically, the target data can be compressed according to the preset compression strategy in the format configuration information. Supported compression algorithms include, but are not limited to: general algorithms such as gzip, zlib, LZ4, and Zstandard (zstd); format-aware compression, such as dictionary encoding and merging of repeated fields for MessagePack or Protobuf; and adaptive compression, which dynamically selects the optimal algorithm based on data characteristics (such as text proportion and numerical density). Compression parameters (such as compression level and block size) can be specified by the format configuration information to ensure matching with the decompression capabilities of the receiving end.

[0050] This invention can convert initial data from an initial format to a target format based on format configuration information to obtain the target data. Through versioned format configuration information, each data conversion process can be associated with a specific configuration version, achieving end-to-end traceability. The system calls the simulator corresponding to the initial format to perform format detection on the target data, and the simulator corresponding to the target format to perform format detection on the initial data, obtaining bidirectional detection results. By realistically simulating the interaction scenario between the old and new systems, potential compatibility issues such as missing fields, type mismatches, and encryption failures can be effectively identified, preventing online incidents caused by anomalies. A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial and target formats are compatible. By introducing a bidirectional simulation detection mechanism, the compatibility between the initial and target formats is verified simultaneously during the format conversion process, ensuring that the converted data behaves predictably on the target platform, improving system stability and security, while significantly reducing manual testing and debugging time and improving R&D efficiency.

[0051] Reference Figure 3 The diagram illustrates a logic diagram of a data format conversion method provided by an embodiment of the present invention. To enable those skilled in the art to better understand the embodiments of the present invention, the following explanation is provided... Figure 3 The embodiments of the present invention are described below: Step 301: Receive and parse the JSON format configuration information input by the user through the graphical interface, which is used to define the data structure, field mapping rules, data compression strategy, encryption method and transmission protocol type required by the target platform; Step 302: The system performs syntax and semantic verification on the configuration content to ensure that the field names, types, paths and other information are legal and valid.

[0052] Step 303: Perform versioning processing on the configuration information, generate a unique semantic version number (e.g., v1.2.3), record the modification time, operator, and change summary, and store the configuration snapshot in the distributed version repository; at the same time, the system automatically triggers the version comparison mechanism to generate a difference report between the previous and current versions, allowing users to view detailed information such as field additions and deletions and policy changes, so as to achieve traceability, auditability, and rollback of configuration changes.

[0053] The "unique semantic version number" is the core identification mechanism of the configuration management module. It uniquely identifies each snapshot of configuration changes, enabling traceability, comparability, rollback, and compatibility analysis of the configuration. The format is: v major version number.minor version number.revision number. The initial system configuration version was v1.0.0, and it has undergone several modifications since then.

[0054] When configuration changes occur, a new version number is automatically generated. For example, if the system detects a new field but does not delete or modify an existing field, it is considered a backward-compatible feature enhancement. The version number is automatically upgraded from v1.2.3 to v1.3.0 (minor version number +1, revision number reset to zero). Purpose: To identify this change as a "new feature" without affecting the operation of old programs.

[0055] Significant structural changes trigger a major version upgrade. For example, a user changes the sensor_data structure from a flat structure to a nested structure and deletes the voltage field. Field deletion, renaming, and structure nesting are detected as incompatible changes. The system prompts: "Incompatible changes detected; it is recommended to upgrade the major version number." After user confirmation, the system generates a new version number, v2.0.0. Purpose: To clearly indicate that "this version is incompatible with older programs," triggering compatibility testing and risk warnings.

[0056] This fixes configuration errors by only upgrading the revision number. For example, a user discovered that the `humidity` field type was incorrectly set to `string` when it should be `float`; this has been corrected. Only errors are fixed; no new or deleted fields are added. This is a backward compatibility fix. The system automatically upgrades the version number from v1.3.0 to v1.3.1. Purpose: Marked as a "patch update," it eliminates the need to retest compatibility and allows for rapid deployment.

[0057] Version comparison and difference analysis: For example, when a user views the differences between v1.2.3 and v1.3.0, the system automatically retrieves the two snapshots based on the version number and generates a comparison report. Purpose: To help users quickly understand the changes and assist in deciding whether to release.

[0058] Version rollback, for example, after upgrading to v1.4.0, it was found that the new configuration caused older devices to be unable to parse data. The user selects "Rollback to v1.3.1" on the interface. The system finds the corresponding configuration snapshot based on version number v1.3.1, restores and regenerates the MessagePack format, automatically triggering compatibility testing to confirm that the older device can run normally. Purpose: To achieve "one-click rollback" and ensure high system availability.

[0059] Version references in compatibility testing, for example, in bidirectional compatibility testing, the system automatically calls: the old program emulator: using the parsing logic of v1.3.1 to test whether it can read data from v1.4.0; the new program emulator: using the parsing logic of v1.4.0 to test whether it can read data from v1.3.1; the test report clearly states: "Test result: v1.4.0 is compatible with v1.3.1 data (compatibility score: 92)". Purpose: The version number is used as a test input parameter to ensure that the test is reproducible and traceable.

[0060] Configuration distribution is matched with the device. For example, when the device starts up, it reports the configuration version number it supports (e.g., supported_config_version: "v1.3.1"). Based on this information, the cloud system automatically selects and distributes a compatible configuration ≤v1.3.1; if the latest configuration is v2.0.0, the system prompts: "The device does not support v2.0.0, please upgrade the firmware or use a downgraded configuration." Purpose: To achieve "intelligent adaptation by version" and avoid device-side parsing failures.

[0061] Step 304: The JSON configuration information is automatically converted into an efficient binary format, such as MessagePack, and a corresponding schema description file is generated. This process adopts an intelligent encoding strategy, which selects the optimal compression and serialization method according to the field type and data characteristics, significantly reducing the data volume and improving the parsing speed.

[0062] The selection of the optimal compression and serialization method based on field type and data characteristics can be achieved through an intelligent encoding strategy engine, which includes the following four stages: I. Field Type Identification and Classification: The system first performs type analysis on each field defined in the configuration to identify its data semantics and structural characteristics. Based on the type field and schema definition in the configuration, and combined with runtime sampled data, type inference is performed.

[0063] II. Data Feature Extraction and Analysis: The system extracts features from historical or sampled data to guide the selection of compression and serialization strategies. This includes: data distribution analysis, data length statistics, update frequency analysis, and platform performance constraints.

[0064] III. Compression and Serialization Strategy Matching: The system has a built-in extensible encoding strategy rule library that matches the optimal combination based on field type and data characteristics.

[0065] IV. Dynamic Encoding Execution and Feedback Optimization: Encoding execution process; MessagePack is selected as the default serialization method. For nested structures, fragmented serialization is supported to avoid memory overflow; Feedback optimization mechanism, such as recording compression rate, encoding time, and decoding time after encoding; If the actual performance does not meet expectations (e.g., compression rate <50%), the system automatically tries alternative strategies; A / B testing is supported to compare the performance of different strategies in a real environment.

[0066] Step 305: After the configuration update, the following test process is automatically executed: Use the "Legacy Program Simulator" to attempt to parse the newly generated new format data (simulating an old program reading new data); use the "New Program Simulator" to attempt to parse historical versions of old format data (simulating a new program reading old data); by comparing the parsing results, identify compatibility issues such as missing fields, type mismatches, and encryption failures, and generate a structured report. Use the "Legacy Program Simulator" to load historical versions of old format data and attempt to parse the currently generated new format data to detect issues such as missing fields, type mismatches, and encryption failures; use the "New Program Simulator" to load old versions of configuration and data and attempt to parse the newly generated new format data to verify its downgrade capability.

[0067] Step 306: The compatibility analysis engine automatically identifies risk items and generates structured test logs based on AST (Abstract Syntax Tree) or Schema comparison algorithms.

[0068] Step 307: Generate a compatibility assessment report, including: a list of risk items (such as "Field A has been deleted" and "The encryption algorithm has been changed from AES-128 to AES-256"); and remediation suggestions (such as "It is recommended to add default value processing logic in the new program" and "All client keys need to be updated synchronously").

[0069] This invention allows the system to automatically generate a unique version identifier for the configuration after a user modifies the JSON configuration, and record metadata such as modification time, operator, and change summary, storing this information in a distributed version control repository. Simultaneously, configuration changes trigger automatic snapshot generation, supporting version rollback, difference comparison, and audit traceability. By introducing a version control mechanism into the data format conversion engine, it achieves full lifecycle management of "configuration as code"; provides a visual change log, supporting filtering by time, user, and field change type; and supports configuration difference comparison, highlighting newly added, deleted, and modified fields and strategies, improving readability and maintainability. It achieves traceability, auditability, and rollback of configuration changes, significantly reducing system upgrade risks; and improves team collaboration efficiency, avoiding conflicts caused by multiple users modifying the configuration simultaneously.

[0070] This invention also constructs a bidirectional compatibility testing engine, which automatically executes the following test process after configuration updates: using an "old program simulator" to attempt to parse newly generated new format data (simulating an old program reading new data); using a "new program simulator" to attempt to parse old format data from historical versions (simulating a new program reading old data); and comparing the parsing results to identify compatibility issues such as missing fields, type mismatches, and encryption failures, and generating a structured report. This compatibility testing paradigm, combining bidirectional simulation and automatic analysis, overcomes the limitations of traditional one-way conversion; it introduces a sandboxed simulator to run different versions of program logic in an isolated environment, ensuring reliable test results; and it automatically generates repair suggestions, such as "recommend keeping field A" or "add type conversion logic," achieving intelligent early warning. This enables risk prediction before upgrades, avoiding "crashes upon deployment"; significantly reduces system maintenance costs and manual testing and debugging time; and supports canary releases and gradual upgrades, improving system availability and user experience.

[0071] It should be noted that the data format conversion method provided in this embodiment of the invention can be executed by a data format conversion device, or a control module within the data format conversion device for executing the loading data format conversion method. This embodiment of the invention uses the execution of the loading data format conversion method by a data format conversion device as an example to illustrate the data format conversion method provided in this embodiment of the invention.

[0072] Reference Figure 4 The diagram illustrates a structural block diagram of a data format conversion apparatus provided in an embodiment of the present invention. The apparatus includes: Initial data acquisition module 401 is used to acquire initial data and format configuration information; The target format conversion module 402 is used to convert the initial data from the initial format to the target format according to the format configuration information to obtain the target data; The detection result determination module 403 is used to call the simulator corresponding to the initial format to perform format detection on the target data, and to call the simulator corresponding to the target format to perform format detection on the initial data, so as to obtain a bidirectional detection result; The conversion report generation module 404 is used to generate a format conversion report based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

[0073] In this embodiment of the invention, the format conversion report includes a format compatibility report and a format incompatibility report; the conversion report generation module includes: The detection result judgment submodule is used to determine whether the target data has missing fields, mismatched types, or failed encryption based on the bidirectional detection results. The incompatible report generation submodule is used to generate an incompatible report in the event that the target data field is missing, the type does not match, or the encryption fails. The compatibility report generation submodule is used to generate a format-compatible report if the target data fields are complete, the type matches, and the encryption is successful.

[0074] In this embodiment of the invention, the device further includes: A repair suggestion generation module is used to generate repair suggestions based on the bidirectional detection results when the initial format is incompatible with the target format; the repair suggestions are used to indicate that the target format should be modified to make the initial format compatible with the target format.

[0075] In this embodiment of the invention, the device further includes: A cross-platform transmission module is used to compress the target data while ensuring that the initial format is compatible with the target format, and then transmit the compressed target data across platforms.

[0076] In this embodiment of the invention, before the target format conversion module, the apparatus further includes: The configuration information verification module is used to perform syntax and semantic verification on the format configuration information. The target format conversion module includes: The target format conversion submodule is used to convert the initial data from the initial format to the target format according to the format configuration information, provided that the syntax and semantic verification of the format configuration information are passed.

[0077] In this embodiment of the invention, the device further includes: A configuration snapshot generation module is used to generate a configuration snapshot and a version number corresponding to the format configuration information; the configuration snapshot is used to record the modification information of the initial data, and the version number is used to identify the configuration snapshot corresponding to the format configuration information.

[0078] In this embodiment of the invention, the device further includes: The difference report generation module is used to generate a difference report between the initial data and the target data.

[0079] This invention can convert initial data from an initial format to a target format based on format configuration information to obtain the target data. Through versioned format configuration information, each data conversion process can be associated with a specific configuration version, achieving end-to-end traceability. The system calls the simulator corresponding to the initial format to perform format detection on the target data, and the simulator corresponding to the target format to perform format detection on the initial data, obtaining bidirectional detection results. By realistically simulating the interaction scenario between the old and new systems, potential compatibility issues such as missing fields, type mismatches, and encryption failures can be effectively identified, preventing online incidents caused by anomalies. A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial and target formats are compatible. By introducing a bidirectional simulation detection mechanism, the compatibility between the initial and target formats is verified simultaneously during the format conversion process, ensuring that the converted data behaves predictably on the target platform, improving system stability and security, while significantly reducing manual testing and debugging time and improving R&D efficiency.

[0080] The data format conversion device in this embodiment of the invention can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This embodiment of the invention does not impose specific limitations.

[0081] The data format conversion device in this embodiment of the invention can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this embodiment of the invention does not impose specific limitations.

[0082] The data format conversion device provided in this embodiment of the invention can achieve Figures 1 to 3 The various processes implemented by the data format conversion device in the method embodiment will not be described again here to avoid repetition.

[0083] Optionally, embodiments of the present invention also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described data format conversion method embodiments and achieve the same technical effects. To avoid repetition, further details are omitted here. It should be noted that the electronic device in the embodiments of the present invention includes the aforementioned mobile electronic device and non-mobile electronic device.

[0084] This invention also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described data format conversion method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0085] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0086] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of the present invention is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0087] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0088] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other modifications under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these modifications are within the protection scope of the present invention.

Claims

1. A data format conversion method, characterized in that, The method includes: Obtain initial data and format configuration information; According to the format configuration information, the initial data is converted from the initial format to the target format to obtain the target data; The simulator corresponding to the initial format is invoked to perform format detection on the target data, and the simulator corresponding to the target format is invoked to perform format detection on the initial data, to obtain a bidirectional detection result; A format conversion report is generated based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

2. The data format conversion method according to claim 1, characterized in that, The format conversion report includes a format compatibility report and a format incompatibility report; The step of generating a format conversion report based on the bidirectional detection results includes: Based on the bidirectional detection results, determine whether the target data has missing fields, mismatched types, or failed encryption; If the target data field is missing, the type does not match, or encryption fails, generate a format incompatibility report; If the target data fields are complete, the types match, and encryption is successful, a format-compatible report is generated.

3. The data format conversion method according to claim 1, characterized in that, The method further includes: If the initial format is incompatible with the target format, a repair suggestion is generated based on the bidirectional detection results; the repair suggestion is used to indicate that the target format should be modified to make the initial format compatible with the target format.

4. The data format conversion method according to claim 1, characterized in that, The method further includes: If the initial format is compatible with the target format, the target data is compressed, and the compressed target data is transmitted across platforms.

5. The data format conversion method according to claim 1, characterized in that, Before converting the initial data from the initial format to the target format according to the format configuration information, the method further includes: The format configuration information is subjected to syntax and semantic validation. The step of converting the initial data from the initial format to the target format according to the format configuration information includes: If the syntax and semantic validation of the format configuration information pass, the initial data is converted from the initial format to the target format according to the format configuration information.

6. The data format conversion method according to claim 1, characterized in that, The method further includes: Generate a configuration snapshot and version number corresponding to the format configuration information; the configuration snapshot is used to record the modification information of the initial data, and the version number is used to identify the configuration snapshot corresponding to the format configuration information.

7. The data format conversion method according to claim 1, characterized in that, The method further includes: Generate a difference report between the initial data and the target data.

8. A data format conversion device, characterized in that, The device includes: The initial data acquisition module is used to acquire initial data and format configuration information; The target format conversion module is used to convert the initial data from the initial format to the target format according to the format configuration information to obtain the target data; The detection result determination module is used to call the simulator corresponding to the initial format to perform format detection on the target data, and to call the simulator corresponding to the target format to perform format detection on the initial data, so as to obtain a bidirectional detection result; A conversion report generation module is used to generate a format conversion report based on the bidirectional detection results; the format conversion report is used to characterize whether the initial format is compatible with the target format.

9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the data format conversion method as described in claims 1-7.

10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the data format conversion method as described in claims 1-7.

Images