A data verification method, system, device and medium for cross-language refactoring code

Abstract

The application discloses a data verification method, system and device for cross-language reconstruction of code and a medium. The method comprises the following steps: obtaining input parameters of different development languages configured by a user; calling an interface of a corresponding language to execute a cross-language service request according to the configured input parameters of different development languages, and obtaining JSON data of different development languages returned at the interface; parsing the JSON data of different development languages returned at the interface to obtain parsed JSON data of different development languages; and performing differential comparison on the parsed JSON data of different development languages to obtain a difference result. The application automatically processes a data verification process between different development languages, thereby significantly reducing the workload of a developer in manually writing conversion and verification codes. Meanwhile, the application effectively avoids human errors possibly introduced when logs and data are manually compared, and improves the accuracy and reliability of data verification.

Description

TECHNICAL FIELD

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

[0002] In the field of software development, cross-language programming has become a common and necessary requirement. Due to the differences in syntax, library functions and data processing methods of different development languages, code refactoring and data interaction in a cross-language environment become 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 efficiently and accurately process data from multiple languages.

[0003] However, traditional data verification methods are often limited to a single language environment and cannot be directly applied to cross-language scenarios. When code refactoring or data exchange between different programming languages is required, developers often need to frequently check program logs to ensure that the input and output of the refactored code flow meet expectations. This method, although intuitive, has the problems of low efficiency and easy errors, which not only increases development costs but also easily introduces errors, affecting software quality and maintenance efficiency. Especially in large systems, manually comparing logs and data is time-consuming and laborious, and it is difficult to meet the complex and changing cross-language development needs. SUMMARY

[0004] The main purpose of the present 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 refactoring code. By automatically processing the data verification process between different development languages, the workload of manually writing conversion and verification code by developers is significantly reduced. At the same time, human errors that may be introduced when manually comparing logs and data are effectively avoided, improving the accuracy and reliability of data verification.

[0005] In order to achieve the above purpose, the present application adopts the following technical scheme:

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

[0007] Obtaining input parameters of different development languages configured by a user;

[0008] 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 different development languages returned at the interface;

[0009] Parsing the JSON data of different development languages returned at the interface to obtain the parsed JSON data of different development languages;

[0010] The parsed JSON data in different development languages is compared to obtain a difference result.

[0011] As a preferred technical solution, the input parameters in different development languages configured by the user include URL parameters, query parameters, request parameters, and request header parameters configured by the user.

[0012] As a preferred technical solution, after the input parameters in different development languages configured by the user are obtained, the method further includes:

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

[0014] If it is found that the types of the input parameters in different development languages configured by the user are inconsistent, a prompt message is sent to prompt the user to correct.

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

[0016] extracting type information of the input parameters in different development languages;

[0017] mapping the type information of the input parameters in different development languages to the same type system according to a mapping rule defined by the user, and if there is no matching mapping rule defined by the user, applying a predefined type mapping rule to perform 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 at the interface includes:

[0020] The JSON data in different development languages is converted into an operable object or data structure.

[0021] As a preferred technical solution, the comparison of the parsed JSON data in different development languages to obtain a difference result includes:

[0022] The parsed JSON data in different development languages is traversed using a recursive or iterative manner to extract features of all field information in the parsed JSON data in different development languages, wherein the features include a field name, a field path, a field type, and a field value.

[0023] The string edit distance algorithm is used to calculate the difference between the field names in the JSON data parsed by different development languages, to obtain the field name difference result of the JSON data parsed by different development languages.

[0024] The structure and depth of the field path in the JSON data parsed by different development languages are analyzed to obtain the difference result between the paths in the JSON data parsed by different development languages.

[0025] The type mapping and type hierarchy are used to compare the difference of the field types in the JSON data parsed by different development languages, to obtain the field type difference result of the JSON data parsed by different development languages.

[0026] The Manhattan distance is used to calculate the distance between the field values in the JSON data parsed by different development languages, to obtain the field value difference result of the JSON data parsed by different development languages.

[0027] As a preferred technical solution, after the difference comparison of the field information of the JSON data parsed by different development languages is performed to obtain the difference result, the method further includes:

[0028] A difference report is generated according to the difference result, and the difference part is highlighted through an interface, and a warning notification is sent.

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

[0030] In a second aspect, the application provides a data verification system for cross-language refactoring code, which is applied to the data verification method for cross-language refactoring code, and includes an acquisition parameter module, a calling interface module, a data analysis module, and a difference comparison module.

[0031] The acquisition parameter module is configured to acquire input parameters of different development languages configured by a user.

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

[0033] The data analysis module is configured to analyze the JSON data of different development languages returned at the interface, to obtain JSON data parsed by different development languages.

[0034] The difference comparison module is configured to compare the JSON data parsed by different development languages, to obtain a difference result.

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

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

[0037] As a preferred technical solution, the acquisition parameter module further includes a consistency checking submodule, which is used for:

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

[0039] If it is found that the types of the input parameters of different development languages configured by the user are inconsistent, a prompt information is sent to prompt the user to correct.

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

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

[0042] mapping the type information of the input parameters of different development languages to the same type system according to a mapping rule defined by the user, and if there is no matching mapping rule defined by the user, a pre-defined type mapping rule is used for mapping;

[0043] comparing the mapped parameter type information one by one to determine whether the parameter type information is consistent.

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

[0045] converting the JSON data of different development languages into operable objects or data structures.

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

[0047] using a recursive or iterative manner to traverse the parsed JSON data of different development languages, and extracting features of all field information in the parsed JSON data of 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 parsed JSON data of different development languages, to obtain a field name difference result of the parsed JSON data of different development languages;

[0049] analyze the structure and depth of the field paths in the JSON data parsed by the different development languages, to obtain a difference result between the paths in the JSON data parsed by the different development languages;

[0050] compare the differences in the field types in the JSON data parsed by the different development languages through type mapping and type hierarchy, to obtain a field type difference result of the JSON data parsed by the different development languages;

[0051] calculate the distances between the field values in the JSON data parsed by the different development languages using Manhattan distance, to obtain a field value difference result of the JSON data parsed by the different development languages.

[0052] As a preferred technical solution, the method further comprises a difference report module, which is configured to:

[0053] generate a difference report according to the difference result, highlight the difference part through an interface, and send an early warning notification;

[0054] The difference report comprises a record difference field information name, a difference degree, and an improvement suggestion.

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

[0056] at least one processor; and

[0057] a memory connected in communication with the at least one processor; wherein

[0058] The memory stores computer program instructions executable by the at least one processor, and the computer program instructions are executed by the at least one processor to enable the at least one processor to 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, and the program is executed by a processor to implement the data verification method for cross-language reconstructed code.

[0060] In summary, compared with the prior art, the technical solution provided by the present application has at least the following effective effects:

[0061] The application provides a data checking method for cross-language reconstruction code, obtains input parameters of different development languages configured by a user; according to the configured input parameters of different development languages, an interface of a corresponding language is called to execute a cross-language service request, and JSON data of different development languages returned at the interface is obtained; the JSON data of different development languages returned at the interface is parsed to obtain parsed JSON data of different development languages; and the parsed JSON data of different development languages is compared in different manners to obtain a difference result. The application uses a unified JSON data format as a medium for cross-language data exchange, and through automatic parsing and different comparison of the JSON data returned by different development languages, the difference and error of data in the cross-language transmission process can be accurately identified, the automatic checking mechanism effectively avoids human errors possibly introduced when logs and data are manually compared, and the accuracy and reliability of data checking are improved. BRIEF DESCRIPTION OF DRAWINGS

[0062] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0063] Figure 1 A flowchart of a data checking method for cross-language reconstruction code provided by an embodiment of the present application is shown in FIG. 1.

[0064] Figure 2 A flowchart of checking the consistency of input parameter types of different development languages provided by an embodiment of the present application is shown in FIG. 2.

[0065] Figure 3 A flowchart of differentiating and comparing the parsed JSON data of different development languages provided by an embodiment of the present application is shown in FIG. 3.

[0066] Figure 4 A block diagram of a data checking system for cross-language reconstruction code provided by an embodiment of the present application is shown in FIG. 4.

[0067] Figure 5 A structural diagram of an electronic device provided by an embodiment of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0068] In the following, the technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application, so that those skilled in the art can better understand the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work belong to the scope of protection of the present application.

[0069] Reference to "embodiments" in this application means that the particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The appearance of the phrase in various places in the specification does not necessarily all refer to the same embodiment, nor does it necessarily exclude other embodiments although it can. It is explicitly and implicitly understood that the embodiments described in the present application can be combined with each other.

[0070] Different development languages differ in syntax, library functions, and data processing methods, making code refactoring and data interaction in a cross-language environment particularly complex. Therefore, when refactoring involves a multi-language system, how to ensure the accuracy and consistency of data transmission between different development languages becomes a problem to be solved. However, traditional data verification methods are often limited to a single language environment. For example, data types, encoding methods, and character set processing may differ significantly between different development languages. If these differences are not properly handled, they can easily lead to data loss, distortion, or parsing errors during cross-language transmission, thereby affecting the overall performance and stability of the system; it is difficult to apply directly to cross-language scenarios. When code refactoring or data exchange between different programming languages is required, developers often need to frequently check program logs to ensure that the input and output of the refactored code flow meet expectations. This method, although intuitive, has the problems of low efficiency and easy errors, which not only increases development costs but also easily introduces errors, affecting software quality and maintenance efficiency. Especially in large systems, manually comparing logs and data is time-consuming and laborious, and it is difficult to meet the complex and varied cross-language development needs.

[0071] To solve the problems of low efficiency and error-prone in the existing traditional cross-language code verification method, the present application first processes different development language input parameters configured by the user uniformly, and calls the interface of the corresponding language to execute the service request, ensuring the consistency of data in the cross-language transmission process. Then, a unified JSON data format is used as the medium for cross-language data exchange, and by automatically parsing and differentiating the JSON data returned by different development languages, the differences and errors in the cross-language transmission process can be accurately identified. This automated verification mechanism effectively avoids human errors that may be introduced when manually comparing logs and data, improving the accuracy and reliability of data verification; and solves the problems of low efficiency and error-prone in the traditional cross-language code verification method.

[0072] The JSON (JavaScript Object Notation) in the present application refers to a lightweight data exchange format that builds complex data structures through key-value pairs and ordered value lists (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, and also easy to parse and generate, facilitating data exchange or service invocation between different programming languages.

[0073] The technical solutions provided by the embodiments in the present specification will be described in detail below with reference to the accompanying drawings.

[0074] Please refer to Figure 1 In an embodiment of the present application, a cross-language refactoring code data verification method is provided, comprising the following steps:

[0075] S1, obtaining input parameters of different development languages configured by the user.

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

[0077] Further, the user can configure multiple types of parameters for PHP and Go through a visual interface. Obtaining the input parameters of different development languages configured by the user includes obtaining the 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 a 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 points to completely different services.

[0079] The query parameter is a parameter appended at the end of the URL, and the parameters are separated by &.

[0080] The request parameter is additional information sent on the URL (as a query string) or through the HTTP request body. The request parameter can be a string, an integer, a floating-point number, a Boolean value, an array, or an object, etc. The request parameter is used to provide necessary data to the service or specify the specific behavior of the request. In different development language configurations, the request parameter is different to adapt to the syntax and habits of each language.

[0081] The request header parameter contains 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, the following steps are further included:

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

[0084] If it is found that the types of the input parameters of different development languages configured by the user are inconsistent, a prompt information is sent through a visual interface to prompt the user to correct.

[0085] Please refer to Figure 2 to check whether the types of the input parameters of different development languages configured by the user are consistent, and the steps include:

[0086] S11, extract the type information of the input parameters of different development languages.

[0087] Further, the parameter types not only include basic data types, but also include complex data types and structures, specifically 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 type: such as "struct", "class", "object", etc.

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

[0093] S12, according to the mapping rule defined by the user, the type information of the 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.

[0094] Further, the embodiment allows the user to customize the parameter type mapping rule according to the actual demand; that is, the user can specify the mapping relationship of a specific type on the visual interface, for example, mapping the array type of PHP to the slice type of Go. The system saves these custom rules in the database and applies these rules when performing parameter type checking to increase flexibility and meet special needs.

[0095] The system also predefines a set of predefined type mapping rules, which define the correspondence of common data types in different development languages. For example, the string type of PHP usually corresponds to the string type of Go, and the int type of PHP corresponds to the int or int64 of Go (depending on the context and needs of Go). In addition, in addition to the predefined type mapping rules, the user can also customize the parameter type mapping rule according to the actual demand in the embodiment; that is, the user can specify the mapping relationship of a specific type on the visual interface, and the system saves these custom rules in the database and applies these rules when performing parameter type checking.

[0096] In the embodiment, first, the user-defined mapping rule is tried to be applied for mapping; if no matching custom rule is found, the predefined type mapping rule is applied for mapping. By preferentially applying the user-defined mapping rule, the flexibility of type mapping is ensured, and the predefined rule provides a basic consistency guarantee, thereby meeting the diversified needs of different users.

[0097] S13, the mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent.

[0098] If it is found that there is a parameter type inconsistency, the detailed information of the inconsistency will be recorded, and a prompt will be issued to the user through the user interface, clearly indicating which parameter types are inconsistent and their type representations in the two development languages, thereby guiding the user to make the appropriate corrections.

[0099] S2, according to the configured different development language input parameters, calling the interface of the corresponding language to execute cross-language service request, and obtaining the different development language JSON data returned at the interface.

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

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

[0102] S22, based on the parsed configuration information, the system needs to build the corresponding HTTP request; including: according to the configured interface URL and possible URL parameters to splice the complete request address;

[0103] According to the configured request header parameter, set the header information of the HTTP request, such as Content-Type, Authorization, etc.

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

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

[0106] S24, after the interface service processes the request, the interface will receive the returned different development language JSON data.

[0107] In addition, the system supports multiple exception handling mechanisms when calling the interface, such as timeout, network failure, interface error, and data format exception handling, to deal with various error situations that may occur during the execution of different development language services. For abnormal situations, the system should be able to capture and record detailed error information, and return clear and easy-to-understand error responses to the caller, helping developers quickly locate problems.

[0108] Further, timeout refers to the failure of the interface to return the expected result within a specified time range. The steps for handling timeout situations during invocation are as follows:

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

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

[0111] If the request does not receive a response within the set timeout time during the interface call process, it is judged as a timeout exception situation, 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] Through the timeout exception handling mechanism, system resources can be prevented from being occupied for a long time or waiting indefinitely. When the request processing time exceeds the pre-set 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 trapped in a stalemate due to a single request.

[0113] The steps for handling network failure exceptions are as follows:

[0114] During the invocation process, use try-catch statement blocks to capture possible exceptions;

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

[0116] If it is determined to be a network failure exception, record detailed error information and prompt the user to check the network connection, and support reconnection of the network.

[0117] Through the network failure exception handling mechanism, the fault tolerance of the system can be enhanced, ensuring that in the case of unstable network, the user can be prompted in a timely manner for processing, to ensure the stable operation of the system.

[0118] For abnormal cases 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 status code (such as HTTP status code), response header, and response body.

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

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

[0122] According to the error information or error code in the response body, determine the specific error type; including authentication failure, insufficient permissions, resource does not exist, request parameter error, etc.

[0123] According to the error type, implement the corresponding error handling logic. For example, if the error is caused by request parameter error, the client needs to verify the parameters and prompt the user to correct; if the error is caused by server internal problem, a temporary error message needs to be displayed to the user, and the request needs to be retried.

[0124] For data format abnormal cases, 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 captured by the try-catch statement block, including checking whether the necessary fields exist, whether the field types are correct, etc.

[0127] If it is determined that there is a data format exception, record the detailed information of the data format exception, and prompt the user to check the data format returned by the interface, and provide debugging information.

[0128] Through the data format exception handling mechanism, the data parsing ability and fault tolerance of the system can be improved, and the system can receive and process data of various formats.

[0129] The exception handling mechanism in this embodiment provides comprehensive error handling capability for interface services, not only reducing the risk of system crashes due to errors, but also improving the stability and reliability of the system. At the same time, by providing detailed error records and prompts, developers are provided with troubleshooting basis, helping to quickly locate the problem source, which is helpful for problem tracking and user experience improvement.

[0130] S3, parsing the JSON data in different development languages returned at the interface to obtain parsed JSON data in different development languages.

[0131] Further, 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 utilize these data within these services, in the present embodiment, it is necessary to parse JSON data in different development languages; parsing JSON data in different development languages refers to converting JSON strings in different development languages into operable objects or data structures using selected parsing libraries, which is a key step for cross-language data interaction.

[0132] Converting JSON strings in different development languages into operable objects or data structures using selected parsing libraries includes the following steps:

[0133] Calling a parsing function of a parsing library and inputting a JSON string as a parameter;

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

[0135] S4, differentiating and comparing the parsed JSON data in different development languages to obtain a difference result.

[0136] Further, please refer to Figure 3 Differentiating and comparing the parsed JSON data in different development languages to obtain a difference result includes the following steps:

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

[0138] Further, using a recursive method to traverse the parsed JSON data in different development languages and extract features of all field information in the parsed JSON data in different development languages includes the following steps:

[0139] (1) define a recursive function that takes at least two arguments: the current JSON node to be processed (which can be a JSON object, a JSON array, a primitive 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 starting marker);

[0140] (2) inside the recursive function, first check if the current node is a base case, i.e., whether it is a primitive data type value (such as a string, a number, a 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, iterate through all key-value pairs of the object. For each pair of keys, take the key as the field name, combine the current path with the key name to form a new field path, and take the value as the 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 characteristics of the key-value pair;

[0142] (4) if the current node is a JSON array, iterate through each element in the array. For each element in the array, combine its index (or some identifier) with the current path to form a new field path, and take the element itself as the 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 characteristics 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, all field information characteristics have been extracted and recorded in the preset data structure.

[0144] Using an iterative approach to traverse the JSON data parsed by different development languages, the characteristics of all field information in the JSON data parsed by different development languages are extracted, and the steps 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 characteristics, and initialize a variable (such as a string or path object) to track the current traversal path, which initially represents the root path;

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

[0147] 3) If the current element is a basic data type value (such as a string, number, boolean) 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 pair, take the key as the field name, combine the current path with the key name to form a new field path, and take the value as the next element to be processed. Iteratively process the value, i.e., repeat steps 2) to 4) in an 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, combine its index (or some identifier) with the current path to form a new field path, and take the element itself as the next element to be processed; likewise, repeat steps 2) to 4) in an inner iteration loop, but iterate through the array elements for processing;

[0150] 6) When the iteration control structure completes the 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 the string edit distance algorithm, to obtain the 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 known as the edit distance), which evaluates the similarity between two strings by calculating the minimum number of single-character edits (insertions, deletions, or substitutions) required to convert one string to another; its steps include:

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

[0154] For each pair of field names, calculate the difference between them using the Levenshtein distance algorithm; in this calculation process, all possible single-character editing operations are considered, and the minimum number of operations required to convert one field name to another is found;

[0155] According to the calculated edit distance, the degree of difference between the field names is evaluated. The smaller the edit distance, the more similar the two field names; on the contrary, the larger the edit distance, the greater the difference.

[0156] S43, analyze the structure and depth of the field paths in the JSON data parsed by different development languages, and obtain the difference result between the paths in the JSON data parsed by different development languages; the steps include:

[0157] Parse the field path (such as "a.b.c") into a component list (such as ["a", "b", "c"]);

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

[0159] Traverse the component list 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 the other path (i.e. one path is a sub-path of the other path), it means that the JSON data parsed by different development languages has a containing relationship at a certain level, but the subsequent structure is different, and this incomplete match is recorded;

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

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

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

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

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

[0167] convert the field types into types in a unified type system using a type mapping table;

[0168] if a type hierarchy is used, compare the similarity of types according to the hierarchy, for example, if a field is identified as an "integer" in one development language and as a "numeric value" in another development language, it can be considered that the two fields are similar in type because "integer" is a subset of "numeric value";

[0169] if the types of fields in different development languages are not the same in the unified type system and are not found through the type hierarchy, record the type difference.

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

[0171] define a distance function: for two field values A and B (assuming they are both numerical vectors or arrays), the Manhattan distance D can be calculated by the following formula:

[0172]

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

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

[0175] determine the field value difference and its degree of difference according to the total distance.

[0176] In this embodiment, the JSON data parsed after different development languages are compared for field information differences, and after the difference results are obtained, a difference report is generated according to the difference results. In the difference report, the information name of each difference field is recorded in detail, so that relevant personnel can quickly locate the problem source without blind searching in massive data, and an explicit target and direction are provided for subsequent repair work. The difference report also introduces quantitative evaluation of the difference degree, which helps relevant personnel quickly judge the urgency and importance of the difference by defining clear difference levels (such as slight, moderate, and severe).

[0177] In addition to recording difference field information and difference degree, the difference report also provides optimization or improvement suggestions in combination with historical data and rules. The improvement suggestions are based on the analysis of the difference causes and the matching of the existing knowledge base, aiming to provide practical solutions for developers and data administrators. The improvement suggestions cover data cleaning rule adjustment, field mapping correction, data synchronization process optimization, and other aspects, aiming to fundamentally solve the data difference problem and improve data quality and consistency; for example, it is suggested to remove the 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 part is directly displayed in the related JSON data view or data structure through interface highlighting display; this visual enhancement not only improves the data review efficiency, but also reduces the risk of misjudgment and omission; in addition, a warning notification mechanism is designed, which generates a warning notification automatically after the difference comparison is completed, and sends it to relevant personnel through multiple channels such as email, instant messaging tools, etc. The warning notification contains the summary and key information of the difference report, reminding the receiver to pay attention to and handle the data difference problem, which helps to ensure that the problem is responded and solved in time.

[0179] In summary, the data verification method for cross-language code reconstruction proposed in this application first uniformly processes different development language input parameters configured by the user, and calls the interface of the corresponding language to execute the service request, ensuring the consistency of data in the cross-language transmission process; 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 automatic data verification mechanism, problems in cross-language data transmission can be found in time, reducing the error repair work caused by inconsistent data, reducing the maintenance cost of the system, and solving the problems of low verification efficiency and easy errors in the traditional cross-language code verification method.

[0180] It should be noted that for the foregoing method embodiments, for the convenience of description, they are all expressed as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the actions described, 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 checking method for cross-language code reconstruction in the above-mentioned embodiment, the present application also provides a data checking system for cross-language code reconstruction, which can be used to execute the above-mentioned data checking method for cross-language code reconstruction. For the convenience of description, in the structural schematic diagram of an embodiment of a data checking system for cross-language code reconstruction, only the parts related to the embodiments of the present application are shown, and those skilled in the art can understand that the illustrated structure does not constitute a limitation on the system, and can include more or fewer components than the illustrated, or combine certain components, or different component arrangements.

[0182] Please refer to Figure 4 In another embodiment of the present application, a data checking system for cross-language code reconstruction is provided, which includes an acquisition parameter module 101, a calling interface module 102, a data analysis module 103, and a difference comparison module 104.

[0183] The acquisition parameter module 101 is configured to acquire input parameters of different development languages configured by a user.

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

[0185] The data analysis module 103 is configured to analyze the JSON data of different development languages returned at the interface to obtain JSON data of different development languages after analysis.

[0186] The difference comparison module 104 is configured to compare the JSON data of different development languages after analysis to obtain a difference result.

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

[0188] The acquisition of the input parameters of different development languages configured by the user includes the acquisition of 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 acquisition parameter module 101 further includes a consistency checking submodule, and the consistency checking submodule is configured to:

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

[0191] If it is found that the types of input parameters of different development languages configured by the user are inconsistent, prompt information is sent to prompt the user to correct.

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

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

[0194] mapping the type information of input parameters of different development languages to the same type system according to a mapping rule defined by the user, and if there is no matching mapping rule defined by the user, applying a predefined type mapping rule for mapping;

[0195] comparing the mapped parameter type information one by one to determine whether the parameter type information is consistent.

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

[0197] converting the JSON data of 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] using a recursive or iterative manner to traverse the parsed JSON data of different development languages, and extracting features of all field information in the parsed JSON data of 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 parsed JSON data of different development languages, to obtain a field name difference result of the parsed JSON data of different development languages;

[0201] analyzing the structure and depth of the field paths in the parsed JSON data of different development languages to obtain a difference result between the paths in the parsed JSON data of different development languages;

[0202] comparing the differences of the field types in the parsed JSON data of different development languages through type mapping and type hierarchy to obtain a field type difference result of the parsed JSON data of different development languages;

[0203] The Manhattan distance is used to calculate the distance between the field values in the parsed JSON data of different development languages, to obtain a field value difference result of the parsed JSON data of different development languages.

[0204] As a preferred technical solution, the system further comprises a difference report module configured to:

[0205] generate a difference report according to the difference result, highlight the difference part through an interface, and send an early warning notification;

[0206] The difference report comprises a record difference field information name, a difference degree, and an improvement suggestion.

[0207] It should be noted that the data verification system for cross-language refactoring code of the present application corresponds to the data verification method for cross-language refactoring code of the present application. The technical features and advantages described in the embodiment of the data verification method for cross-language refactoring code are applicable to the embodiment of the data verification system for cross-language refactoring code. For specific content, please refer to the description in the method embodiment. Here, no further description is given, and this is hereby declared.

[0208] In addition, the logical division of each program module in the embodiment of the data verification system for cross-language refactoring code is only an example. In actual application, the above-mentioned functions can be completed by different program modules according to needs, for example, considering the configuration requirements of the corresponding hardware or the convenience of software implementation, to divide the internal structure of the data verification system for cross-language refactoring code into different program modules to complete all or part of the functions described above.

[0209] Please refer to Figure 5 In another embodiment, an electronic device for a data verification method for cross-language refactoring code is provided, which comprises a processor, a memory, and a bus, and can further comprise a computer program stored in the memory and executable on the processor.

[0210] For example, in this embodiment, the computer program can 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 modules can be a series of computer program instruction segments capable of completing a specific function, which are used to describe the execution process of the computer program in the device.

[0211] The electronic device can be a desktop computer, a notebook computer, a palm computer, a cloud server, and other computing devices. The device can include, but is not limited to, a processor and a memory.

[0212] The processor can be composed of integrated circuits in some embodiments, for example, can be composed of a single packaged integrated circuit, or can be composed of multiple packaged integrated circuits with the same function or different functions, including one or more central processing units (CPUs), and can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or can also be any conventional processor, etc. The processor is the control unit of the device, and is connected to various components of the entire device through various interfaces and lines; by running or executing programs or modules stored in the memory, and calling data stored in the memory, to perform various functions and process data of the electronic device.

[0213] The memory can be used to store the computer programs and / or modules, and the processor realizes various functions of the device by running or executing the computer programs and / or modules 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 nonvolatile memory, for example, a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0214] The memory can be an internal storage unit of the electronic device in some embodiments, for example, a mobile hard disk of the electronic device. The memory can also be an external storage device of the electronic device in other embodiments, for example, a plug-in mobile hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device. Further, the memory can include both the internal storage unit and the external storage device of the electronic device. The memory can be used not only to store application software and various data installed on the electronic device, for example, a code of a data verification program for cross-language code reconstruction, but also to temporarily store data that has been output or will be output.

[0215] Figure 5 Only the electronic device with components is shown, and those skilled in the art can understand that, Figure 5 The structure shown does not constitute a limitation on the electronic device, and can include fewer or more components than shown, or combine certain components, or different component arrangements.

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

[0217] Obtaining input parameters of different development languages configured by a user;

[0218] According to the configured different development language input parameters, calling an interface of a corresponding language to execute a cross-language service request, and obtaining JSON data of different development languages returned at the interface;

[0219] Parsing the JSON data of different development languages returned at the interface to obtain parsed JSON data of different development languages;

[0220] Differentially comparing the parsed JSON data of different development languages to obtain a difference result.

[0221] Correspondingly, the application also provides a computer readable storage medium including a stored computer program, wherein the computer program controls a device where the computer readable storage medium is located to execute the data verification method for cross-language code reconstruction according to any one of the above embodiments when the computer program runs.

[0222] The computer program includes computer program code, which can be in the form of source code, object code, executable code, or some intermediate form, etc. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, 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 memory (such as SD or DX memory, etc.), magnetic memory, 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 related hardware through a computer program. The program can be stored in a non-volatile computer readable storage medium, and when the program is executed, it can include the processes of the above-mentioned embodiments of the method. Any reference to memory, storage, database or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), 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), etc.

[0224] The technical features of the above embodiments can be combined in any way. In order to make the description simple, not all possible combinations of technical features in the above embodiments are described, but as long as the combination of technical features does not exist contradictory, it should be considered as the scope of the present application.

[0225] The above embodiments are the preferred embodiments of the present application, but the embodiments of the present application are not limited by the above embodiments, and any changes, modifications, substitutions, combinations, simplifications made without departing from the spirit and principles of the present application shall be equivalent replacement methods, and shall be included in the protection scope of the present application.

Claims

1. A data validation method for cross-language refactored code, characterized in that, Includes the following steps: Obtain input parameters for different programming languages ​​configured by the user, and extract the type information of the input parameters for different programming languages; Based on user-defined mapping rules, the type information of input parameters from different programming languages ​​is mapped to the same type system; if no matching user-defined mapping rules are available, predefined type mapping rules are applied. The mapped parameter type information is compared and checked one by one to determine whether the parameter type information is consistent. Based on the different development language input parameters configured, the corresponding language interface is called to execute cross-language service requests, and JSON data in different development languages ​​returned by the interface is obtained; The JSON data returned by the interface in different programming languages ​​is parsed to obtain the JSON data parsed in different programming languages. The JSON data parsed by different programming languages ​​is compared to obtain the difference results. The method involves recursively or iteratively traversing the JSON data parsed by different programming languages ​​to extract the features of all field information in the JSON data parsed by different programming languages. The features include field name, field path, field type, and field value. The differences between the field names in the JSON data parsed by different programming languages ​​are calculated using the string edit distance algorithm, and the results of the differences in field names in the JSON data parsed by different programming languages ​​are obtained. The structure and depth of the field paths in the JSON data parsed by different programming languages ​​are analyzed to obtain the differences between the field paths in the JSON data parsed by different programming languages. The differences in field types in the JSON data parsed by different programming languages ​​are compared by using type mapping and type hierarchy to obtain the results of the differences in field types in the JSON data parsed by different programming languages. The Manhattan distance is used to calculate the distance between the field values ​​in the JSON data parsed by the different programming languages, and the difference results of the field values ​​in the JSON data parsed by the different programming languages ​​are obtained.

2. The data validation method for cross-language refactoring code according to claim 1, characterized in that, The input parameters for obtaining different development languages ​​configured by the user include URL parameters, query parameters, request parameters, and request header parameters for the different development languages ​​configured by the user.

3. The data validation method for cross-language refactoring code according to claim 1, characterized in that, After obtaining the input parameters for different programming languages ​​configured by the user, the process further includes: If the user detects inconsistencies in the types of input parameters for different programming languages ​​configured by the user, a prompt message will be issued to the user to make corrections.

4. The data validation method for cross-language refactoring code according to claim 1, characterized in that, The parsing of JSON data in different programming languages ​​returned by the interface includes: Convert JSON data from the different programming languages ​​into operable objects or data structures.

5. The data validation method for cross-language refactoring code according to claim 1, characterized in that, The step of performing a differential comparison on the JSON data parsed from the different programming languages, and obtaining the difference results, further includes: A difference report is generated based on the difference results, and the difference is highlighted on the interface, and an early warning notification is sent. The difference report includes the name of the difference field, the degree of difference, and improvement suggestions.

6. A data validation system for cross-language refactored code, characterized in that, A data verification method for cross-language refactoring code applied to any one of claims 1-5 includes a parameter acquisition module, an interface calling module, a data parsing module, and a difference comparison module; The parameter acquisition module is used to acquire input parameters for different development languages ​​configured by the user. The interface calling module is used to call the corresponding language interface to execute cross-language service requests according to the different development language input parameters configured, and to obtain JSON data in different development languages ​​returned by the interface. The data parsing module is used to parse the JSON data returned by the interface in different programming languages ​​to obtain the JSON data parsed in different programming languages. The difference comparison module is used to perform a difference comparison on the JSON data parsed by the different programming languages ​​to obtain the difference results.

7. An electronic device, characterized in that, The electronic device includes: 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, which, when executed by the at least one processor, enables the at least one processor to perform a data verification method for cross-language refactoring code as described in any one of claims 1-5.

8. A computer-readable storage medium storing a program, characterized in that, When the program is executed by the processor, it implements the data verification method for cross-language refactoring code as described in any one of claims 1-5.

Images