Message verification method and device based on front-end form field, equipment and medium

Abstract

The application discloses a message verification method and device based on a front-end form field, equipment and medium, and the method comprises the following steps: intercepting the form submission event of a target front-end page, traversing the source code of the target front-end page, and obtaining original input data; based on at least two field attribute characteristics of the front-end field in the target front-end page, performing field matching on the front-end field key name in the original input data and the corresponding standard field label in a form message template; based on the label hierarchy structure of the corresponding standard field label of the form message template, performing structure hierarchy verification on the field label in the target form message generated by the form submission event; based on the field value corresponding to the front-end field key name in the original input data, performing content consistency verification on the field value corresponding to the field label in the target form message. Through the technical scheme, the accuracy of the target form message generation and the message quality are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a message verification method, apparatus, device, and medium based on front-end form fields. Background Technology

[0002] In fields such as internet services and enterprise applications, front-end form entry and back-end XML (Extensible Markup Language) message interaction in web systems is a widely adopted data transmission mode.

[0003] However, with the increasing complexity of business scenarios and the faster pace of system iteration, traditional solutions have gradually exposed many undeniable technical shortcomings: First, field mapping relies on manual maintenance, resulting in extremely poor adaptability. Traditional solutions use fixed field name mapping relationships. When front-end form fields undergo minor changes due to iteration renaming, automatic framework generation, dynamic form drag-and-drop additions, case changes, underscore additions / removals, abbreviations, etc., the mapping configuration must be manually modified. This is not only costly and error-prone, but also unsuitable for flexible scenarios such as high-frequency iterations, custom forms, and dynamic forms. Second, XML message validation has a single dimension and insufficient stability. Existing validation mechanisms mostly compare only the numerical content within XML nodes, without strictly validating XML tag names, tag levels, and node structures. This easily leads to structural problems such as tag spelling errors, missing tags, disordered tag nesting, and tag replacement, resulting in abnormal XML message formats and causing interface interaction failures, data parsing errors, and other malfunctions. Third, front-end data capture has biases, resulting in low validation reliability. Existing technologies either rely on two-way binding in the front-end framework, making it impossible to capture dynamically rendered fields; or they obtain message data by listening to network request responses, but this data includes fields such as timestamps, serial numbers, signatures, and default fill values ​​automatically generated by the backend, which cannot reflect the user's actual original input content, resulting in low data purity and easily interfered verification results. Summary of the Invention

[0004] This application provides a message verification method, apparatus, device, and storage medium based on front-end form fields to improve the accuracy of message generation and message quality.

[0005] According to one aspect of this application, a message validation method based on front-end form fields is provided, the method comprising: The form submission event of the target front-end page is intercepted, and the source code of the target front-end page is traversed to obtain the original input data; wherein, the original input data refers to the form data entered by the user in the target front-end page; Based on at least two field attribute features of the front-end fields in the target front-end page, field matching is performed between the front-end field key names in the original input data and the corresponding standard field tags in the form message template; wherein, the field attribute features include field naming features, field business type features, and field data type features; Based on the tag hierarchy structure of the standard field tags corresponding to the form message template, the structure hierarchy of the field tags in the target form message generated by the form submission event is validated. Based on the field values ​​corresponding to the front-end field keys in the original entered data, the content consistency verification is performed on the field values ​​corresponding to the field tags in the target form message.

[0006] According to another aspect of this application, a message verification device based on front-end form fields is provided, the device comprising: The raw data acquisition module is used to intercept the form submission event of the target front-end page, traverse the source code of the target front-end page, and obtain the raw input data; wherein, the raw input data refers to the form data entered by the user in the target front-end page; The field matching module is used to perform field matching between the front-end field key names in the original input data and the corresponding standard field tags in the form message template, based on at least two field attribute features of the front-end fields in the target front-end page; wherein, the field attribute features include field naming features, field business type features, and field data type features; The structure hierarchy verification module is used to perform structure hierarchy verification on the field tags in the target form message generated by the form submission event based on the tag hierarchy structure of the standard field tags corresponding to the form message template. The consistency verification module is used to perform content consistency verification on the field values ​​corresponding to the field labels in the target form message based on the field values ​​corresponding to the front-end field key names in the original entered data.

[0007] According to another aspect of this application, an electronic device is provided, the electronic device comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement any of the message verification methods based on front-end form fields provided in the embodiments of this application.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements any of the message verification methods based on front-end form fields provided in the embodiments of this application.

[0009] According to another aspect of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the message verification methods based on front-end form fields provided in the embodiments of this application.

[0010] This application solves the mismatch between frequent changes in front-end page fields and the fixed structure of the target form message by capturing the original input data, dynamically matching the original input data with the form message template, and performing structural hierarchy verification and content consistency verification. This improves the accuracy and quality of the target form message generation, as well as the degree of matching with the original input data. Attached Figure Description

[0011] Figure 1 This is a flowchart of a message verification method based on front-end form fields provided in Embodiment 1 of this application; Figure 2 This is a flowchart of a message verification method based on front-end form fields provided in Embodiment 2 of this application; Figure 3 This is a schematic diagram of a message verification device based on front-end form fields provided in Embodiment 3 of this application; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the message verification method based on front-end form fields according to Embodiment 4 of this application. Detailed Implementation

[0012] 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 with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] Example 1 Figure 1 This is a flowchart illustrating a message verification method based on front-end form fields according to Embodiment 1 of this application. This embodiment is applicable to verifying form messages generated after front-end form input in a Web system. The verification can be performed by a message verification device based on front-end form fields, which can be implemented in hardware and / or software and can be configured in a computer device, such as a server. Figure 1 As shown, the method includes: S110. Intercept the form submission event of the target front-end page, traverse the source code of the target front-end page, and obtain the original input data.

[0015] The target front-end page can refer to the front-end page where the user is currently performing data entry operations.

[0016] Raw data entered can refer to form data input by the user on the target front-end page. Optionally, form data can include data entered in form controls such as general input controls, drop-down selection controls, and multi-line text input controls.

[0017] For example, when a user fills out a form on the front-end page, the content entered by the user is stored in the browser's memory in real time. When the user clicks the submit button, an XML message is generated, sending the form data entered on the front-end page to the back-end in XML format. The back-end receives the XML message, uses an XML parsing library to convert it into a data structure that can be processed by a programming language, executes business logic, and processes the user request. During this process, the form submission event can be intercepted, and the XML message is not sent directly to the back-end after it is generated.

[0018] Optionally, the source code of the target front-end page can be traversed to obtain the original input data. This includes: traversing the source code of the target front-end page using the Document Object Model (DOM) (traversing the node tree of the HTML document using JavaScript code), obtaining the field values ​​of the user-input form fields, and using the field identifier information of the form fields as keys and the field values ​​as values ​​to determine the original input data. It should be noted that the original input data only retains the user-input form data and does not include the field content of automatically generated fields or system-default filled fields, to eliminate interference from irrelevant fields.

[0019] S120. Based on at least two field attribute features of the front-end fields in the target front-end page, perform field matching between the front-end field key names in the original input data and the corresponding standard field tags in the form message template.

[0020] Field attribute characteristics can include field naming characteristics, field business type characteristics, and field data type characteristics.

[0021] It should be noted that front-end field key names can refer to the field identifier information of form fields in the front-end page, the form message template can serve as the basis for generating back-end XML messages, and standard field tags can refer to the field identifiers defined in the form message template. Optionally, the form message template can be adapted according to those skilled in the art.

[0022] S130. Based on the tag hierarchy structure of the standard field tags corresponding to the form message template, perform structural hierarchy validation on the field tags in the target form message generated by the form submission event.

[0023] The target form message can refer to the backend XML message that needs to be sent to the backend.

[0024] It should be noted that the target form message can be generated based on the form message template. The field labels in the target form message have field values, while the field values ​​of the standard field labels in the form message template are empty.

[0025] Optionally, based on the tag hierarchy structure of the standard field tags corresponding to the form message template, a structural hierarchy verification is performed on the field tags in the target form message generated by the form submission event. This includes: after the field matching passes, traversing each standard field tag in the form message template to determine the tag hierarchy structure corresponding to each standard field tag; according to the tag hierarchy structure corresponding to the standard field tag, performing a structural hierarchy verification on the mapped field tag corresponding to the standard field tag in the target form message; if the tag hierarchy structure corresponding to the standard field tag is the same as the tag hierarchy structure of the mapped field tag, it indicates that the structural hierarchy verification passes.

[0026] Optionally, if a field fails to match, no further structural hierarchy validation is required.

[0027] The tag hierarchy can include parent tags and child tags of standard field tags. It should be noted that a parent tag can refer to the field tag of an adjacent parent node, and a child tag can refer to the field tag of an adjacent child node.

[0028] It should be noted that having the same tag hierarchy structure can mean that the standard field tag and its corresponding mapped field tag have the same tag hierarchy structure (the number of parent tags and the number of child tags are the same, and the parent tags are the same, and the child tags are also the same).

[0029] In this embodiment of the invention, the structural hierarchy verification is to ensure the legality and hierarchical consistency of the mapped field labels in the target form message relative to the form message template, and relative to the standard field labels, thereby ensuring the consistency of the data structure relationship in the target form message with that in the form message template. It should be noted that the mapped field labels can refer to the field labels in the target form message corresponding to the standard field labels in the form message template.

[0030] S140. Based on the field values ​​corresponding to the front-end field key names in the original entered data, perform content consistency verification on the field values ​​corresponding to the field labels in the target form message.

[0031] Optionally, based on the field values ​​corresponding to the front-end field keys in the original entered data, a content consistency check is performed on the field values ​​corresponding to the field labels in the target form message. This includes: after the structural hierarchy check passes, determining a matching field label for each piece of form data in the original entered data in the target form message, based on the mapping relationship between the front-end field types of the form data and the field labels in the target form message, as the field label to be checked; performing a content consistency check on the field values ​​of the matching field labels to be checked based on the data values ​​of the form data; if the data values ​​of the form data are not completely consistent with the field values ​​of the field labels to be checked, it indicates that the consistency check of the field labels to be checked has failed; if the data values ​​of the form data are completely consistent with the field values ​​of the field labels to be checked, it indicates that the consistency check of the field labels to be checked has passed.

[0032] Optionally, if the structure hierarchy check fails, there is no need to perform a content consistency check.

[0033] By first verifying the legality of the tag hierarchy structure of the target form message, and then performing a double verification on the content consistency of the field values ​​corresponding to the field tags in the target form message, the message structure is stable and the content is accurate. This can accurately distinguish between tag-type errors and numerical errors, resulting in a higher error detection rate.

[0034] It should be noted that during the above validation process, if field matching fails, the output will indicate a template field label mismatch; if the structure hierarchy validation fails, the output will indicate a target form message with a field label hierarchy error; if the content consistency validation fails, the output will indicate a target form message with a numerical error. Based on different error types, anomalies can be quickly located, improving the efficiency of anomaly troubleshooting.

[0035] This application's embodiments, through the capture of original input data, dynamic field matching between the original input data and the form message template, as well as structural hierarchy verification and content consistency verification, solve the mismatch between the frequent changes in front-end page fields and the fixed structure of the target form message, thereby improving the accuracy and quality of the target form message generation and the degree of matching with the original input data.

[0036] Example 2 Figure 2 This is a flowchart of a message verification method based on front-end form fields according to Embodiment 2 of this application. Based on the technical solutions of the above embodiments, this embodiment further refines the step of "matching the front-end field key names in the original input data with the corresponding standard field tags in the form message template based on at least two field attribute features of the front-end fields in the target front-end page." It should be noted that for parts not detailed in this embodiment, please refer to the relevant descriptions in other embodiments. Figure 2 As shown, the method includes: S210. Intercept the form submission event of the target front-end page, traverse the source code of the target front-end page, and obtain the original input data.

[0037] S220. Based on the mapping relationship between the front-end field types of the form data and the standard field labels in the form message template, determine the matching standard field label for each form data in the original input data in the form message template, and use it as the standard field label to be verified.

[0038] The front-end field type of the form data can refer to the form control type to which the form data belongs in the front-end page.

[0039] It should be noted that the mapping relationship between the front-end field types of form data and the standard field labels in the form message template means that each form control on the front-end page has a fixed standard field label in the form message template. However, the naming of form controls on the front-end page may be dynamically updated; therefore, the standard field labels in the form message template may differ from the latest names of the form controls on the front-end page.

[0040] S230. For each form data in the original input data, and the corresponding standard field label to be verified, extract their respective field naming features, field business type features, and field data type features.

[0041] The standard field tags to be validated corresponding to the form data can also be understood as the front-end field types of the form data on the front-end page, and the standard field tags in the form message template.

[0042] It should be noted that, for the original entered data, field naming characteristics can refer to the naming attributes of form controls in the target front-end page; field business type characteristics can be used to characterize the business category of the form control, such as personnel, orders, or amounts; field data type characteristics can be used to characterize the data type of the form data corresponding to the form control, such as text, numeric, or enumerated Boolean values. For the standard field labels to be validated in the form message template, field naming characteristics can be used to characterize the label name of the standard field label to be validated; field business type characteristics can be used to characterize the business category to which the standard field label to be validated belongs, such as personnel, orders, or amounts; field data type characteristics can be used to characterize the data type of the field value corresponding to the standard field label to be validated, such as text, numeric, or enumerated Boolean values.

[0043] S240. Based on the field naming characteristics, field business type characteristics, and field data type characteristics, determine the field naming similarity, business matching degree, and data type matching degree between the form data in the original input data and its corresponding standard field labels to be verified.

[0044] It should be noted that field naming similarity can be used to characterize the similarity between the field naming features corresponding to the form data and the field naming features corresponding to the standard field labels to be verified; business matching degree can be used to characterize the matching rate between the form data in the original input data and the business category corresponding to the standard field labels to be verified; data type matching degree can be used to characterize whether the form data and the data type features corresponding to the standard field labels to be verified are consistent.

[0045] Optionally, the business matching degree can be determined by the ratio of the number of business categories that the form data matches with the corresponding standard field labels to be verified to the total number of labels in the standard field labels to be verified; for data type matching degree, if the data type characteristics of the form data are consistent with those of the corresponding standard field labels to be verified, the data type matching degree can be set to 1; if the data type characteristics of the form data are inconsistent with those of the corresponding standard field labels to be verified, the data type matching degree can be set to 0.

[0046] Optionally, the process of determining field naming similarity can be based on the Levinstein edit distance between the front-end field key name of the form data and the standard field label to be verified that matches the form data, as well as the string lengths corresponding to the front-end field key name and the standard field label to be verified, to determine the field naming similarity between the front-end field key name of the form data and the standard field label to be verified that matches the form data.

[0047] It should be noted that Levinstein edit distance can be used to characterize the minimum number of characters that need to be modified to change the key name of a front-end field of form data to the label of the standard field to be validated that matches the form data.

[0048] Optionally, field naming similarity can be determined using the following formula: ; in, It refers to the Levenstein edit distance between string A and string B. The length of string A The length of string B.

[0049] It should be noted that the field naming similarity between string A and string B The range is 0-1.

[0050] S250. The field naming similarity, business matching degree, and data type matching degree are weighted and summed to determine the target similarity score. If the target similarity score is greater than the similarity matching threshold, it is determined that the front-end field key name of the form data matches the standard field label to be verified in the form data.

[0051] Specifically, if the target similarity score is greater than the similarity matching threshold, then the front-end field key name of the form data is determined to match the standard field label to be verified for the form data; if the target similarity score is not greater than the similarity matching threshold, then the front-end field key name of the form data is determined to not match the standard field label to be verified for the form data, and the standard field label to be verified is set as an unknown abnormal field, and an abnormal alert is issued for the unknown abnormal field. Optionally, the similarity matching threshold can be adaptively set according to those skilled in the art.

[0052] It should be noted that, in the embodiments of the present invention, the weights of the similarity weights corresponding to field naming similarity, business matching degree, and data type matching degree are combined to 1, and the similarity weights corresponding to the three can be adaptively set according to those skilled in the art.

[0053] S260. Based on the tag hierarchy structure of the standard field tags corresponding to the form message template, perform structural hierarchy validation on the field tags in the target form message generated by the form submission event.

[0054] S270. Based on the field values ​​corresponding to the front-end field key names in the original entered data, perform content consistency verification on the field values ​​corresponding to the field labels in the target form message.

[0055] This application embodiment uses multi-dimensional field attribute features to perform multi-dimensional matching calculations on the front-end field key names of form data and the standard field tags to be verified that match the form data. The calculations include field naming similarity, business matching degree, and data type matching degree, and determine the target similarity score. This achieves automatic matching between variable front-end fields and fixed XML tags, avoiding the need to manually maintain fixed field name mapping relationships, reducing labor costs, and improving the adaptability to dynamic front-end form fields.

[0056] Example 3 Figure 3 This is a schematic diagram of a message verification device based on front-end form fields according to Embodiment 3 of this application. It is applicable to verifying form messages generated after front-end form input in a Web system. This message verification device based on front-end form fields can be implemented in hardware and / or software, and can be configured in a computer device, such as a server. Figure 3 As shown, the device includes: The raw data acquisition module 310 is used to intercept the form submission event of the target front-end page, traverse the source code of the target front-end page, and obtain the raw input data; wherein, the raw input data refers to the form data entered by the user in the target front-end page; The field matching module 320 is used to perform field matching between the front-end field key names in the original input data and the corresponding standard field tags in the form message template based on at least two field attribute features of the front-end fields in the target front-end page; wherein, the field attribute features include field naming features, field business type features, and field data type features; The structure hierarchy verification module 330 is used to perform structure hierarchy verification on the field tags in the target form message generated by the form submission event based on the tag hierarchy structure of the standard field tags corresponding to the form message template. The consistency verification module 340 is used to perform content consistency verification on the field values ​​corresponding to the field labels in the target form message based on the field values ​​corresponding to the front-end field key names in the original input data.

[0057] This application's embodiments, through the capture of original input data, dynamic field matching between the original input data and the form message template, as well as structural hierarchy verification and content consistency verification, solve the mismatch between the frequent changes in front-end page fields and the fixed structure of the target form message, thereby improving the accuracy and quality of the target form message generation and the degree of matching with the original input data.

[0058] Optionally, the field matching module 320 includes: The standard field unit to be verified is used to determine a matching standard field label for each form data in the original input data in the form message template, based on the mapping relationship between the front-end field type of the form data and the standard field label in the form message template, and to serve as the standard field label to be verified. The field attribute feature extraction unit is used to extract the corresponding field naming features, field business type features, and field data type features for each form data in the original input data and the corresponding standard field label to be verified. The similarity determination unit is used to determine the similarity of field names, business matching degree, and data type matching degree between the form data in the original input data and its corresponding standard field labels to be verified, based on the field naming characteristics, field business type characteristics, and field data type characteristics. The field matching unit is used to perform a weighted summation of the field naming similarity, the business matching degree, and the data type matching degree to determine the target similarity score. If the target similarity score is greater than the similarity matching threshold, it is determined that the front-end field key name of the form data matches the standard field label to be verified of the form data.

[0059] Optionally, the similarity determination unit includes: The naming similarity determination subunit is used to determine the field naming similarity between the front-end field key name of the form data and the standard field label to be verified that matches the form data, based on the Levenstein edit distance between the front-end field key name of the form data and the standard field label to be verified that matches the form data, as well as the string lengths corresponding to the front-end field key name and the standard field label to be verified, respectively.

[0060] Optionally, the structure hierarchy verification module 330 includes: The tag hierarchy structure determination unit is used to traverse each standard field tag in the form message template after the field matching is successful, and determine the tag hierarchy structure corresponding to each standard field tag; wherein, the tag hierarchy structure includes the parent tag and child tags of the standard field tag; The hierarchical structure verification unit is used to perform hierarchical structure verification on the mapped field label corresponding to the standard field label in the target form message according to the label hierarchy structure corresponding to the standard field label. The structure verification unit is used to indicate that the structure level verification has passed if the tag hierarchy structure corresponding to the standard field tag is the same as the tag hierarchy structure of the mapped field tag.

[0061] Optionally, the consistency verification module 340 includes: The field to be verified unit is used to determine a matching field label for each form data in the original input data in the target form message, based on the mapping relationship between the front-end field type of the form data and the field label in the target form message, after the structure-level verification is passed; The content consistency verification unit is used to perform content consistency verification on the field values ​​of the matching field tags based on the data values ​​of the form data. If the data values ​​of the form data are not completely consistent with the field values ​​of the field tags to be verified, it indicates that the consistency verification of the field tags to be verified has failed.

[0062] Optionally, the target form message is generated based on the form message template, the field labels in the target form message have field values, and the field values ​​of the standard field labels in the form message template are empty.

[0063] The message verification device based on front-end form fields provided in this application can execute the message verification method based on front-end form fields provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each message verification method based on front-end form fields.

[0064] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0065] Example 4 Figure 4 This is a schematic diagram of the structure of an electronic device 410 implementing the message verification method based on front-end form fields according to embodiments of this application. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0066] like Figure 4 As shown, the electronic device 410 includes at least one processor 411 and a memory, such as a read-only memory 412 or a random access memory 413, communicatively connected to the at least one processor 411. The memory stores computer programs executable by the at least one processor. The processor 411 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 412 or loaded from storage unit 418 into the random access memory 413. The random access memory 413 can also store various programs and data required for the operation of the electronic device 410. The processor 411, read-only memory 412, and random access memory 413 are interconnected via a bus 414. An input / output interface 415 is also connected to the bus 414.

[0067] Multiple components in electronic device 410 are connected to input / output interface 415, including: input unit 416, such as keyboard, mouse, etc.; output unit 417, such as various types of monitors, speakers, etc.; storage unit 418, such as disk, optical disk, etc.; and communication unit 419, such as network card, modem, wireless transceiver, etc. Communication unit 419 allows electronic device 410 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0068] Processor 411 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 411 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 411 performs the various methods and processes described above, such as message verification methods based on front-end form fields.

[0069] In some embodiments, the message verification method based on front-end form fields can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 418. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 410 via read-only memory 412 and / or communication unit 419. When the computer program is loaded into random access memory 413 and executed by processor 411, one or more steps of the message verification method based on front-end form fields described above can be performed. Alternatively, in other embodiments, processor 411 can be configured for the message verification method based on front-end form fields by any other suitable means (e.g., by means of firmware).

[0070] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), systems-on-a-chip (SoCs), payload programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0071] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable message verification device based on front-end form fields, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0072] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0073] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a cathode ray tube or liquid crystal display monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0074] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0075] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.

[0076] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0077] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A message validation method based on front-end form fields, characterized in that, include: The form submission event of the target front-end page is intercepted, and the source code of the target front-end page is traversed to obtain the original input data; wherein, the original input data refers to the form data entered by the user in the target front-end page; Based on at least two field attribute features of the front-end fields in the target front-end page, field matching is performed between the front-end field key names in the original input data and the corresponding standard field tags in the form message template; wherein, the field attribute features include field naming features, field business type features, and field data type features; Based on the tag hierarchy structure of the standard field tags corresponding to the form message template, the structure hierarchy of the field tags in the target form message generated by the form submission event is validated. Based on the field values ​​corresponding to the front-end field keys in the original entered data, the content consistency verification is performed on the field values ​​corresponding to the field tags in the target form message.

2. The method according to claim 1, characterized in that, The process of matching the front-end field keys in the original input data with the corresponding standard field tags in the form message template based on at least two field attribute features of the front-end fields in the target front-end page includes: Based on the mapping relationship between the front-end field types of the form data and the standard field labels in the form message template, a matching standard field label is determined for each form data in the original input data in the form message template, which serves as the standard field label to be verified. For each form data in the original input data, and the corresponding standard field label to be verified, extract their respective field naming features, field business type features, and field data type features; Based on the field naming characteristics, field business type characteristics, and field data type characteristics, determine the field naming similarity, business matching degree, and data type matching degree between the form data in the original input data and its corresponding standard field labels to be verified; The field naming similarity, business matching degree, and data type matching degree are weighted and summed to determine the target similarity score. If the target similarity score is greater than the similarity matching threshold, it is determined that the front-end field key name of the form data matches the standard field label to be verified in the form data.

3. The method according to claim 2, characterized in that, The process of determining the similarity of field names includes: Based on the Levinstein edit distance between the front-end field key name of the form data and the standard field label to be verified that matches the form data, and the string lengths corresponding to the front-end field key name and the standard field label to be verified, the field naming similarity between the front-end field key name of the form data and the standard field label to be verified that matches the form data is determined.

4. The method according to claim 1, characterized in that, The method of performing structural hierarchy validation on the field tags in the target form message generated by the form submission event based on the tag hierarchy structure of the field tags corresponding to the form message template includes: After the field matching is successful, each standard field label in the form message template is traversed to determine the label hierarchy structure corresponding to each standard field label; wherein, the label hierarchy structure includes the parent label and child labels of the standard field label; Based on the tag hierarchy structure corresponding to the standard field tag, perform a structure hierarchy check on the mapped field tag corresponding to the standard field tag in the target form message; If the tag hierarchy structure corresponding to the standard field tag is the same as the tag hierarchy structure of the mapped field tag, it indicates that the structure hierarchy verification has passed.

5. The method according to claim 1, characterized in that, The step of performing content consistency verification on the field values ​​corresponding to field tags in the target form message based on the field values ​​corresponding to the front-end field keys in the original entered data includes: After the structural hierarchy verification is passed, based on the mapping relationship between the front-end field types of the form data and the field labels in the target form message, a matching field label is determined for each form data in the original input data in the target form message, which is used as the field label to be verified. Perform content consistency verification on the field values ​​of the matching fields to be verified based on the data values ​​of the form data; If the data value of the form data is not completely consistent with the field value of the field label to be validated, it indicates that the consistency validation of the field label to be validated has failed.

6. The method according to claim 1, characterized in that, The target form message is generated based on the form message template. The field labels in the target form message have field values, while the field values ​​of the standard field labels in the form message template are empty.

7. A message verification device based on front-end form fields, characterized in that, include: The raw data acquisition module is used to intercept the form submission event of the target front-end page, traverse the source code of the target front-end page, and obtain the raw input data; wherein, the raw input data refers to the form data entered by the user in the target front-end page; The field matching module is used to perform field matching between the front-end field key names in the original input data and the corresponding standard field tags in the form message template, based on at least two field attribute features of the front-end fields in the target front-end page; wherein, the field attribute features include field naming features, field business type features, and field data type features; The structure hierarchy verification module is used to perform structure hierarchy verification on the field tags in the target form message generated by the form submission event based on the tag hierarchy structure of the standard field tags corresponding to the form message template. The consistency verification module is used to perform content consistency verification on the field values ​​corresponding to the field labels in the target form message based on the field values ​​corresponding to the front-end field key names in the original entered data.

8. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the message verification method based on front-end form fields as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the message verification method based on front-end form fields as described in any one of claims 1-6.

10. A computer program product comprising a computer program that, when executed by a processor, implements the message verification method based on front-end form fields according to any one of claims 1-6.

Images