Data verification method, system and equipment for cross-language reconstruction code and medium

Abstract

The invention discloses a data verification method, system and device for cross-language reconstruction codes and a medium. The method comprises the steps that input parameters, configured by a user, of different development languages are obtained; calling interfaces of corresponding languages to execute cross-language service requests according to the configured input parameters of the different development languages, and acquiring JSON data of the different development languages returned from the interfaces; analyzing the JSON data of the different development languages returned by the interface to obtain the JSON data analyzed by the different development languages; and performing differential comparison on the JSON data analyzed by the different development languages to obtain a difference result. According to the method, the data verification process among different development languages is automatically processed, so that the workload of manually writing, converting and verifying codes by developers is remarkably reduced; and meanwhile, human errors possibly introduced during manual comparison of logs and data are effectively avoided, and the accuracy and reliability of data verification are improved.

Description

Technical Field

[0001] The present application relates to the technical field of code verification, and in particular to a data verification method, system, device and medium for cross-language reconstructed code. Background Art

[0002] In the field of software development, cross-language programming has become a common and necessary requirement. Different development languages ​​have different syntax, library functions, and data processing methods, making code refactoring and data interaction in a cross-language environment particularly complex. Especially in large software projects or distributed systems, different modules may be developed by different teams using different programming languages, which requires the system to be able to efficiently and accurately process data from multiple languages.

[0003] However, traditional data verification methods are often limited to a single language environment and are difficult to directly apply to cross-language scenarios. When code refactoring or data exchange between different programming languages ​​is required, developers usually need to frequently check program logs to ensure that the input and output of the refactored code flow meet expectations. Although this method is intuitive, it is inefficient and error-prone, which not only increases development costs, but also easily introduces errors, affecting software quality and maintenance efficiency. Especially in large systems, manual comparison of logs and data is time-consuming and labor-intensive, and it is difficult to meet the complex and changing cross-language development needs. Summary of the invention

[0004] The main purpose of this application is to overcome the shortcomings and deficiencies of the prior art and to provide a data verification method, system, device and medium for cross-language reconstructed code, which significantly reduces the workload of developers manually writing conversion and verification code by automatically processing the data verification process between different development languages; at the same time, it effectively avoids the human errors that may be introduced when manually comparing logs and data, and improves the accuracy and reliability of data verification.

[0005] In order to achieve the above objectives, this application adopts the following technical solutions:

[0006] In a first aspect, the present application provides a data verification method for cross-language reconstructed code, comprising the following steps:

[0007] Get the input parameters of different development languages ​​configured by the user;

[0008] According to the input parameters of different development languages ​​configured, the interface of the corresponding language is called to execute the cross-language service request, and the JSON data of different development languages ​​returned at the interface is obtained;

[0009] Parsing the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages;

[0010] The JSON data parsed by the different development languages ​​are differentially compared to obtain differential results.

[0011] As a preferred technical solution, the method of obtaining input parameters of different development languages ​​configured by the user includes obtaining URL parameters, query parameters, request parameters and request header parameters of different development languages ​​configured by the user.

[0012] As a preferred technical solution, after obtaining the input parameters of different development languages ​​configured by the user, the method further includes:

[0013] Check whether the types of input parameters of different development languages ​​configured by the user are consistent;

[0014] If it is detected that the types of the input parameters of the different development languages ​​configured by the user are inconsistent, a prompt message is issued to prompt the user to make corrections.

[0015] As a preferred technical solution, the step of checking whether the types of input parameters of different development languages ​​configured by the user are consistent includes:

[0016] Extract type information of input parameters of different development languages;

[0017] According to the user-defined mapping rules, the type information of input parameters of different development languages ​​is mapped to the same type system; if there is no matching custom mapping rule, the predefined type mapping rule is applied for mapping;

[0018] The mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent.

[0019] As a preferred technical solution, the parsing of the JSON data in different development languages ​​returned from the interface includes:

[0020] Convert the JSON data in the different development languages ​​into operable objects or data structures.

[0021] As a preferred technical solution, the JSON data parsed by the different development languages ​​are subjected to differential comparison to obtain differential results, including:

[0022] Traversing the JSON data parsed by different development languages ​​in a recursive or iterative manner, extracting features of all field information in the JSON data parsed by the different development languages; wherein the features include field name, field path, field type and field value;

[0023] Using a string edit distance algorithm to calculate the difference between the field names in the JSON data parsed by different development languages, and obtaining the field name difference results of the JSON data parsed by different development languages;

[0024] Analyze the structure and depth of the field path in the JSON data parsed by the different development languages ​​to obtain the difference results between the paths in the JSON data parsed by the different development languages;

[0025] Comparing the differences in the field types in the JSON data parsed by the different development languages ​​through type mapping and type hierarchy to obtain field type difference results of the JSON data parsed by the different development languages;

[0026] Manhattan distance is used to calculate the distance between the field values ​​in the JSON data parsed by different development languages, and the field value difference results of the JSON data parsed by different development languages ​​are obtained.

[0027] As a preferred technical solution, after performing differential comparison of field information on the JSON data parsed by the different development languages ​​and obtaining the difference results, the method further includes:

[0028] Generate a difference report based on the difference results, highlight the difference parts through the interface, and send an early warning notification;

[0029] The difference report includes recording the difference field information name, difference degree and improvement suggestions.

[0030] In a second aspect, the present application provides a data verification system for cross-language reconstructed code, which is applied to the data verification method for cross-language reconstructed code, and includes a parameter acquisition module, a call interface module, a data parsing module, and a difference comparison module;

[0031] The parameter acquisition module is used to obtain input parameters of different development languages ​​configured by the user;

[0032] The calling interface module is used to call the interface of the corresponding language to execute the cross-language service request according to the input parameters of the different development languages ​​configured, and obtain the JSON data of the different development languages ​​returned at the interface;

[0033] The data parsing module is used to parse the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages;

[0034] The difference comparison module is used to perform a difference comparison on the JSON data parsed by the different development languages ​​to obtain a difference result.

[0035] As a preferred technical solution, the parameter acquisition module is specifically used for:

[0036] The obtaining of input parameters of different development languages ​​configured by the user includes obtaining URL parameters, query parameters, request parameters and request header parameters of different development languages ​​configured by the user.

[0037] As a preferred technical solution, the parameter acquisition module further includes a consistency check submodule, and the consistency check submodule is used to:

[0038] Check whether the types of input parameters of different development languages ​​configured by the user are consistent;

[0039] If it is detected that the types of the input parameters of the different development languages ​​configured by the user are inconsistent, a prompt message is issued to prompt the user to make corrections.

[0040] As a preferred technical solution, the consistency check submodule is further specifically used for:

[0041] Extract type information of input parameters of different development languages;

[0042] According to the user-defined mapping rules, the type information of input parameters of different development languages ​​is mapped to the same type system; if there is no matching custom mapping rule, the predefined type mapping rule is applied for mapping;

[0043] The mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent.

[0044] As a preferred technical solution, the data parsing module is specifically used for:

[0045] Convert the JSON data in the different development languages ​​into operable objects or data structures.

[0046] As a preferred technical solution, the difference comparison module is specifically used for:

[0047] Traversing the JSON data parsed by different development languages ​​in a recursive or iterative manner, extracting features of all field information in the JSON data parsed by the different development languages; wherein the features include field name, field path, field type and field value;

[0048] Using a string edit distance algorithm to calculate the difference between the field names in the JSON data parsed by different development languages, and obtaining the field name difference results of the JSON data parsed by different development languages;

[0049] Analyze the structure and depth of the field path in the JSON data parsed by the different development languages ​​to obtain the difference results between the paths in the JSON data parsed by the different development languages;

[0050] Comparing the differences in the field types in the JSON data parsed by the different development languages ​​through type mapping and type hierarchy to obtain field type difference results of the JSON data parsed by the different development languages;

[0051] Manhattan distance is used to calculate the distance between the field values ​​in the JSON data parsed by different development languages, and the field value difference results of the JSON data parsed by different development languages ​​are obtained.

[0052] As a preferred technical solution, it also includes a difference reporting module, which is used to:

[0053] Generate a difference report based on the difference results, highlight the difference parts through the interface, and send an early warning notification;

[0054] The difference report includes recording the difference field information name, difference degree and improvement suggestions.

[0055] In a third aspect, the present application provides an electronic device, the electronic device comprising:

[0056] at least one processor; and,

[0057] a memory communicatively connected to the at least one processor; wherein,

[0058] The memory stores computer program instructions that can be executed by the at least one processor, and the computer program instructions are executed by the at least one processor so that the at least one processor can execute the data verification method for cross-language reconstructed code.

[0059] In a fourth aspect, the present application provides a computer-readable storage medium storing a program, which, when executed by a processor, implements the data verification method for cross-language reconstructed code.

[0060] In summary, compared with the prior art, the effective effects brought about by the technical solution provided by this application include at least:

[0061] The present application proposes a data verification method for cross-language refactoring code, which obtains input parameters of different development languages ​​configured by the user; according to the configured input parameters of different development languages, calls the interface of the corresponding language to execute the cross-language service request, and obtains the JSON data of different development languages ​​returned at the interface; parses the JSON data of different development languages ​​returned at the interface to obtain the JSON data parsed by different development languages; performs differential comparison on the JSON data parsed by different development languages ​​to obtain the difference results. The present application adopts a unified JSON data format as the medium for cross-language data exchange. By automatically parsing and differentially comparing the JSON data returned by different development languages, it can accurately identify the differences and errors in the data during cross-language transmission. This automated verification mechanism effectively avoids the human errors that may be introduced when manually comparing logs and data, and improves the accuracy and reliability of data verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0063] Figure 1 A flowchart of a data verification method for cross-language refactoring code provided by an embodiment of the present application;

[0064] Figure 2 A flowchart for checking the consistency of input parameter types of different development languages ​​provided by an embodiment of the present application;

[0065] Figure 3 A flowchart for performing differential comparison on JSON data parsed in different development languages ​​provided in one embodiment of the present application;

[0066] Figure 4 A block diagram of a data verification system for cross-language code reconstruction provided by an embodiment of the present application;

[0067] Figure 5 A structural diagram of an electronic device provided for one embodiment of the present application. DETAILED DESCRIPTION

[0068] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present application.

[0069] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments.

[0070] Different development languages ​​have differences in syntax, library functions, and data processing methods, making code refactoring and data interaction in a cross-language environment particularly complicated. Therefore, when refactoring a multi-language system, how to ensure the accuracy and consistency of data transmission between different development languages ​​becomes an urgent problem to be solved. However, traditional data verification methods are often limited to a single language environment. For example, data types, encoding methods, character set processing, etc. may differ significantly in different development languages. If these differences are not properly handled, it is very easy to cause data loss, deformation, or parsing errors during cross-language transmission, thereby affecting the overall performance and stability of the system; it is difficult to directly apply to cross-language scenarios. When code refactoring or data exchange between different programming languages ​​is required, developers usually need to frequently check program logs to ensure that the input and output of the refactored code flow meet expectations. Although this method is intuitive, it is inefficient and error-prone, which not only increases development costs, but also easily introduces errors, affecting software quality and maintenance efficiency. Especially in large systems, manual comparison of logs and data is time-consuming and labor-intensive, and it is difficult to meet the complex and changing cross-language development needs.

[0071] In order to solve the problems of low inspection efficiency and prone to errors in the existing traditional cross-language code verification methods, and difficulty in meeting the complex and changeable cross-language development needs, this application first ensures the consistency of data in the cross-language transmission process by uniformly processing the input parameters of different development languages ​​configured by the user, and calling the interface of the corresponding language to execute the service request. Then, a unified JSON data format is used as the medium for cross-language data exchange. Through automated parsing and differentiated comparison of JSON data returned by different development languages, the differences and errors in data during cross-language transmission can be accurately identified. This automated verification mechanism effectively avoids the human errors that may be introduced when manually comparing logs and data, improves the accuracy and reliability of data verification, and solves the problems of low inspection efficiency and prone to errors in traditional cross-language code verification methods.

[0072] JSON (JavaScript Object Notation) in this application refers to a lightweight data exchange format that constructs complex data structures through key-value pairs and ordered lists of values ​​(i.e., arrays), thereby achieving efficient storage and representation of data; JSON uses a language-independent text format to represent data, which is easy to read and write, as well as easy to parse and generate, facilitating data exchange or service calls between different programming languages.

[0073] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0074] See also Figure 1 In one embodiment of the present application, a data verification method for cross-language reconstructed code is provided, comprising the following steps:

[0075] S1. Obtain input parameters of different development languages ​​configured by the user.

[0076] Furthermore, different development languages ​​include but are not limited to PHP and Go, among which PHP (Hypertext Preprocessor) is an open source general-purpose scripting language suitable for web page development and can be embedded in HTML. Go (also known as Golang) is a statically typed, compiled, concurrent programming language developed by Google with garbage collection function.

[0077] Furthermore, the user can configure and input various types of parameters for different development languages ​​such as PHP and Go through a visual interface. Obtaining the input parameters of different development languages ​​configured by the user includes obtaining URL parameters, query parameters, request parameters, and request header parameters of different development languages ​​configured by the user.

[0078] The URL parameter refers to a uniform resource locator, which is the basic address of a service request and points to a Web service or API that needs to be called or interacted with. In different development language configurations, the URL points to different endpoints of the same service, or to completely different services.

[0079] The query parameters are parameters added to the end of the URL, and the parameters are separated by &.

[0080] The request parameters are additional information attached to the URL (as a query string) or sent through the HTTP request body. Request parameters can be data types such as strings, integers, floating-point numbers, Boolean values, arrays, or objects; request parameters are used to provide necessary data to the service or specify specific behavior of the request. In different development language configurations, request parameters vary to adapt to the syntax and habits of each language.

[0081] The request header parameters include metadata about the request itself, such as content type, authentication information, cache control instructions, etc.; for example, Content-Type (specifies the content encoding type when sending information to the server, such as application / json), Authorization (contains authentication information, such as Bearer Token), Accept (specifies the content type that the client can receive), etc.

[0082] Specifically, after obtaining the input parameters of different development languages ​​configured by the user, it also includes:

[0083] Check whether the types of input parameters of different development languages ​​configured by the user are consistent;

[0084] If it is detected that the types of the input parameters of the different development languages ​​configured by the user are inconsistent, a prompt message is issued through the visual interface to prompt the user to make corrections.

[0085] See also Figure 2 , check whether the types of input parameters of different development languages ​​configured by the user are consistent, the steps include:

[0086] S11. Extract type information of input parameters of different development languages.

[0087] Furthermore, parameter types include not only basic data types, but also complex data types and structures, including but not limited to:

[0088] (1) Basic data types: such as "int", "float", "string", "boolean", etc.

[0089] (2) Collection types: such as "array", "slice", "list", etc.

[0090] (3) Mapping type: such as "hashmap", "dictionary", "map", etc.

[0091] (4) Custom types: such as "struct", "class", "object", etc.

[0092] (5) Complex types: such as "JSON", "XML", etc.

[0093] S12. Map the type information of input parameters of different development languages ​​to the same type system according to the user-defined mapping rules; if there is no matching customized mapping rule, apply the predefined type mapping rule for mapping.

[0094] Furthermore, this embodiment allows users to customize parameter type mapping rules according to actual needs; that is, users can specify specific types of mapping relationships on the visual interface, such as mapping PHP's array type to Go's slice type. The system saves these customized rules to the database and applies them when performing parameter type checking to increase flexibility and meet special needs.

[0095] A set of predefined type mapping rules are also predefined in the system, which define the correspondence between common data types in different development languages. For example, PHP's string type usually corresponds to Go's string type, and PHP's int type corresponds to Go's int or int64 (depending on the context and needs of Go). In addition, in addition to the predefined type mapping rules, this embodiment can also allow users to customize parameter type mapping rules according to actual needs; that is, users can specify specific types of mapping relationships on the visual interface, and the system saves these customized rules to the database and applies these rules when performing parameter type checks.

[0096] In this embodiment, the user-defined mapping rules are first tried for mapping; if no matching custom rules are found, the predefined type mapping rules are applied for mapping. By giving priority to the user-defined mapping rules, the flexibility of type mapping is guaranteed, and the basic consistency guarantee is provided through the predefined rules, thereby meeting the diverse needs of different users.

[0097] S13. Compare and check the mapped parameter type information one by one to determine whether the parameter type information is consistent.

[0098] If any inconsistency in parameter types is found, detailed information about the inconsistency will be recorded and a prompt will be given to the user through the user interface, clearly indicating which parameter types are inconsistent and their respective type representations in the two development languages, thereby guiding the user to make corresponding corrections.

[0099] S2. According to the input parameters of different development languages ​​configured, the interface of the corresponding language is called to execute the cross-language service request, and the JSON data of different development languages ​​returned at the interface is obtained.

[0100] Further, according to the configured different development language input parameters, calling the interface of the corresponding language to execute the cross-language service request, and obtaining the JSON data of the different development languages ​​returned at the interface, the steps include:

[0101] S21. First, the interface information of different development languages ​​entered by the user through the interface or configuration file needs to be parsed. This information usually includes: the programming language to be used (such as Java, Python, Go, etc.), the service interface address corresponding to each language (i.e., URL parameters), query parameters, request parameters, and request header parameters.

[0102] S22. Based on the parsed configuration information, the system needs to construct a corresponding HTTP request, including: splicing a complete request address according to the configured interface URL and possible URL parameters;

[0103] Set the HTTP request header information, such as Content-Type, Authorization, etc., according to the configured request header parameters;

[0104] If the request method is a type that needs to send data, such as POST or PUT, the request body will be constructed according to the configuration. Among them, the POST method is mainly used to submit data to be processed to the specified resource; the PUT method is used to upload the latest content to the specified resource location. If the specified resource does not exist, the server may create a new resource based on the permission and configuration of the request. The main purpose of the PUT request is to update or replace resources.

[0105] S23. Use an appropriate HTTP client library (such as Java's HttpClient, Python's requests library, etc.) to send the constructed HTTP request to the specified interface URL.

[0106] S24. After the interface service processes the request, the interface will receive the returned JSON data in different development languages.

[0107] In addition, when calling the interface, the system will support multiple exception handling mechanisms, such as timeout, network failure, interface error and data format exception handling, to cope with various error conditions that may occur during the execution of different development language services. For abnormal conditions, the system must be able to capture and record detailed error information, and return a clear and easy-to-understand error response to the caller to help developers quickly locate the problem.

[0108] Furthermore, timeout means that the interface fails to return the expected result within the specified time range; the steps for handling timeout during calling are:

[0109] Set a reasonable timeout threshold based on the actual processing capacity and requirements of the interface;

[0110] Set the timeout for initiating an interface call request; the timeout includes the connection timeout (i.e. the maximum time required to establish a connection) and the read timeout (i.e. the maximum time required to read data from the server);

[0111] During the interface call process, if the request is not responded to within the set timeout period, it is considered a timeout exception and the user is prompted; then a retry mechanism is used to re-initiate the call request. The number of retries and the retry interval are both pre-set.

[0112] The timeout handling mechanism can prevent system resources from being occupied for a long time or waiting indefinitely. When the request processing time exceeds the preset threshold, the system can automatically interrupt the request and trigger the timeout exception handling logic, which helps to quickly release resources and avoid the system from being deadlocked due to a single request.

[0113] The steps to handle abnormal network failures are as follows:

[0114] During the call, use the try-catch block to catch any exceptions that may be thrown.

[0115] Determine whether it is a network failure by checking the type of exception caught. For example, UnknownHostException usually indicates a DNS resolution failure, while ConnectException or SocketTimeoutException indicates a connection problem or timeout;

[0116] If a network failure is detected, detailed error information will be recorded, and the user will be prompted to check the network connection and reconnect to the network.

[0117] The abnormal situation handling mechanism of network failure can enhance the fault tolerance of the system and ensure that in the case of network instability, users can be prompted to handle the situation in time to ensure stable operation of the system.

[0118] For abnormal situations of interface errors, the steps include:

[0119] Initiate an interface call, and after the call is completed, receive the response content returned by the interface; the response content includes a status code (such as an HTTP status code), a response header, and a response body.

[0120] Analyze the status code of the response to determine whether the request is successful; HTTP status codes range from 1xx to 5xx, with 2xx indicating success, 4xx indicating client error, and 5xx indicating server error. Interface errors are usually associated with 4xx and 5xx status codes;

[0121] If the status code indicates an error (i.e., non-2xx status code), parse the response body to obtain more detailed error information;

[0122] Determine the specific error type based on the error information or error code in the response body, including authentication failure, insufficient permissions, non-existent resources, incorrect request parameters, etc.

[0123] Implement the corresponding error handling logic according to the error type. For example, if the error is caused by incorrect request parameters, you need to verify the parameters on the client and prompt the user to correct them; if the error is caused by an internal problem in the server, you need to display a temporary error message to the user and retry the request.

[0124] For abnormal data format, the steps include:

[0125] After calling the interface, first receive the JSON data of the response returned by the interface;

[0126] Determine whether it is a data format exception by checking the exception type caught by the try-catch block, including checking whether the necessary fields exist and whether the field type is correct.

[0127] If the data format is abnormal, the detailed information of the data format abnormality is recorded, and the user is prompted to check the data format returned by the interface and provide debugging information.

[0128] The data format exception handling mechanism can improve the system's data parsing capabilities and fault tolerance, ensuring that the system can receive and process data in various formats.

[0129] The exception handling mechanism in this embodiment provides comprehensive error response capabilities for the interface service, which can not only reduce the risk of system crashes due to errors, but also improve the stability and reliability of the system. At the same time, by providing detailed error records and prompts, it provides developers with a basis for troubleshooting, helps quickly locate the root cause of the problem, and helps track problems and improve user experience.

[0130] S3. Parse the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages.

[0131] Furthermore, when services or APIs written in different development languages ​​(such as Python, Go, Java, etc.) communicate with each other, the use of JSON data format becomes particularly common. Therefore, in order to effectively use these data within these services, in this embodiment, it is necessary to parse JSON data in different development languages; parsing JSON data in different development languages ​​means using the selected parsing library to convert JSON strings into operable objects or data structures, which is a key step in realizing cross-language data interaction.

[0132] Convert JSON data in different development languages ​​to operable objects or data structures using the selected parsing library. The steps include:

[0133] Call the parsing function of the parsing library and pass in the JSON string as a parameter;

[0134] The parsing function converts each element in the string into a corresponding data structure within the programming language (such as a Python dictionary, a Go map, etc.) according to the JSON format specifications; this data structure accurately reflects the content of the original JSON data; the data structure can be traversed, modified, or further processed as needed.

[0135] S4. Perform differential comparison on the JSON data parsed by the different development languages ​​to obtain differential results.

[0136] For further information, see Figure 3 , perform differential comparison on JSON data parsed by different development languages ​​to obtain differential results, the steps include:

[0137] S41. Use a recursive or iterative method to traverse the JSON data parsed by different development languages, and extract the features of all field information in the JSON data parsed by the different development languages; wherein the features include field name, field path, field type and field value.

[0138] Further, recursively traverse the JSON data parsed by different development languages ​​to extract features of all field information in the JSON data parsed by different development languages, the steps of which include:

[0139] (1) Define a recursive function that receives at least two parameters: the current JSON node to be processed (the node can be a JSON object, a JSON array, a basic data type value, or null) and the path of the current field (for the root node, the path can be an empty string or a predefined start tag);

[0140] (2) Inside the recursive function, first check whether the current node is a basic case, that is, whether it is a basic data type value (such as a string, number, Boolean value) or null. If so, extract the field name, field path, field type, and field value of the node and record them in the preset data structure;

[0141] (3) If the current node is a JSON object, traverse all key-value pairs of the object. For each key-value pair, use the key as the field name, combine the current path with the key name to form a new field path, and use the value as a new node to be processed. Recursively call the recursive function, passing in the new field path and the node to be processed as parameters to extract and record the features of the key-value pair;

[0142] (4) If the current node is a JSON array, traverse each element in the array. For each element in the array, use its index (or some identifier) ​​to combine with the current path to form a new field path, and the element itself is used as a new node to be processed. Similarly, recursively call the recursive function, passing in the new field path and the node to be processed as parameters to extract and record the features of the array element;

[0143] (5) When the recursive function has processed all child nodes of the current node and there are no more child nodes to be processed, the recursive call will return layer by layer to the initial call point; at this time, the features of all field information have been extracted and recorded in the preset data structure.

[0144] The steps of iterating through the JSON data parsed by different development languages ​​and extracting the features of all field information in the JSON data parsed by different development languages ​​include:

[0145] 1) Receive the parsed JSON data as input, initialize an empty data structure (such as a list, queue, or custom collection) to store the extracted features, and initialize a variable (such as a string or path object) for tracking the current traversal path. Initially, the variable represents the root path;

[0146] 2) Use an iteration control structure (such as a for loop, while loop, or iterator) to traverse all elements of the parsed JSON data. Execute the corresponding processing logic according to the type of element currently traversed (object, array, basic data type value, or null);

[0147] 3) If the current element is a basic data type value (such as a string, number, Boolean value) or null, extract its field name, the current path as the field path, the element type as the field type, and the element value as the field value, and add them to the initialized data structure;

[0148] 4) If the current element is a JSON object, iterate through all key-value pairs of the object; for each key-value pair, use the key as the field name, combine the current path with the key name to form a new field path, and use the value as the next element to be processed. Iteratively process the value, i.e., repeat steps 2) to 4) in the inner iteration loop, but use the new field path and the value to be processed as the current context;

[0149] 5) If the current element is a JSON array, iterate through each element in the array; for each element in the array, use its index (or some kind of identifier) ​​combined with the current path to form a new field path, and the element itself is the next element to be processed; similarly, repeat steps 2) to 4) in the inner iteration loop, but iterate the array elements;

[0150] 6) When the iteration control structure completes traversal of all elements and there are no more elements to be processed, the iteration process ends.

[0151] S42. Calculate the difference between the field names in the JSON data parsed by different development languages ​​using a string edit distance algorithm to obtain a field name difference result of the JSON data parsed by different development languages.

[0152] Further, the string edit distance algorithm is the Levenshtein distance (also called edit distance), which evaluates the similarity between two strings by calculating the minimum number of single-character edits (insertion, deletion, or substitution) required to convert from one string to another; its steps include:

[0153] Traverse all field names in JSON data parsed by different development languages;

[0154] For each pair of field names, the difference between them is calculated using the Levenshtein distance algorithm, which considers all possible single-character edit operations and finds the minimum number of operations required to transform one field name into another.

[0155] The difference between field names is evaluated based on the calculated edit distance. The smaller the edit distance, the more similar the two field names are; conversely, the larger the edit distance, the greater the difference.

[0156] S43, analyzing the structure and depth of the field path in the JSON data parsed by the different development languages, and obtaining the difference results between the paths in the JSON data parsed by the different development languages; the steps include:

[0157] Parse a field path (such as "abc") into a list of components (such as ["a", "b", "c"]);

[0158] Compare the lengths of the two paths (i.e., the number of components); the length of the path directly reflects the depth of the JSON data structure; if the two paths have the same length, it means that the field paths of different development languages ​​point to data structures of the same or similar depth; if the lengths are different, the field paths of different development languages ​​point to structures of different depths or there is an incomplete match;

[0159] Traverse the component lists of the two paths and compare the corresponding components one by one;

[0160] If the components at a certain position are the same, continue to compare the next component; if the components at a certain position are different, record the difference point and its position;

[0161] If one path is a prefix of another path (i.e., one path is a subpath of another path), it means that the JSON data parsed by different development languages ​​have an inclusion relationship at a certain level, but the subsequent structures are different, and this incomplete match is recorded;

[0162] If the paths in the JSON data parsed by different development languages ​​do not have a common prefix, they point to completely different parts of the data structure, which indicates that the JSON objects of different development languages ​​​​do not have much similarity as a whole, or the data points they focus on are completely different.

[0163] S44, comparing the differences in the field types in the JSON data parsed by the different development languages ​​through type mapping and type hierarchy, to obtain field type difference results of the JSON data parsed by the different development languages; the steps include:

[0164] Create a type mapping table to map types in different development languages ​​into a unified type system to eliminate confusion caused by differences in type naming and classification in different development languages; for example, map integers and floating-point numbers to the "numeric" type, map Boolean values ​​to the "boolean" type, and map strings to the "string" type.

[0165] If the type system has a hierarchy (such as class inheritance in object-oriented programming), define this hierarchy;

[0166] Traverse all fields in the JSON data structure parsed by different development languages ​​and obtain the types of all fields;

[0167] Use the type mapping table to convert the field type to a type in a unified type system;

[0168] If a type hierarchy is used, the similarity of types is compared based on the hierarchy. For example, if a field is identified as "integer" in one development language and "numeric" in another development language, the two fields can be considered similar in type because "integer" is a subset of "numeric";

[0169] If the type of a field in different development languages ​​is not the same in the unified type system and is not found through the type hierarchy, this type difference is recorded.

[0170] S45, using Manhattan distance to calculate the distance between the field values ​​in the JSON data parsed by different development languages, to obtain the field value difference results of the JSON data parsed by different development languages; the steps include:

[0171] Define the distance function: For two field values ​​A and B (assuming they are both numeric vectors or arrays), the Manhattan distance D can be calculated by the following formula:

[0172]

[0173] where n is the length of the numeric vector or array; A i and B i They are the i-th elements in field value A and field value B respectively.

[0174] Traverse all elements of the two field values, perform subtraction operations on each pair of corresponding elements, then take the absolute value, and finally add all these absolute values ​​to get the total distance; the smaller the total distance, the more similar the two field values ​​are; the larger the total distance, the more significant the difference between the two field values.

[0175] The difference in field values ​​and the degree of difference are determined based on the total distance.

[0176] In this embodiment, a differential comparison of field information is performed on JSON data parsed by different development languages. After the difference results are obtained, a difference report is generated based on the difference results. The difference report records the information name of each difference field in detail to ensure that relevant personnel can quickly locate the source of the problem without blindly searching in massive data, thereby providing clear goals and directions for subsequent repair work. The difference report also introduces a quantitative assessment of the degree of difference, which helps relevant personnel quickly judge the urgency and importance of the difference by defining clear difference levels (such as minor, moderate, and severe).

[0177] In addition to recording the difference field information and the degree of difference, the difference report also combines historical data and rules to provide optimization or improvement suggestions. Improvement suggestions are based on the analysis of the causes of the differences and the matching of the existing knowledge base, aiming to provide developers and data managers with practical solutions. Improvement suggestions cover multiple aspects such as data cleaning rule adjustment, field mapping correction, and data synchronization process optimization, aiming to fundamentally solve data difference problems and improve data quality and consistency; for example, it is recommended to remove redundant fields in the return value of a certain language, or add corresponding fields in the return value of another language.

[0178] In order to make the difference information more intuitive and easy to understand, the difference parts are directly displayed in the relevant JSON data view or data structure through the interface highlighting method; this visual enhancement not only improves the efficiency of data review, but also reduces the risk of misjudgment and omission; in addition, an early warning notification mechanism is designed. When the difference comparison is completed, the system will automatically generate an early warning notification and send it to relevant personnel through multiple channels such as email and instant messaging tools. The early warning notification contains a summary and key information of the difference report, reminding the recipient to pay attention to and deal with data difference issues, which helps to ensure that the problem is responded to and effectively resolved in a timely manner.

[0179] In summary, the present application proposes a data verification method for cross-language reconstructed code. The present application first ensures the consistency of data during cross-language transmission by uniformly processing the input parameters of different development languages ​​configured by the user and calling the interface of the corresponding language to execute the service request; this effectively avoids data loss, deformation or parsing errors caused by language differences, thereby improving the overall reliability and stability of the software system. Secondly, through the automated data verification mechanism, problems in cross-language data transmission can be discovered in a timely manner, reducing the error repair work caused by data inconsistency, reducing the maintenance cost of the system, and solving the problems of low inspection efficiency and easy errors in traditional cross-language code verification methods.

[0180] It should be noted that, for the sake of convenience of description, the aforementioned method embodiments are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited to the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously.

[0181] Based on the same idea as the data verification method for cross-language reconstructed code in the above embodiment, the present application also provides a data verification system for cross-language reconstructed code, which can be used to execute the above data verification method for cross-language reconstructed code. For ease of explanation, the structural diagram of an embodiment of a data verification system for cross-language reconstructed code only shows the parts related to the embodiment of the present application. Those skilled in the art can understand that the illustrated structure does not constitute a limitation on the system, and may include more or fewer components than shown in the diagram, or combine certain components, or arrange the components differently.

[0182] See also Figure 4 In another embodiment of the present application, a data verification system for cross-language reconstructed code is provided, the system comprising a parameter acquisition module 101, a call interface module 102, a data parsing module 103 and a difference comparison module 104;

[0183] The parameter acquisition module 101 is used to acquire input parameters of different development languages ​​configured by the user;

[0184] The calling interface module 102 is used to call the interface of the corresponding language to execute the cross-language service request according to the configured different development language input parameters, and obtain the JSON data of the different development languages ​​returned at the interface;

[0185] The data parsing module 103 is used to parse the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages;

[0186] The difference comparison module 104 is used to perform a difference comparison on the JSON data parsed by the different development languages ​​to obtain a difference result.

[0187] As a preferred technical solution, the parameter acquisition module 101 is specifically used for:

[0188] The obtaining of input parameters of different development languages ​​configured by the user includes obtaining URL parameters, query parameters, request parameters and request header parameters of different development languages ​​configured by the user.

[0189] As a preferred technical solution, the parameter acquisition module 101 further includes a consistency check submodule, and the consistency check submodule is used to:

[0190] Check whether the types of input parameters of different development languages ​​configured by the user are consistent;

[0191] If it is detected that the types of the input parameters of the different development languages ​​configured by the user are inconsistent, a prompt message is issued to prompt the user to make corrections.

[0192] As a preferred technical solution, the consistency check submodule is further specifically used for:

[0193] Extract type information of input parameters of different development languages;

[0194] According to the user-defined mapping rules, the type information of input parameters of different development languages ​​is mapped to the same type system; if there is no matching custom mapping rule, the predefined type mapping rule is applied for mapping;

[0195] The mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent.

[0196] As a preferred technical solution, the data parsing module 103 is specifically used for:

[0197] Convert the JSON data in the different development languages ​​into operable objects or data structures.

[0198] As a preferred technical solution, the difference comparison module 104 is specifically used for:

[0199] Traversing the JSON data parsed by different development languages ​​in a recursive or iterative manner, extracting features of all field information in the JSON data parsed by the different development languages; wherein the features include field name, field path, field type and field value;

[0200] Using a string edit distance algorithm to calculate the difference between the field names in the JSON data parsed by different development languages, and obtaining the field name difference results of the JSON data parsed by different development languages;

[0201] Analyze the structure and depth of the field path in the JSON data parsed by the different development languages ​​to obtain the difference results between the paths in the JSON data parsed by the different development languages;

[0202] Comparing the differences in the field types in the JSON data parsed by the different development languages ​​through type mapping and type hierarchy to obtain field type difference results of the JSON data parsed by the different development languages;

[0203] Manhattan distance is used to calculate the distance between the field values ​​in the JSON data parsed by different development languages, and the field value difference results of the JSON data parsed by different development languages ​​are obtained.

[0204] As a preferred technical solution, it also includes a difference reporting module, which is used to:

[0205] Generate a difference report based on the difference results, highlight the difference parts through the interface, and send an early warning notification;

[0206] The difference report includes recording the difference field information name, difference degree and improvement suggestions.

[0207] It should be noted that a data verification system for cross-language reconstructed code of the present application corresponds one-to-one to a data verification method for cross-language reconstructed code of the present application. The technical features and beneficial effects described in the embodiment of the above-mentioned data verification method for cross-language reconstructed code are applicable to the embodiment of a data verification system for cross-language reconstructed code. For specific contents, please refer to the description in the embodiment of the method of the present application, which will not be repeated here. This is hereby declared.

[0208] In addition, in the implementation of a data verification system for cross-language reconstructed codes in the above-mentioned embodiment, the logical division of each program module is only an example. In actual applications, the above-mentioned functions can be assigned to different program modules as needed, for example, for the configuration requirements of the corresponding hardware or the convenience of software implementation. That is, the internal structure of the data verification system for cross-language reconstructed codes is divided into different program modules to complete all or part of the functions described above.

[0209] See also Figure 5 In another embodiment, an electronic device for a data verification method for cross-language reconstructed code is provided, including a processor, a memory, and a bus, and may also include a computer program stored in the memory and executable on the processor.

[0210] Exemplarily, in this embodiment, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present application. The one or more module elements may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program in the device.

[0211] The electronic device may be a computing device such as a desktop computer, a notebook, a palm computer, a cloud server, etc. The device may include, but is not limited to, a processor and a memory.

[0212] In some embodiments, the processor may be composed of an integrated circuit, for example, a single packaged integrated circuit, or a plurality of packaged integrated circuits with the same or different functions, including one or more central processing units (CPUs), other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center (Control Unit) of the device, and uses various interfaces and lines to connect the various components of the entire device; by running or executing the program or module stored in the memory, and calling the data stored in the memory, the various functions of the electronic device and the processing data are executed.

[0213] The memory can be used to store the computer program and / or module, and the processor realizes various functions of the device by running or executing the computer program and / or module stored in the memory, and calling the data stored in the memory. The memory can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function, etc.; in addition, the memory can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (Secure Digital, SD) card, a flash card (Flash Card), at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0214] Wherein, the memory may be an internal storage unit of an electronic device in some embodiments, such as a mobile hard disk of the electronic device. The memory may also be an external storage device of an electronic device in other embodiments, such as a plug-in mobile hard disk, a smart memory card (Smart Media Card, SMC), a secure digital (SecureDigital, SD) card, a flash card (Flash Card), etc. equipped on the electronic device. Furthermore, the memory may also include both an internal storage unit of the electronic device and an external storage device. The memory may be used not only to store application software and various types of data installed in the electronic device, such as the code of a data verification program for cross-language reconstruction code, but also to temporarily store data that has been output or is to be output.

[0215] Figure 5 Only an electronic device with components is shown, and those skilled in the art will understand that Figure 5 The structure shown does not constitute a limitation on the electronic device, and may include fewer or more components than shown in the figure, or combine certain components, or arrange the components differently.

[0216] The data verification program for cross-language reconstructed code stored in the memory of the electronic device is a combination of multiple instructions, which, when executed in the processor, can achieve:

[0217] Get the input parameters of different development languages ​​configured by the user;

[0218] According to the input parameters of different development languages ​​configured, the interface of the corresponding language is called to execute the cross-language service request, and the JSON data of different development languages ​​returned at the interface is obtained;

[0219] Parsing the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages;

[0220] The JSON data parsed by the different development languages ​​are differentially compared to obtain differential results.

[0221] Accordingly, the present application also provides a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute a data verification method for cross-language reconstructed code as described in any one of the above embodiments.

[0222] The computer program includes computer program code, which may be in source code form, object code form, executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), flash memory, mobile hard disk, multimedia card, card-type memory (e.g., SD or DX memory, etc.), magnetic memory, magnetic disk, optical disk, etc.

[0223] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0224] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0225] The above embodiments are preferred implementation modes of the present application, but the implementation modes of the present application are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present application should be equivalent replacement methods and are included in the protection scope of the present application.

Claims

1. A data verification method for cross-language refactoring code, characterized in that: The steps include: Get the input parameters of different development languages ​​configured by the user; According to the input parameters of different development languages ​​configured, the interface of the corresponding language is called to execute the cross-language service request, and the JSON data of different development languages ​​returned at the interface is obtained; Parsing the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages; The JSON data parsed by the different development languages ​​are differentially compared to obtain differential results.

2. According to the data verification method of cross-language reconstructed code according to claim 1, it is characterized in that: The obtaining of input parameters of different development languages ​​configured by the user includes obtaining URL parameters, query parameters, request parameters and request header parameters of different development languages ​​configured by the user.

3. According to the data verification method of cross-language reconstructed code according to claim 1, it is characterized in that: After obtaining the input parameters of different development languages ​​configured by the user, the method further includes: Check whether the types of input parameters of different development languages ​​configured by the user are consistent; If it is detected that the types of the input parameters of the different development languages ​​configured by the user are inconsistent, a prompt message is issued to prompt the user to make corrections.

4. According to the data verification method of cross-language reconstructed code according to claim 3, it is characterized in that: The checking whether the types of input parameters of different development languages ​​configured by the user are consistent includes: Extract type information of input parameters of different development languages; According to the user-defined mapping rules, the type information of input parameters of different development languages ​​is mapped to the same type system; if there is no matching custom mapping rule, the predefined type mapping rule is applied for mapping; The mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent.

5. According to the data verification method of cross-language reconstructed code according to claim 1, it is characterized in that: The parsing of the JSON data in different development languages ​​returned from the interface includes: Convert the JSON data in the different development languages ​​into operable objects or data structures.

6. According to the data verification method of cross-language reconstructed code according to claim 1, it is characterized in that: The differential comparison of the JSON data parsed by the different development languages ​​to obtain the difference results includes: Traversing the JSON data parsed by different development languages ​​in a recursive or iterative manner, extracting features of all field information in the JSON data parsed by the different development languages; wherein the features include field name, field path, field type and field value; Using a string edit distance algorithm to calculate the difference between the field names in the JSON data parsed by different development languages, and obtaining the field name difference results of the JSON data parsed by different development languages; Analyze the structure and depth of the field path in the JSON data parsed by the different development languages ​​to obtain the difference results between the paths in the JSON data parsed by the different development languages; Comparing the differences in the field types in the JSON data parsed by the different development languages ​​through type mapping and type hierarchy to obtain field type difference results of the JSON data parsed by the different development languages; Manhattan distance is used to calculate the distance between the field values ​​in the JSON data parsed by different development languages, and the field value difference results of the JSON data parsed by different development languages ​​are obtained.

7. According to the data verification method of cross-language reconstructed code according to claim 1, it is characterized in that: After performing differential comparison of field information on the JSON data parsed by the different development languages ​​and obtaining the difference results, the method further includes: Generate a difference report based on the difference results, highlight the difference parts through the interface, and send an early warning notification; The difference report includes recording the difference field information name, difference degree and improvement suggestions.

8. A data verification system for cross-language refactoring code, characterized in that: A data verification method for cross-language reconstructed code applied to any one of claims 1 to 7, comprising a parameter acquisition module, a call interface module, a data parsing module, and a difference comparison module; The parameter acquisition module is used to acquire input parameters of different development languages ​​configured by the user; The calling interface module is used to call the interface of the corresponding language to execute the cross-language service request according to the input parameters of the different development languages ​​configured, and obtain the JSON data of the different development languages ​​returned at the interface; The data parsing module is used to parse the JSON data in different development languages ​​returned from the interface to obtain the JSON data parsed in different development languages; The difference comparison module is used to perform a difference comparison on the JSON data parsed by the different development languages ​​to obtain a difference result.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores computer program instructions that can be executed by the at least one processor, and the computer program instructions are executed by the at least one processor so that the at least one processor can execute the data verification method for cross-language reconstructed code as described in any one of claims 1-7.

10. A computer-readable storage medium storing a program, characterized in that: When the program is executed by a processor, a data verification method for cross-language reconstructed code according to any one of claims 1 to 7 is implemented.

Images