Multilingual protocol conversion method, electronic device, storage medium, and program product

Abstract

This invention relates to the field of protocol communication technology, specifically to a multilingual protocol conversion method, electronic device, storage medium, and program product. The method includes: receiving a protocol call request for a target device, obtaining object parameter data, a development language environment identifier, and a method identifier; determining a field mapping rule between the object parameter data and binary protocol data packets based on the development language environment identifier and the method identifier; assembling packets according to the field mapping rule and sending them to the target device; receiving the response binary data returned by the target device, parsing it, obtaining the response object data, and returning it to the development language environment. This invention achieves a unified conversion between object-oriented calls and underlying protocol data in different development language environments.

Description

Technical Field

[0001] This invention relates to the field of protocol communication technology, specifically to multilingual protocol conversion methods, electronic devices, storage media, and program products. Background Technology

[0002] As computer peripherals evolve towards high performance, programmability, and multi-device collaboration, the communication capabilities between host computer software and peripherals have become a crucial foundation affecting product development efficiency, ecosystem compatibility, and functional expansion capabilities. For keyboards, mice, and other connectable devices, developers typically need to achieve consistent device control and data interaction across different operating environments, including web, desktop, and embedded systems. This directly impacts the efficiency of secondary development, cross-platform adaptability, and the speed of subsequent functional expansion for peripheral products.

[0003] In existing solutions, upper-layer calling methods often depend on specific development languages ​​and runtime environments. Inconsistent interface input structures, parameter organization, and return result representations lead to the need for separate adaptations of the same control capability across different development environments. Meanwhile, the device side actually receives binary data packets in a fixed format. The lack of a stable and unified mapping process between upper-layer objectified parameters and lower-layer protocol data easily results in inconsistent packet assembly rules, chaotic field correspondences, scattered parsing logic, and difficulties in uniformly encapsulating return results. As device types continue to increase and protocol fields gradually expand, these problems further amplify maintenance costs, impacting the reuse of peripheral protocol capabilities and software development efficiency. Summary of the Invention

[0004] This invention provides a multilingual protocol conversion method, electronic device, storage medium, and program product, which at least solves the problem of how to uniformly convert object-oriented call data into binary protocol data recognizable by the target device in different development language environments and uniformly restore the device response results.

[0005] In a first aspect, the present invention provides a multilingual protocol conversion method, the method comprising: Receive protocol call requests for the target device and obtain the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request; Based on the development language environment identifier and method identifier, determine the field mapping rules between object parameter data and binary protocol data packets. The binary protocol data packets include a protocol header and a data area. The object parameter data is packaged according to the field mapping rules to obtain a binary protocol data packet, and then the binary protocol data packet is sent to the target device. Receive the response binary data returned by the target device, parse the response binary data according to the development language environment identifier and method identifier to obtain the response object data, and return the response object data to the development language environment.

[0006] In one possible implementation, receiving a protocol call request for the target device and obtaining the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request includes: receiving call data sent by the upper-layer interface as a protocol call request; and extracting the object parameter data, development language environment identifier, and method identifier from the call data.

[0007] In one possible implementation, the field mapping rules between object parameter data and binary protocol data packets are determined based on the development language environment identifier and the method identifier, including: determining the target object type based on the method identifier; determining the parameter fields in the object parameter data based on the target object type; determining the field conversion rules corresponding to the parameter fields based on the development language environment identifier; and generating field mapping rules based on the parameter fields and the field conversion rules.

[0008] In one possible implementation, a field mapping rule is generated based on the parameter field and the field conversion rule, including: determining the command identification information in the protocol header based on the method identifier; determining the field arrangement order in the data area based on the parameter field; and establishing the correspondence between the parameter field and the command identification information and the field arrangement order in the data area to obtain the field mapping rule.

[0009] In one possible implementation, the protocol header includes an identification header, length information, command data length, checksum data, source address, destination address, and command identification information, which includes the main command and subcommands.

[0010] In one possible implementation, the object parameter data is packaged according to the field mapping rules to obtain a binary protocol data packet, including: generating a single binary protocol data packet when the length of the binary protocol data packet is not greater than a preset length; and splitting the binary protocol data packet into a first binary protocol data packet and subsequent binary protocol data packets when the length of the binary protocol data packet is greater than the preset length. The first binary protocol data packet includes a protocol header and a partial data area, and the subsequent binary protocol data packets include length information and data in the remaining data area. The preset length is the upper limit of the single packet length corresponding to the underlying communication protocol.

[0011] In one possible implementation, the system receives binary response data returned by the target device, parses the binary response data according to the development language environment identifier and the method identifier to obtain response object data, including: determining the response object type corresponding to the binary response data according to the method identifier; determining the field parsing rules according to the development language environment identifier and the response object type; and parsing the binary response data according to the field parsing rules to obtain the response object data.

[0012] In a second aspect, the present invention provides an electronic device, comprising: a processor; a memory for storing a computer program that can run on the processor; wherein, when the processor executes the computer program, it implements a multilingual protocol conversion method.

[0013] Thirdly, the present invention provides a storage medium storing a computer program, which, when executed by a processor, implements a multilingual protocol conversion method.

[0014] Fourthly, the present invention provides a program product, which includes a computer program that, when executed by a processor, implements a multilingual protocol conversion method.

[0015] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By introducing development language environment identifiers and method identifiers, unified identification of upper-layer call contexts is achieved, enabling call requests from different development environments to form a consistent data foundation before entering the protocol processing flow, reducing adaptation branches caused by differences in call entry points.

[0016] By establishing field mapping rules between object parameter data and binary protocol data packets, a unified organization of object-oriented parameters to protocol fields is achieved, enabling upper-layer business parameters to be written into the protocol header and data area according to fixed rules, thus avoiding the problem of inconsistent packet assembly results under different implementation methods.

[0017] By performing packet assembly and transmission according to field mapping rules, the direct conversion of upper-layer call data to target device protocol commands is realized, making the protocol delivery process have a clear field source and data destination.

[0018] By parsing the response binary data based on the development language environment identifier and method identifier, the unified restoration of the device return result to the response object data is achieved, enabling different development environments to receive the execution result in a consistent object form.

[0019] By incorporating request-side packet assembly and response-side parsing into the same processing loop, the peripheral protocol call process is unified and standardized, which helps reduce development costs and improve the reusability of protocol capabilities. Attached Figure Description

[0020] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a schematic diagram illustrating the protocol call request reception and call context extraction of the present invention; Figure 3 This is a schematic diagram illustrating the generation of field mapping rules and protocol data packetization in this invention; Figure 4 This is a schematic diagram illustrating the packet sending and response object parsing of the present invention. Detailed Implementation

[0021] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0022] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0023] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0024] Protocol conversion can be understood as a process of establishing a unified correspondence between different data representations. Its role is not to change the business semantics, but to convert the upper-layer readable, organizeable, and callable data representation into a data representation that can be stably transmitted through the lower-layer communication link and accurately recognized by the device side, and then perform reverse restoration on the return side. For peripheral control scenarios, upper-layer interfaces are more suitable for object-oriented and structured data organization methods, allowing developers to call functions accordingly; while the device side typically uses fixed-format protocol data packets to complete command recognition, parameter reading, and result return. Therefore, protocol conversion actually plays a bridging role of "keeping semantics unchanged while converting the representation method." Its core lies in establishing a mapping relationship between the upper-layer parameter structure and the lower-layer protocol fields, and ensuring that the conversion on the request side and the restoration on the response side can form a consistent closed loop. Based on this, this invention proposes a multi-language protocol conversion method for multiple development language environments, used to achieve unified conversion between object parameter data and binary protocol data packets in different development language environments.

[0025] like Figure 1 As shown, a multilingual protocol conversion method includes: Receive protocol call requests for the target device and obtain the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request; When the upper layer initiates a protocol call targeting a device, the protocol conversion layer first receives the protocol call request and reads the call data carried in the request. After entering the protocol conversion layer, the call data is not directly assembled into packets; instead, it is first split into object parameter data, a development language environment (LLE) identifier, and a method identifier. The object parameter data carries the input content corresponding to the current business command, the LLE identifier represents the LLE of the current call request, and the method identifier represents the business method corresponding to the current call request. After extraction, the object parameter data, LLE identifier, and method identifier are associated with the same call context for subsequent field mapping processing, enabling unified organization of protocol data based on the LLE and business method.

[0026] like Figure 2 As shown, the protocol call request for the target device is received, and the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request are obtained. This includes: receiving call data sent by the upper-layer interface as a protocol call request; and extracting object parameter data, development language environment identifier, and method identifier from the call data.

[0027] In one embodiment, the protocol call request consists of call data sent by the upper-layer interface. Different development language environments can form call data according to their respective interface organization methods. The protocol conversion layer does not require different development language environments to maintain completely consistent parameter passing formats at the upper layer. Instead, after receiving the call data, it uniformly extracts the key content from the call data. The development language environment identifier is used to distinguish whether the call data comes from a web environment, a desktop environment, or a hardware-side operating environment, and can also be further mapped to a specific development language environment type.

[0028] Method identifiers are used to distinguish the business method being called, and different business methods correspond to different object parameter data structures. Object parameter data is used to carry the parameter content of the current business method, and its field composition is determined according to the business method. Taking the device information acquisition scenario as an example, the object parameter data can include at least one of the following: device serial number, firmware version, and device type; taking the layout acquisition scenario as an example, the object parameter data can include at least one of the following: row data, column data, button width, and button height.

[0029] After receiving the call data, the protocol conversion layer first determines whether the call data contains a development language environment identifier and a method identifier. If the call data contains both, it then determines the object parameter fields to be extracted based on the method identifier. If the business method corresponding to the method identifier does not require input parameters, the object parameter data can be determined as an empty parameter object, while retaining the development language environment identifier and method identifier for subsequent processing. If the call data lacks either a development language environment identifier or a method identifier, the current call can be terminated directly, and corresponding exception messages can be generated.

[0030] For extracting object parameter data, field values ​​can be read item by item according to a predefined field name table, and a structured parameter result can be formed according to the correspondence between field names and field values. After extraction, the development language environment identifier, method identifier, and object parameter data are written together into the current call record so that subsequent execution of field mapping rule determination, binary protocol data packet assembly, and response data parsing can continue.

[0031] Based on the development language environment identifier and method identifier, determine the field mapping rules between object parameter data and binary protocol data packets. The binary protocol data packets include a protocol header and a data area. Upon receiving the development language environment identifier and method identifier, the protocol conversion layer begins establishing a field mapping relationship between object parameter data and binary protocol data packets. This stage does not directly output the packet assembly result; instead, it first converts the business meaning in the object parameter data into field organization rules recognizable by the protocol layer. The binary protocol data packet consists of a protocol header and a data area. The protocol header carries command identification, length control, and send / receive positioning information, while the data area carries the business parameter content corresponding to the object parameter data. The protocol conversion layer first determines the business method corresponding to the current call based on the method identifier, then determines the data representation and field conversion method used for the current call based on the development language environment identifier. Subsequently, it maps the parameter content in the object parameter data to the corresponding positions in the protocol header and data area, generating field mapping rules. After the field mapping rules are generated, subsequent packet assembly stages can encode object parameter data from different development language environments according to unified rules, ensuring that protocol calls initiated from different development language environments fall into the same binary protocol format.

[0032] like Figure 3 As shown, based on the development language environment identifier and method identifier, the field mapping rules between object parameter data and binary protocol data packets are determined, including: determining the target object type based on the method identifier; determining the parameter fields in the object parameter data based on the target object type; determining the field conversion rules corresponding to the parameter fields based on the development language environment identifier; and generating field mapping rules based on the parameter fields and field conversion rules.

[0033] In one embodiment, this stage first determines the target object type based on the method identifier. The target object type represents the data structure category corresponding to the current method; different business methods correspond to different target object types. For example, the device information acquisition method corresponds to the device information object type, the layout acquisition method corresponds to the layout object type, and the lighting setting method corresponds to the lighting configuration object type.

[0034] Once the target object type is determined, parameter fields are extracted from the object parameter data based on that type. Parameter fields are the actual set of fields in the object parameter data that participate in protocol conversion; their number, names, order, and types are all pre-constrained by the target object type. The development language environment identifier distinguishes whether the current call originates from a web environment, desktop environment, or hardware-side runtime environment, and can further differentiate the specific development language environment. Because different development language environments differ in their representation of numerical values, strings, Boolean values, and methods of splitting complex objects, after extracting the parameter fields, it is also necessary to determine the corresponding field conversion rules based on the development language environment identifier.

[0035] Field conversion rules are used to at least limit the encoding type, length handling method, byte arrangement method, and null value handling method of parameter fields. For fixed-length fields, the corresponding length of binary content can be written directly according to the field type; for variable-length fields, the field length can be determined first, and then the actual field value can be written; for composite fields, they can be split into multiple basic fields first, and then the conversion can be performed separately.

[0036] After the field conversion rules are determined, the parameter fields and field conversion rules are combined to generate field mapping rules. The field mapping rules must at least record the parameter field name, the position of the parameter field in the binary protocol data packet, the field conversion rule used for the parameter field, and the correspondence between the parameter field and the method identifier. Through this process, object parameter data with different structural forms but the same business meaning in different programming language environments can be converted into a unified field mapping relationship, thus providing stable input for subsequent unified packet assembly.

[0037] The process involves generating field mapping rules based on parameter fields and field conversion rules, including: determining the command identification information in the protocol header based on the method identifier; determining the field arrangement order in the data area based on the parameter fields; and establishing the correspondence between parameter fields, command identification information, and the field arrangement order in the data area to obtain the field mapping rules.

[0038] In one embodiment, the generation of field mapping rules is further refined into two parts: protocol header mapping and data area mapping. Protocol header mapping is used to determine the content to be written for command identification information and basic control fields, while data area mapping is used to determine the order of business parameters and their write boundaries. The protocol conversion layer first looks up the command definition table based on the method identifier, and then determines the command identifier information corresponding to the current business method from the command definition table. The command identifier information is used to characterize the command category of the current business method at the protocol layer, and can be composed of a main command and sub-commands.

[0039] The main command distinguishes functional categories, while subcommands distinguish specific operations within the same functional category. After the command identifier is determined, the field order in the data area is generated based on the parameter fields. The field order does not directly depend on the original field order of the object parameter data, but rather on the protocol layer's data organization requirements for the current business method. For single-field business methods, the field order can directly match the parameter field order; for multi-field business methods, the fields are arranged sequentially according to the preset field order in the command definition table; for business methods containing complex structures, the complex structure can be first split into multiple basic parameter fields, and then written into the data area in a preset order. Subsequently, the protocol conversion layer establishes the correspondence between parameter fields, command identifier information, and the field order in the data area, obtaining complete field mapping rules.

[0040] This mapping relationship includes at least three levels: first, which type of command identification information controls which business method a certain parameter field belongs to; second, the starting position and order of a certain parameter field in the data area; and third, the field conversion rule used to encode a certain parameter field. Once the field mapping rules are formed, the subsequent packet assembly stage does not require re-analyzing the development language environment and object structure. It only requires writing the field mapping rules sequentially into the protocol header and data area to complete the construction of a unified binary protocol data packet.

[0041] The protocol header includes an identification header, length information, command data length, checksum data, source address, destination address, and command identification information, which includes the main command and subcommands.

[0042] In one embodiment, the protocol header is organized using a fixed set of fields, which includes at least an identification header, length information, command data length, checksum data, source address, destination address, and command identification information, including the main command and sub-commands.

[0043] The identification header indicates the start position of a binary protocol data packet, enabling the target device to identify whether the current data is a valid command start when receiving the byte stream. The length information indicates the effective length of the current data packet, helping the target device determine the number of bytes to receive. The command data length indicates the length of the service parameter content in the data area, distinguishing it from the protocol header length. The checksum data performs consistency checks on key fields and service parameters in the current data packet to determine if errors occurred during transmission. The source address identifies the side sending the current data packet, and the destination address identifies the target device or chip receiving the current data packet. The main command in the command identification information identifies the functional category of the current service, and the subcommand identifies the specific operation type within that functional category. When generating field mapping rules, the protocol conversion layer first determines the main and subcommands based on the method identifier, then determines the source and destination addresses based on the call context, subsequently determines the length information and command data length based on the total field length, and finally calculates the checksum data based on the protocol header and the content to be sent in the data area.

[0044] By adopting the above protocol header structure, business calls generated by different development language environments can complete a unified protocol header definition before entering the packet assembly stage, thereby ensuring that the content of the data area written subsequently is consistent with the length control, command identifier and send / receive location information in the protocol header.

[0045] The object parameter data is packaged according to the field mapping rules to obtain a binary protocol data packet, and then the binary protocol data packet is sent to the target device. After generating the field mapping rules, the protocol conversion layer assembles the object parameter data into binary protocol data packets according to these rules and sends them to the target device. During packet assembly, the content of each field in the protocol header is first determined based on the field mapping rules, and then the object parameter data is written into the data area according to the same rules, forming a complete data packet corresponding to the current method identifier. After data packet assembly, the binary protocol data packet is written into the transmission buffer and sent according to the underlying communication interface corresponding to the target device. Upon receiving the binary protocol data packet, the target device can receive and process the packet based on the identification and length information in the protocol header, thus completing the actual transmission of upper-layer object parameter data to lower-layer protocol commands.

[0046] The object parameter data is packaged according to the field mapping rules to obtain binary protocol data packets, including: generating a single binary protocol data packet when the length of the binary protocol data packet is not greater than the preset length; and splitting the binary protocol data packet into a first binary protocol data packet and subsequent binary protocol data packets when the length of the binary protocol data packet is greater than the preset length. The first binary protocol data packet includes a protocol header and part of the data area, and the subsequent binary protocol data packets include length information and the data in the remaining data area. The preset length is the upper limit of the single packet length corresponding to the underlying communication protocol.

[0047] In one embodiment, the packet assembly process first determines the byte arrangement of the protocol header and data area according to the field mapping rules, then calculates the total length of the current binary protocol data packet based on the arrangement result, and compares the total length with a preset length. The preset length represents the upper limit of the single packet length allowed by the underlying communication protocol. The preset length is not fixed to a certain abstract parameter, but is determined according to the underlying communication protocol used by the target device.

[0048] In common peripheral communication scenarios, the preset length can be taken as the upper limit of the effective transmission of a single packet allowed by the underlying communication protocol. For example, when using general serial bus communication, the preset length can correspond to the maximum number of bytes allowed in a single underlying transmission. If the total length of the current binary protocol data packet is not greater than the preset length, the protocol conversion layer directly generates a single-packet binary protocol data packet. In the single-packet binary protocol data packet, the protocol header is at the beginning, and the data area is at the end. The identification header, length information, command data length, checksum data, source address, destination address, main command, and subcommand in the protocol header are all written at once, and then the data area contents corresponding to the object parameter data are written sequentially according to the field mapping rules. If the total length of the current binary protocol data packet is greater than the preset length, the protocol conversion layer does not directly send the complete data packet, but splits the data packet according to the preset length to generate a first binary protocol data packet and one or more subsequent binary protocol data packets. The first binary protocol data packet is used to establish the receiving context of the current command, so the first packet retains the complete protocol header and writes part of the data area data.

[0049] Subsequent binary protocol packets are used to carry over any remaining data that the first packet could not contain. Therefore, subsequent binary protocol packets do not repeat the complete protocol header; instead, they retain the length information and are written sequentially into the remaining data area. During splitting, the number of bytes occupied by the protocol header in the first packet is first deducted from the preset length to obtain the length of the data area that the first packet can carry. Then, data of the corresponding length is truncated from the beginning of the data area and written into the first packet. The remaining unwritten data continues to be written in segments according to the length that subsequent binary protocol packets can carry, until all data area content has been written.

[0050] After the packet splitting is complete, the protocol conversion layer writes each packet into the transmission buffer in the order of first packet first, followed by subsequent packets, and sends them sequentially through the underlying communication interface corresponding to the target device. During transmission, after sending each packet, it can wait for the underlying transmission completion marker before continuing to send the next packet to avoid subsequent binary protocol data packets arriving at the target device before the first packet. If a transmission failure, buffer write failure, or failure to establish a receiving state is detected during transmission, the current transmission process is terminated, and the failure status is written to the current call record for subsequent response processing to identify whether the current call has been completed. Through the above packet assembly and transmission methods, object parameter data generated in different development language environments can be converted into unified single-packet or multi-packet binary protocol data packets under the constraints of field mapping rules and stably sent to the target device.

[0051] Receive the response binary data returned by the target device, parse the response binary data according to the development language environment identifier and method identifier to obtain the response object data, and return the response object data to the development language environment.

[0052] After the target device completes command execution, the protocol conversion layer receives the response binary data returned by the target device and performs parsing processing based on the development language environment identifier and method identifier corresponding to the current call. During parsing, the response binary data is not directly returned to the upper layer as is. Instead, the business scope corresponding to the current response is first determined based on the method identifier, and then the data expression method in the current development language environment is determined based on the development language environment identifier, restoring the response binary data into response object data. After restoration, the response object data is written into the return result and sent to the corresponding development language environment, enabling the upper-layer interface to receive the execution result in object form, thereby maintaining consistency in data organization between the call entry point and the return exit point.

[0053] like Figure 4 As shown, the system receives binary response data returned by the target device, parses the binary response data according to the development language environment identifier and the method identifier to obtain response object data, including: determining the response object type corresponding to the binary response data according to the method identifier; determining the field parsing rules according to the development language environment identifier and the response object type; and parsing the binary response data according to the field parsing rules to obtain the response object data.

[0054] In one embodiment, the parsing process of the response binary data includes three stages: determining the response object type, determining the field parsing rules, and reconstructing the response object data. After receiving the response binary data, the protocol conversion layer first reads the method identifier from the current call record and determines the response object type based on the method identifier.

[0055] The response object type characterizes the object structure that the current response should be restored to. Different method identifiers correspond to different response object types. For example, the device information retrieval method corresponds to the device information response object type, the layout retrieval method corresponds to the layout response object type, and the status reading method corresponds to the status response object type. After the response object type is determined, the field parsing rules are determined in conjunction with the development language environment identifier. The field parsing rules are used to limit the reading order, byte length, field type, field termination position, and field conversion method of each field in the response binary data. If the development language environment expresses integers, strings, booleans, or arrays differently, the field parsing rules further limit the restoration method of each type of field in the current development language environment.

[0056] The protocol conversion layer first performs basic splitting of the response binary data according to the field parsing rules, separating the identification information, length information, command identifier information, and data area content in the protocol header. Then, based on the field definitions corresponding to the response object type, it extracts the response fields sequentially from the data area. For fixed-length fields, they are directly read and converted according to the predetermined length; for variable-length fields, the length value is read first, and then the actual field content is extracted based on the length value; for composite fields, they are first split into multiple basic fields based on the field boundaries, and then conversion is performed separately for each. If the response field is an enumeration value, it is converted into an object field value according to the enumeration mapping table corresponding to the current method identifier; if the response field is a status value, it is converted into a status field according to the status definition table; if the response field is empty, the corresponding object field is written with an empty value or a default value.

[0057] After field extraction, the protocol conversion layer constructs response object data based on the field template of the response object type and writes the parsed field values ​​into the corresponding field positions one by one. If the command identifier information in the response binary data is inconsistent with the method identifier in the current call record, the current response object data reconstruction process is stopped, and the current response is marked as invalid. If the length information in the response binary data is inconsistent with the actual received length, the current response is marked as length abnormal. If field out-of-bounds errors, field type mismatches, or insufficient field quantity occur during field parsing, the current field parsing process is terminated, and an abnormal return result is generated. After successful parsing, the protocol conversion layer encapsulates the response object data into a return result according to the data organization method of the current development language environment and sends it to the corresponding development language environment so that the upper-layer interface can continue to process the device return data in an object-oriented manner.

[0058] An electronic device includes: a processor; a memory for storing a computer program that can run on the processor; wherein, when the processor executes the computer program, it implements a multilingual protocol conversion method.

[0059] In one embodiment, the electronic device can be a desktop device, a gateway device, an embedded control device, or other computing devices with protocol processing capabilities. The electronic device includes a processor and a memory. The memory stores computer programs and temporary data during operation, while the processor invokes the computer program in the memory to perform multilingual protocol conversion processing. Specifically, when executing the computer program, the processor first receives a protocol call request for the target device and obtains object parameter data, a development language environment identifier, and a method identifier from the request. Then, it determines the field mapping rules between the object parameter data and the binary protocol data packet based on the development language environment identifier and the method identifier. Subsequently, it assembles the object parameter data according to the field mapping rules, generates a binary protocol data packet, and sends the binary protocol data packet to the target device through the corresponding communication interface. After the target device returns response binary data, the processor continues to parse the response binary data according to the development language environment identifier and the method identifier to obtain response object data, and returns the response object data to the corresponding development language environment. In addition to storing the computer program, the memory can also be used to cache object parameter data, field mapping rules, binary protocol data packets, and response object data to support data reading and writing and state maintenance during the protocol conversion process.

[0060] A storage medium storing a computer program, which, when executed by a processor, implements a multilingual protocol conversion method.

[0061] In one embodiment, a computer program is stored in the storage medium. When loaded and executed by a processor, the computer program is used to implement multilingual protocol conversion processing. The storage medium can be a read-only memory, random access memory, flash memory, solid-state memory, disk storage, or optical disk storage, or any combination thereof. The computer program includes call request receiving instructions, field mapping rule determination instructions, protocol data packet assembly instructions, protocol data sending instructions, and response data parsing instructions. When the processor executes the call request receiving instructions, it receives protocol call requests and extracts object parameter data, development language environment identifiers, and method identifiers. When it executes the field mapping rule determination instructions, it establishes a field mapping relationship between object parameter data and binary protocol data packets based on the development language environment identifier and method identifier. When it executes the protocol data packet assembly instructions and protocol data sending instructions, it generates binary protocol data packets and sends them to the target device. When it executes the response data parsing instructions, it restores the response binary data returned by the target device to response object data and returns it to the development language environment. By storing the computer program in the storage medium, different hardware platforms can execute the same protocol conversion processing logic after loading the computer program.

[0062] A program product comprising a computer program that, when executed by a processor, implements a multilingual protocol conversion method.

[0063] In one embodiment, the program product includes a computer program, which can be packaged as an installation package, deployment package, upgrade package, or calling component for deployment in desktop environments, web environments, embedded runtime environments, or other runtime environments that support target business processing. When executed by a processor, the computer program implements a multi-language protocol conversion process. Specifically, the computer program in the program product first receives call data from an upper-layer interface and identifies the call data as a protocol call request; then it extracts object parameter data, development language environment identifier, and method identifier from the call data; next, it performs field mapping rule generation processing based on the development language environment identifier and method identifier, and converts the object parameter data into binary protocol data packets based on the field mapping rules; after completing the transmission of the binary protocol data packets, it continues to receive response binary data returned by the target device, and completes the parsing and conversion of the response binary data into response object data based on the development language environment identifier and method identifier; finally, it outputs the response object data to the corresponding development language environment. By adopting the above method, the program product can deploy and reuse the same protocol conversion capability in different runtime environments in the form of a software product.

[0064] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

[0065] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A multi-lingual protocol conversion method, characterized by, The method includes: Receive a protocol call request for the target device, and obtain the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request; Based on the development language environment identifier and the method identifier, the field mapping rules between the object parameter data and the binary protocol data packet are determined, wherein the binary protocol data packet includes a protocol header and a data area; The object parameter data is packaged according to the field mapping rules to obtain the binary protocol data packet, and the binary protocol data packet is sent to the target device; The system receives the response binary data returned by the target device, parses the response binary data according to the development language environment identifier and the method identifier to obtain response object data, and returns the response object data to the development language environment.

2. The method according to claim 1, characterized in that, The step of receiving a protocol call request for the target device and obtaining the object parameter data, development language environment identifier, and method identifier corresponding to the protocol call request includes: Receive the call data sent by the upper-layer interface as the protocol call request; Extract the object parameter data, the development language environment identifier, and the method identifier from the call data.

3. The method according to claim 1, characterized in that, The step of determining the field mapping rules between the object parameter data and the binary protocol data packet based on the development language environment identifier and the method identifier includes: The target object type is determined based on the method identifier; Determine the parameter fields in the object parameter data based on the target object type; The field conversion rules corresponding to the parameter fields are determined based on the development language environment identifier; The field mapping rule is generated based on the parameter field and the field conversion rule.

4. The method according to claim 3, characterized in that, The step of generating the field mapping rule based on the parameter field and the field conversion rule includes: The command identification information in the protocol header is determined according to the method identifier; The order of fields in the data area is determined based on the parameter fields. Establish the correspondence between the parameter fields and the command identification information, and the field arrangement order in the data area, to obtain the field mapping rules.

5. The method according to claim 1, characterized in that, The protocol header includes an identification header, length information, command data length, checksum data, source address, destination address, and command identification information, wherein the command identification information includes the main command and sub-commands.

6. The method according to claim 5, characterized in that, The step of assembling the object parameter data according to the field mapping rules to obtain the binary protocol data packet includes: When the length of the binary protocol data packet is not greater than a preset length, a single-packet binary protocol data packet is generated; If the length of the binary protocol data packet is greater than the preset length, the binary protocol data packet is split into a first binary protocol data packet and subsequent binary protocol data packets. The first binary protocol data packet includes the protocol header and part of the data area, and the subsequent binary protocol data packets include length information and data in the remaining data area. The preset length is the upper limit of the single packet length corresponding to the underlying communication protocol.

7. The method according to claim 1, characterized in that, The process involves receiving the response binary data returned by the target device, parsing the response binary data according to the development language environment identifier and the method identifier to obtain the response object data, including: The response object type corresponding to the response binary data is determined based on the method identifier; The field parsing rules are determined based on the development language environment identifier and the response object type; The response binary data is parsed according to the field parsing rules to obtain the response object data.

8. An electronic device, characterized in that, include: processor; Memory for storing computer programs that can run on the processor; When the processor executes the computer program, it implements the multilingual protocol conversion method as described in claim 1.

9. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the multilingual protocol conversion method as described in claim 1.

10. A program product, characterized in that, The program product includes a computer program, which, when executed by a processor, implements the multilingual protocol conversion method as described in claim 1.

Images