A multi-format document parsing and verifying method and system

Abstract

This invention discloses a method and system for parsing and verifying multi-format documents. The method includes: receiving a document to be parsed and generating a source file artifact record; identifying the document type and determining a standardized PDF file, performing validity verification, and generating a standardized PDF artifact record for association; submitting a parsing request using the standardized PDF as unified input, recording the request artifact, and receiving an external task identifier; obtaining the parsing result based on the task identifier and generating a parsing result artifact record, establishing a multi-dimensional association between the result and the source file, PDF, and request record; recording the task's lifecycle events and performing phased verification; and forming a document parsing artifact chain based on the artifact records and lifecycle events at each stage. This invention, by establishing a unified visual benchmark and a mesh-like link association, significantly improves parsing accuracy while achieving precise anomaly localization and data closed-loop auditing throughout the entire lifecycle.

Description

Technical Field

[0001] This invention belongs to the field of computer data processing and document information extraction technology, specifically relating to a method and system for parsing and verifying multi-format documents. Specifically, this invention involves uniformly converting source documents of various formats into a standardized PDF as a visual benchmark, and performing phased consistency verification and link tracing on multiple levels of artifacts and their corresponding lifecycle events generated during the parsing process. This enables efficient and accurate parsing of multi-format documents, fault location throughout the parsing lifecycle, and data consistency auditing. Background Technology

[0002] With the advancement of enterprise digital transformation and the widespread application of technologies such as Large Language Modeling (LLM) in document processing, the demand for automated and structured parsing of various document formats (such as PDF, Word, and Excel) is becoming increasingly urgent. However, existing technologies still have the following prominent problems when processing multi-format document parsing and subsequent result verification: I. Regarding the issue of inconsistent visual references In traditional technologies, for documents of different formats (such as Word and PDF), the text and formatting information are usually extracted by directly calling their respective independent parsing engines, or by converting non-PDF documents directly into common plain text or hypertext intermediate formats such as HTML and Markdown before parsing, and then performing business processing or manual verification on these intermediate formats.

[0003] Different document formats, under different rendering environments, operating systems, or parsing paths, have vastly different rendering rules and parameters for their typesetting engines. This can easily lead to shifts in page wrapping, pagination, fonts, line spacing, etc., resulting in a lack of a physically unified visual page baseline. Furthermore, directly converting non-PDF documents to text formats like Markdown, which lack physical layout coordinates, will cause subsequent layout analysis (such as table and image positioning) to completely lose the reference of the original spatial position dimension.

[0004] Therefore, the traditional processing methods described above lead to serious inconsistencies between the parsing results and the original visual content of the document page, causing significant deviations and difficulties for subsequent user page previews, layout structure recognition, coordinate mapping, and manual review, and failing to provide a unified and reliable visual comparison benchmark.

[0005] II. Regarding the issues of untraceable and unreproducible parsing processes

[0006] Existing multi-stage data management in the document parsing lifecycle typically uses only a flat database table to record the original file input path and the final output parsing result (such as extracted Markdown content or JSON structure) of a "parsing task". The intermediate evolution states and temporary files generated in each processing stage are directly discarded or stored in a scattered manner after the task is completed.

[0007] The existing system's data model and management links are too coarse. They fail to build structured "artifact" records for entities at different levels, such as source files, normalized PDFs, parsing requests, and parsing results generated throughout the parsing process. They also fail to establish and maintain strong network links between these artifacts. As a result, the originally continuous and interconnected file evolution and request links are completely fragmented at the data level, making bidirectional tracking impossible.

[0008] This results in extremely poor traceability and reproducibility of the document parsing process. Once a user or auditor discovers that a segment of parsed data contains errors or has a disordered format, the system has difficulty tracing back from that local parsing result to the intermediate normalized file before its conversion, the specific request parameters used when submitting the parsing, or even accurately tracing back to its corresponding original source file.

[0009] III. Regarding the difficulty in locating the source of parsing failures

[0010] The execution status of existing document parsing tasks is typically marked and controlled globally only by a very few coarse-grained status flags (e.g., only "queuing", "processing", "success", and "failure").

[0011] This approach lacks a mechanism for real-time registration and phased verification of fine-grained "lifecycle events" that track the behavior of parsing tasks at different processing stages. In complex document parsing pipelines, due to the lack of event-level recording and incremental consistency checks for key nodes, when an anomaly occurs in an intermediate step, the abnormal state cannot be effectively isolated and accurately captured; it can only be generally summarized as a global task failure.

[0012] Ultimately, this leads to a "black box" state when the parsing system faces abnormal failures, making it extremely difficult to accurately pinpoint the specific link and root cause of the failure. Developers and operations personnel cannot intuitively and automatically determine whether a task failure is due to corrupted original files causing format conversion failure, network fluctuations causing request sending failure, or a parsing engine crash or timeout, resulting in high costs for system maintenance and troubleshooting.

[0013] IV. Regarding the issue of unreliable parsed input

[0014] In traditional technologies, when a system submits a file to be parsed (especially a PDF file generated by a format conversion engine) to a document parsing engine, it usually sends the file to the downstream parsing service queue directly based on the file path or task identifier after the conversion task is completed.

[0015] Because the system lacks an independent, rigorous, and multi-dimensional "validity verification mechanism" after format conversion and before submitting the parsing request, relying solely on the success / failure status returned by the upstream conversion engine is unreliable (for example, the conversion process may not actually generate a file due to timeout, or the generated PDF file may be 0 bytes in size, or its file header may not even conform to the characteristics of the standard PDF format). Directly inputting unreliable artifacts to the downstream without checking for existence, file size, file header characteristics, and hash, inevitably leads to extremely fragile stability and robustness of the entire parsing pipeline.

[0016] This approach results in a large number of invalid, null, incompletely converted, or severely corrupted files directly entering the subsequent expensive and time-consuming document parsing process. This not only easily causes the downstream parsing engine to crash or hang, but also seriously wastes the system's concurrent parsing performance and computing resources.

[0017] V. Regarding the discrepancy between the parsing results and the mapping of the page's visual area

[0018] In traditional technologies, when the parsing engine returns bounding boxes or coordinate information containing content blocks such as paragraphs, tables, and images, the system usually directly displays these coordinate data to the front-end interface for highlighting and previewing, or uses these coordinates as the starting point for manual fine-tuning during the manual review stage.

[0019] Because the content block coordinates output by the parsing engine (usually based on a specific DPI and page size rendered internally by the engine) do not undergo strict mapping and calibration transformation in terms of page scale, index, orientation, and DPI between the actual size of the document page in the front-end preview or storage, directly using the raw coordinate output of the parsing engine in the absence of a coordinate transformation model based on the same normalized PDF file size will inevitably lead to serious misalignment of spatial geometric information.

[0020] This leads to serious deviations such as frequent overall offset, stretching deformation, or overlapping misalignment of highlighted boxes and marked areas during manual review and page preview, making it impossible to provide a reliable data basis and intuitive visual feedback during the manual review stage. Summary of the Invention

[0021] The following provides a brief overview of one or more aspects to offer a basic understanding of them. This overview is not an exhaustive summary of all conceived aspects, nor is it intended to identify key or decisive elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form to prepare for the more detailed descriptions that follow.

[0022] The purpose of this invention is to solve the above-mentioned problems and provide a method and system for parsing and verifying multi-format documents. This system can uniformly convert multi-format documents into standardized PDFs to establish a unique visual benchmark. By performing phased verification and full-link tracking of the entire parsing process and lifecycle events, it can significantly improve the accuracy of parsing and spatial coordinate mapping, while achieving accurate anomaly location and data closed-loop auditing throughout the parsing lifecycle.

[0023] The technical solution of this invention is as follows: This invention discloses a method for parsing and verifying multi-format documents, the method comprising: Step S1: Receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed; Step S2: Identify the document type of the document to be parsed, and determine the normalized PDF file based on the document type; Step S3: Perform a validity check on the standardized PDF file; Step S4: Generate a standardized PDF workpiece record and establish the association between the source file workpiece record and the standardized PDF workpiece record; Step S5: Using the standardized PDF file as the unified input file, submit a parsing request to the document parsing engine; Step S6: Record the parsing request artifact or parsing attempt record, and receive the external parsing task identifier returned by the document parsing engine; Step S7: Obtain the parsing status based on the external parsing task identifier, and obtain the parsing result after the parsing is completed; Step S8: Generate parsing result workpiece records and establish the association between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records; Step S9: Record the lifecycle events of the document parsing task, and perform phased verification of the parsing process based on the lifecycle events; Step S10: Based on the source file artifact record, normalized PDF artifact record, parsing request record, parsing result artifact record, and lifecycle events, form a document parsing artifact chain.

[0024] According to an embodiment of the multi-format document parsing and verification method of the present invention, the document to be parsed includes a PDF document, a Word document, or other office documents that can be converted to PDF; the source file artifact record includes at least one or more of the following: file identifier, file name, file storage address, file type, file size, file hash value, upload time, and task identifier.

[0025] According to one embodiment of the multi-format document parsing and verification method of the present invention, the document type identification is completed based on one or more of the following methods: file extension, content type, file header features, and file metadata; the method for determining a normalized PDF file is as follows: when the document to be parsed is a PDF type, the file corresponding to the source file artifact is determined as a normalized PDF file; when the document to be parsed is a non-PDF type, a document conversion engine is invoked to convert the document to be parsed into a normalized PDF file.

[0026] According to one embodiment of the multi-format document parsing and verification method of the present invention, the normalization processing of non-PDF type documents is performed in an asynchronous task; when performing format conversion, the document conversion engine allocates an independent working directory, input directory, output directory and running configuration directory for each conversion task.

[0027] According to an embodiment of the multi-format document parsing and verification method of the present invention, the validity verification includes at least one of the following: verifying whether a standardized PDF file exists, verifying whether the file size is greater than a preset threshold, verifying whether the file header conforms to the PDF format, calculating and recording the file hash value, verifying whether the conversion process times out, and verifying whether the conversion output path matches the task record.

[0028] According to an embodiment of the multi-format document parsing and verification method of the present invention, the normalized PDF artifact record includes one or more of the following: file identifier, file name, storage address, file size, hash value, generation method, source file identifier, and generation time of the normalized PDF file; the association relationship is established in the following manner: for a PDF type document to be parsed, the source file artifact record and the normalized PDF artifact record point to the same file; for a non-PDF type document to be parsed, the normalized PDF artifact record points to a PDF file generated by the document conversion engine.

[0029] According to one embodiment of the multi-format document parsing and verification method of the present invention, the parsing request includes one or more of the following: normalized PDF file address, parsing parameters, task identifier, page number range, language parameters, table parsing parameters, and formula parsing parameters.

[0030] According to one embodiment of the multi-format document parsing and verification method of the present invention, the parsing attempt record includes one or more of the following: task identifier, number of attempts, parsing engine identifier, submission time, request parameters, external parsing task identifier, submission status, and error information.

[0031] According to an embodiment of the multi-format document parsing and verification method of the present invention, the parsing result includes one or more of the following: a result compressed package, Markdown text, a content block list, page layout data, and intermediate structure files. The content block list includes structural units such as text blocks, title blocks, table blocks, and image blocks, along with their page numbers, position information, or bounding box information. The page layout data includes page size, page order, page element coordinates, and intermediate output of the parsing model. The content block list in the parsing result contains page indexes and bounding box information, wherein, based on the page size of the normalized PDF file, the bounding box information in the content block list is converted into page coordinates consistent with those of the normalized PDF file.

[0032] According to one embodiment of the multi-format document parsing and verification method of the present invention, the parsing result artifact record includes one or more of the following: result file type, result file address, file size, file hash value, task identifier, parsing attempt identifier, and generation time.

[0033] According to an embodiment of the multi-format document parsing and verification method of the present invention, the lifecycle events include one or more of the following: source file reception event, document type identification event, normalization processing start event, normalization processing success event, normalization processing failure event, normalized PDF verification event, parsing request submission event, parsing status polling event, parsing result acquisition event, parsing result registration event, task completion event, and task failure event.

[0034] According to an embodiment of the multi-format document parsing and verification method of the present invention, the staged verification includes at least one of the following: Verify that the source file workpiece record exists; Verify that the standardized PDF workpiece record exists and passes the validity check. Verify whether the input file referenced by the parsing request is the normalized PDF file; Verify whether the parsed workpiece is associated with the same task identifier or the same parsing attempt identifier; Verify whether the page structure information in the parsing results corresponds to the standardized PDF file; Verify whether the task lifecycle events cover the preset key stages; When any critical stage is missing, fails, or the workpiece relationship is inconsistent, a corresponding error state and error event are generated.

[0035] According to one embodiment of the multi-format document parsing and verification method of the present invention, the document parsing artifact chain is used to support parsing task tracking, failure stage location, result verification, page preview, parsing result backtracking, and subsequent archiving processing.

[0036] This invention also discloses a multi-format document parsing and verification system, the system comprising: The document access and source workpiece registration module is used to receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed; The type recognition and normalization conversion module is used to identify the document type of the document to be parsed and determine the normalized PDF file based on the document type; A standardized document validity verification module is used to verify the validity of the standardized PDF file; The standardized workpiece registration and primary association module is used to generate standardized PDF workpiece records and establish the association between the source file workpiece records and the standardized PDF workpiece records; The parsing engine integration and request submission module uses the standardized PDF file as a unified input file to submit a parsing request to the document parsing engine. The parsing attempt log and token acquisition module is used to record parsing request artifacts or parsing attempt logs, and to receive external parsing task identifiers returned by the document parsing engine; The parsing status tracking and result extraction module is used to obtain the parsing status based on the external parsing task identifier, and to obtain the parsing result after the parsing is completed; The result workpiece registration and multidimensional association module is used to generate parsing result workpiece records and establish the association relationship between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records; The lifecycle monitoring and stage verification module is used to record lifecycle events of the document parsing task and perform stage-based verification of the parsing process based on the lifecycle events. The end-to-end workpiece traceability and synthesis module is used to form a document parsing workpiece chain based on the source file workpiece record, standardized PDF workpiece record, parsing request record, parsing result workpiece record, and lifecycle events.

[0037] The present invention also discloses a computer system including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the multi-format document parsing and verification method described above.

[0038] The present invention also discloses a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the multi-format document parsing and verification method described above.

[0039] The present invention also discloses a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the multi-format document parsing and verification method described above.

[0040] Compared with the prior art, the present invention has the following advantages: First, by generating or determining a standardized PDF file before document parsing and using the standardized PDF file as a unified visual benchmark for subsequent parsing, previewing, coordinate mapping, and verification, this invention avoids the problem of inconsistent page display caused by documents of different formats under different rendering environments or different parsing paths, and improves the consistency between the parsing results and the original page visual content.

[0041] Secondly, by generating source file artifact records, normalized PDF artifact records, parsing request records, and parsing result artifact records respectively, and establishing the association between the above artifact records, this invention enables any parsing result to be traced back to the corresponding normalized PDF file and the original source file, and any source file can also be traced to its corresponding normalized file, parsing request, and parsing result, thereby improving the traceability and reproducibility of the document parsing process.

[0042] Third, by recording the lifecycle events generated during the document parsing task in stages such as source file reception, document type identification, normalization processing, normalized PDF verification, parsing request submission, parsing status acquisition, and parsing result registration, this invention enables the system to locate the specific processing stage where the failure occurred when parsing fails, and generate corresponding error statuses and error events, thereby improving the ability to locate anomalies and troubleshoot faults.

[0043] Fourth, before submitting the file to the document parsing engine, the present invention performs validity checks on the standardized PDF file. The validity checks include one or more of the following: file existence check, file size check, file format header check, and file hash value record. This can prevent invalid files, empty files, files with abnormal formats, or files that have failed to be converted from entering the parsing process, thereby improving the reliability of parsing input files.

[0044] Fifth, this invention associates the parsed result artifact with the standardized PDF file, and uses the page index, content block information or bounding box information in the parsed result to establish the correspondence between the parsed result and the page area of ​​the standardized PDF, thereby providing a reliable data foundation for page preview, manual review, parsed result verification and layout consistency verification.

[0045] In summary, this invention uses standardized PDF files as a unified visual benchmark in the multi-format document parsing process, and employs an artifact tracing mechanism to associate and record the source file, standardized file, parsing request, parsing result, and lifecycle events during the document parsing process, thereby improving the consistency of parsing input, the traceability of the parsing process, the location of parsing failures, and the consistency between parsing results and page visual content in multi-format document parsing scenarios. Attached Figure Description

[0046] The above-described features and advantages of the present invention will be better understood after reading the following detailed description of embodiments of the present disclosure in conjunction with the accompanying drawings. In the drawings, components are not necessarily drawn to scale, and components having similar related characteristics or features may have the same or similar reference numerals.

[0047] Figure 1 A flowchart of an embodiment of the multi-format document parsing and verification method of the present invention is shown.

[0048] Figure 2 A schematic diagram of an embodiment of the multi-format document parsing and verification system of the present invention is shown.

[0049] Figure 3 The diagram shows an example of the overall structure of a server system actually built according to the present invention.

[0050] Figure 4 A schematic diagram of the workpiece link relationship is shown. Detailed Implementation

[0051] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. It should be noted that the aspects described below with reference to the accompanying drawings and specific embodiments are merely exemplary and should not be construed as limiting the scope of protection of the present invention in any way.

[0052] Figure 1 The flowchart of an embodiment of the multi-format document parsing and verification method of the present invention is shown. See also Figure 1 The implementation steps of the method in this embodiment are described in detail below.

[0053] Step S1: Receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed.

[0054] The document to be parsed includes PDF documents, Word documents, or other office documents that can be converted to PDF. The source file artifact record includes at least one or more of the following: file identifier, file name, file storage address, file type, file size, file hash value, upload time, and task identifier.

[0055] Step S2: Identify the document type of the document to be parsed, and determine the normalized PDF file based on the document type.

[0056] Document type identification can be accomplished based on one or more of the following methods: file extension, content type, file header features, and file metadata.

[0057] When the document to be parsed is a PDF, the file corresponding to the source file artifact is determined as a normalized PDF file; when the document to be parsed is not a PDF, the document conversion engine is invoked to convert the document to be parsed into a normalized PDF file.

[0058] Normalization of non-PDF documents is performed in an asynchronous task. Upon receiving a document to be parsed, the system first creates a parsing task and a source file artifact record. When the system detects that the document requires format conversion, it submits the parsing task to the conversion queue. After the conversion is complete and a normalized PDF file is generated, the parsing task is then submitted to the parsing submission queue. This avoids blocking frontend requests during document conversion and improves the ability to handle multiple documents concurrently.

[0059] When performing format conversion, the document conversion engine allocates an independent working directory, input directory, output directory, and runtime configuration directory to each conversion task. By isolating the conversion environments of different tasks, file lock conflicts, temporary file contamination, or mutual interference of runtime states between multiple conversion tasks are avoided.

[0060] Step S3: Perform a validity check on the standardized PDF file.

[0061] The validity check includes at least one of the following: verifying the existence of the standardized PDF file, verifying whether the file size exceeds a preset threshold, verifying whether the file header conforms to the PDF format, calculating and recording the file hash value, verifying whether the conversion process times out, and verifying whether the conversion output path matches the task record. Only when the standardized PDF file passes the validity check is it allowed to proceed to the subsequent parsing process.

[0062] Step S4: Generate a standardized PDF workpiece record and establish the association between the source file workpiece record and the standardized PDF workpiece record.

[0063] The standardized PDF artifact record includes at least one or more of the following: file identifier, file name, storage address, file size, hash value, generation method, source file identifier, and generation time of the standardized PDF file.

[0064] The association is established as follows: for PDF documents to be parsed, the source file artifact record and the normalized PDF artifact record can point to the same file; for non-PDF documents to be parsed, the normalized PDF artifact record points to the PDF file generated by the document conversion engine. Those skilled in the art will understand that the document conversion engine can be an open-source or commercial format conversion tool such as LibreOffice, Adobe Acrobat, or Microsoft Office, and this invention does not impose any specific limitations on it.

[0065] Step S5: Using the standardized PDF file as the unified input file, submit a parsing request to the document parsing engine.

[0066] The parsing request includes one or more of the following: a normalized PDF file address, parsing parameters, a task identifier, a page number range, language parameters, table parsing parameters, and formula parsing parameters. The document parsing engine does not directly use the original non-PDF file as parsing input, but rather a normalized PDF file that has passed validity verification. This ensures that subsequent page preview, layout structure recognition, coordinate mapping, and manual review are all based on the same visual benchmark. The document parsing engine can be any document understanding engine or third-party parsing interface based on deep learning, optical character recognition (OCR), or large language model (LLM). In specific implementations, the document parsing engine may include, but is not limited to, PaddleOCR, TesseractOCR, Unstructured, LlamaParse, etc., and this invention does not impose any limitations on this.

[0067] Step S6: Record the parsing request artifact or parsing attempt record, and receive the external parsing task identifier returned by the document parsing engine.

[0068] The parsing attempt record includes at least one or more of the following: task identifier, number of attempts, parsing engine identifier, submission time, request parameters, external parsing task identifier, submission status, and error message. If the parsing request submission fails, a submission failure event is recorded, and a decision is made on whether to resubmit.

[0069] Step S7: Obtain the parsing status based on the external parsing task identifier, and obtain the parsing result after the parsing is completed.

[0070] The parsing results include one or more of the following: a compressed result package, Markdown text, a list of content blocks, page layout data, and intermediate structure files. The list of content blocks includes structural units such as text blocks, heading blocks, table blocks, and image blocks, along with their page numbers, position information, or bounding box information. The page layout data includes page size, page order, page element coordinates, and intermediate output from the parsing model.

[0071] The content block list in the parsing result includes page indexes and bounding box information. Based on the page dimensions of the normalized PDF file, the system converts the bounding box information in the content block list into page coordinates consistent with those of the normalized PDF file. Therefore, the parsing result can establish a correspondence with page regions in the normalized PDF file, which can be used for subsequent page preview and manual review.

[0072] Step S8: Generate parsing result workpiece records and establish the association between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records.

[0073] The parsing result artifact record includes at least one or more of the following: result file type, result file address, file size, file hash value, task identifier, parsing attempt identifier, and generation time. Through the association established in step S8, it is possible to trace back from any parsing result to the corresponding normalized PDF file and the original source file, and also to trace from the source file to its subsequently generated normalized PDF files and parsing result files.

[0074] Step S9: Record the lifecycle events of the document parsing task, and perform phased verification of the parsing process based on the lifecycle events.

[0075] The lifecycle events include one or more of the following: source file reception event, document type identification event, normalization processing start event, normalization processing success event, normalization processing failure event, normalized PDF verification event, parsing request submission event, parsing status polling event, parsing result acquisition event, parsing result registration event, task completion event, and task failure event.

[0076] The phased verification includes at least one of the following: Verify that the source file workpiece record exists; Verify that the standardized PDF workpiece record exists and passes the validity check. Verify whether the input file referenced by the parsing request is the normalized PDF file; Verify whether the parsed workpiece is associated with the same task identifier or the same parsing attempt identifier; Verify whether the page structure information in the parsing results corresponds to the standardized PDF file; Verify whether the task lifecycle events cover the preset key stages; When any critical stage is missing, fails, or the workpiece relationship is inconsistent, a corresponding error state and error event are generated.

[0077] Step S10: Based on the source file artifact record, normalized PDF artifact record, parsing request record, parsing result artifact record, and lifecycle events, form a document parsing artifact chain.

[0078] Figure 4 A schematic diagram of the workpiece link is shown. (For example...) Figure 4 As shown, the document parsing artifact chain supports parsing task tracking, failure stage location, result verification, page preview, parsing result backtracking, and subsequent archiving. Through the artifact chain, the system can determine the original file, normalized PDF file, parsing request parameters, parsing attempt records, and lifecycle events corresponding to any parsing result.

[0079] After the above steps S1 to S10, the method of the present invention uses a standardized PDF file as a unified visual benchmark in the process of parsing multi-format documents, and uses an artifact link tracing mechanism to associate and record the source file, standardized file, parsing request, parsing result and lifecycle events in the document parsing process and verify consistency.

[0080] Figure 2 The principle of an embodiment of the multi-format document parsing and verification system of the present invention is illustrated. (Reference) Figure 2 The system in this embodiment includes: a document access and source workpiece registration module, a type identification and normalization conversion module, a normalized document validity verification module, a normalized workpiece registration and first-level association module, a parsing engine docking and request submission module, a parsing attempt recording and token acquisition module, a parsing status tracking and result extraction module, a result workpiece registration and multi-dimensional association module, a lifecycle monitoring and stage verification module, and a full-link workpiece traceability and synthesis module.

[0081] The document access and source workpiece registration module is used to receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed.

[0082] The document to be parsed includes PDF documents, Word documents, or other office documents that can be converted to PDF. The source file artifact record includes at least one or more of the following: file identifier, file name, file storage address, file type, file size, file hash value, upload time, and task identifier.

[0083] The type recognition and normalization conversion module is used to identify the document type of the document to be parsed and determine the normalized PDF file based on the document type.

[0084] Document type identification can be accomplished based on one or more of the following methods: file extension, content type, file header features, and file metadata.

[0085] When the document to be parsed is a PDF, the file corresponding to the source file artifact is determined as a normalized PDF file; when the document to be parsed is not a PDF, the document conversion engine is invoked to convert the document to be parsed into a normalized PDF file.

[0086] Normalization of non-PDF documents is performed in an asynchronous task. Upon receiving a document to be parsed, the system first creates a parsing task and a source file artifact record. When the system detects that the document requires format conversion, it submits the parsing task to the conversion queue. After the conversion is complete and a normalized PDF file is generated, the parsing task is then submitted to the parsing submission queue. This avoids blocking frontend requests during document conversion and improves the ability to handle multiple documents concurrently.

[0087] When performing format conversion, the document conversion engine allocates an independent working directory, input directory, output directory, and runtime configuration directory to each conversion task. By isolating the conversion environments of different tasks, file lock conflicts, temporary file contamination, or mutual interference of runtime states between multiple conversion tasks are avoided.

[0088] The standardized document validity verification module is used to verify the validity of the standardized PDF file.

[0089] The validity check includes at least one of the following: verifying the existence of the standardized PDF file, verifying whether the file size exceeds a preset threshold, verifying whether the file header conforms to the PDF format, calculating and recording the file hash value, verifying whether the conversion process times out, and verifying whether the conversion output path matches the task record. Only when the standardized PDF file passes the validity check is it allowed to proceed to the subsequent parsing process.

[0090] The standardized workpiece registration and primary association module is used to generate standardized PDF workpiece records and establish the association between the source file workpiece records and the standardized PDF workpiece records.

[0091] The standardized PDF artifact record includes at least one or more of the following: file identifier, file name, storage address, file size, hash value, generation method, source file identifier, and generation time of the standardized PDF file.

[0092] The association is established in the following way: for PDF type documents to be parsed, the source file artifact record and the normalized PDF artifact record can point to the same file; for non-PDF type documents to be parsed, the normalized PDF artifact record points to the PDF file generated by the document conversion engine.

[0093] The parsing engine integration and request submission module uses the standardized PDF file as a unified input file to submit a parsing request to the document parsing engine.

[0094] The parsing request includes one or more of the following: a normalized PDF file address, parsing parameters, a task identifier, a page number range, language parameters, table parsing parameters, and formula parsing parameters. The document parsing engine does not directly use the original non-PDF file as parsing input; instead, it uses a normalized PDF file that has passed validity checks as parsing input. This ensures that subsequent page previews, layout structure recognition, coordinate mapping, and manual review are all based on the same visual benchmark.

[0095] The parsing attempt log and token acquisition module is used to record parsing request artifacts or parsing attempt logs, and to receive external parsing task identifiers returned by the document parsing engine.

[0096] The parsing attempt record includes at least one or more of the following: task identifier, number of attempts, parsing engine identifier, submission time, request parameters, external parsing task identifier, submission status, and error message. If the parsing request submission fails, a submission failure event is recorded, and a decision is made on whether to resubmit.

[0097] The parsing status tracking and result extraction module is used to obtain the parsing status based on the external parsing task identifier, and to obtain the parsing result after the parsing is completed; The parsing results include one or more of the following: a compressed result package, Markdown text, a list of content blocks, page layout data, and intermediate structure files. The list of content blocks includes structural units such as text blocks, heading blocks, table blocks, and image blocks, along with their page numbers, position information, or bounding box information. The page layout data includes page size, page order, page element coordinates, and intermediate output from the parsing model.

[0098] The content block list in the parsing result includes page indexes and bounding box information. Based on the page dimensions of the normalized PDF file, the system converts the bounding box information in the content block list into page coordinates consistent with those of the normalized PDF file. Therefore, the parsing result can establish a correspondence with page regions in the normalized PDF file, which can be used for subsequent page preview and manual review.

[0099] The result workpiece registration and multidimensional association module is used to generate parsing result workpiece records and establish the association relationship between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records.

[0100] The parsing result artifact record includes at least one or more of the following: result file type, result file address, file size, file hash value, associated task identifier, associated parsing attempt identifier, and generation time. Through the association established between the result artifact registration and the multi-dimensional association module, it is possible to trace back from any parsing result to the corresponding normalized PDF file and the original source file, and also to trace from the source file to its subsequently generated normalized PDF file and parsing result file.

[0101] The lifecycle monitoring and stage verification module is used to record lifecycle events of the document parsing task and perform stage-based verification of the parsing process based on the lifecycle events.

[0102] The lifecycle events include one or more of the following: source file reception event, document type identification event, normalization processing start event, normalization processing success event, normalization processing failure event, normalized PDF verification event, parsing request submission event, parsing status polling event, parsing result acquisition event, parsing result registration event, task completion event, and task failure event.

[0103] The phased verification includes at least one of the following: Verify that the source file workpiece record exists; Verify that the standardized PDF workpiece record exists and passes the validity check. Verify whether the input file referenced by the parsing request is the normalized PDF file; Verify whether the parsed workpiece is associated with the same task identifier or the same parsing attempt identifier; Verify whether the page structure information in the parsing results corresponds to the standardized PDF file; Verify whether the task lifecycle events cover the preset key stages; When any critical stage is missing, fails, or the workpiece relationship is inconsistent, a corresponding error state and error event are generated.

[0104] The end-to-end workpiece traceability and synthesis module is used to form a document parsing workpiece chain based on the source file workpiece record, standardized PDF workpiece record, parsing request record, parsing result workpiece record, and lifecycle events.

[0105] The document parsing artifact chain supports parsing task tracking, failure stage location, result verification, page preview, parsing result backtracking, and subsequent archiving. Through the artifact chain, the system can determine the original file, normalized PDF file, parsing request parameters, parsing attempt records, and lifecycle events corresponding to any parsing result.

[0106] Furthermore, this invention also discloses a computer system, including a memory and a processor, wherein a computer program is stored in the memory. When the processor executes the computer program, it implements... Figure 1 All steps of an embodiment of the multi-format document parsing and verification method shown.

[0107] Furthermore, this invention also discloses a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements as follows: Figure 1 All steps of an embodiment of the multi-format document parsing and verification method shown.

[0108] Furthermore, this invention also discloses a computer program product, including a computer program / instructions, which, when executed by a processor, implements as follows: Figure 1 All steps of an embodiment of the multi-format document parsing and verification method shown.

[0109] like Figure 3 As shown, in actual server system setup, this example server system includes user terminals, backend servers, task queue servers, document conversion servers, document parsing servers, database servers, and file storage servers.

[0110] The system comprises the following components: a user terminal communicates with the backend server via HTTP or HTTPS to upload documents to be parsed and query parsing task status; a backend server communicates with the database server to write and read parsing task records, artifact records, and lifecycle events; a backend server communicates with the file storage server to store source files, normalized PDF files, and parsing result files; a backend server communicates with the task queue server to submit document conversion tasks, parsing submission tasks, parsing status query tasks, and parsing result retrieval tasks; a document conversion server communicates with the task queue server to consume document conversion tasks; and a document parsing server communicates with the backend server or document conversion server via an HTTP interface to receive normalized PDF files and return parsing results.

[0111] In this example, the database server is configured with a parsing task table, a file artifact table, a parsing attempt table, and a lifecycle event table.

[0112] The task table is used to record task identifier, task status, source file identifier, normalized PDF file identifier, current processing stage, error code, error message, creation time and update time.

[0113] The file artifact table records file identifier, file name, file type, file storage address, file size, file hash value, artifact type, and associated task identifier. Artifact types include source files, normalized PDF files, parsed result compressed packages, Markdown files, content block list files, and layout structure files.

[0114] The parsing attempt table is used to record information about each attempt to submit a parsing request to the document parsing server, including the number of attempts, request parameters, external parsing task identifier, submission time, completion time, and attempt status.

[0115] The lifecycle event table records events generated during each processing stage of the parsing task, including source file reception event, document type identification event, normalization processing start event, normalization processing success event, normalized PDF verification event, parsing request submission event, parsing status query event, parsing result retrieval event, parsing result registration event, task completion event, and task failure event.

[0116] The specific implementation process of this example is as follows.

[0117] The first step involves the user uploading a document to be parsed, such as A.docx, via their terminal. After receiving the document, the backend server saves it to the file storage server and generates a source file artifact record in the file artifact table. This source file artifact record includes the file name A.docx, file type application / vnd.openxmlformats-officedocument.wordprocessingml.document, file storage address, file size, file hash value, and artifact type source.

[0118] Meanwhile, the backend server creates a parsing task record in the parsing task table, sets the task status to queued, and writes the source file receive event into the lifecycle event table.

[0119] The second step involves the backend server identifying the document type of the document to be parsed. This identification includes reading the file extension, the content type in the upload request, and file header features. When the identification result indicates that the document to be parsed is a Word document, the backend server determines that the document needs to be normalized and submits the task to the document conversion queue in the task queue server.

[0120] At this point, the current processing stage in the parsing task table is updated to conversion_pending, and a document type identification event is written to the lifecycle event table.

[0121] The third step involves the document conversion server retrieving the document conversion task from the task queue server. The document conversion server creates separate working, input, output, and runtime configuration directories for this task, and then invokes the document conversion engine to convert A.docx to A.pdf.

[0122] After conversion, the document conversion server performs validity checks on the generated A.pdf. Validity checks include: determining if A.pdf exists, checking if the file size is greater than zero, reading the file header to determine if it conforms to the PDF file format, and calculating the hash value of the PDF file. If all checks pass, A.pdf is saved to the file storage server, and a normalized PDF artifact record is generated in the file artifact table, with the artifact type being canonical_pdf.

[0123] Meanwhile, the backend server updates the normalized PDF file identifier in the parsing task table to the file identifier of the normalized PDF artifact record, and writes the normalization processing success event and normalized PDF verification pass event into the lifecycle event table.

[0124] Fourth, the backend server or document conversion server submits the task to the parsing submission queue. After the parsing submission task is consumed, the system reads the normalized PDF file identifier from the parsing task table and obtains the corresponding normalized PDF file storage address from the file artifact table.

[0125] The system uses the normalized PDF file as the sole input for parsing and submits a parsing request to the document parsing server. The parsing request includes the normalized PDF file address, task identifier, page number range, language parameters, table recognition parameters, and formula recognition parameters.

[0126] It should be noted that in this example, the document parsing server does not directly receive the original A.docx file, but rather the A.pdf file that has undergone validity verification. Therefore, subsequent parsing results, page previews, and layout coordinate checks are all based on the same PDF page reference.

[0127] Fifth, after receiving the normalized PDF file, the document parsing server performs parsing and returns an external parsing task identifier. The backend server records the external parsing task identifier, request parameters, and submission time in the parsing attempt table and updates the parsing task status to "submitted." Simultaneously, it writes the parsing request submission event to the lifecycle event table.

[0128] Step 6: The backend server periodically queries the document parsing server's parsing status based on the external parsing task identifier. Once the document parsing server returns a parsing completion status, the backend server retrieves the parsing result file. The parsing result file includes a compressed result package, a Markdown file, a content block list file, and a layout structure file.

[0129] The backend server saves the parsed result files to the file storage server and generates parsing result artifact records in the file artifact table. Each parsing result artifact record is associated with the same parsing task identifier and the same parsing attempt identifier.

[0130] The Markdown file represents the text-based parsing results of the document; the content block list file records content units such as title blocks, text blocks, table blocks, and image blocks, as well as their page numbers and bounding box information; and the layout structure file records page size, page order, and layout element coordinate information.

[0131] Step 7: The backend server establishes the association between the source file artifact record, the normalized PDF artifact record, the parsing attempt record, and the parsing result artifact record.

[0132] In this example, A.docx corresponds to the source file artifact, A.pdf corresponds to the normalized PDF artifact, the parsing request record corresponds to the request submitted to the document parsing server this time, and the parsing result compressed package, Markdown file, content block list file, and layout structure file correspond to the parsing result artifacts. All of the above artifacts are associated with the same parsing task identifier.

[0133] Through this relationship, the system can trace back from the Markdown file to the corresponding normalized PDF file A.pdf and the original source file A.docx, and can also query the normalized PDF file and parsing result file generated from the original source file A.docx.

[0134] Step 8: The backend server performs parsing process verification based on lifecycle events and artifact records. Verification includes: whether the source file artifact exists, whether the normalized PDF artifact exists, whether the normalized PDF passes validity checks, whether the input file referenced by the parsing request is a normalized PDF file, whether the parsing result artifact is associated with the current parsing task, and whether the page indexes in the parsing results correspond to pages in the normalized PDF file.

[0135] If all the above verifications pass, the backend server will update the parsing task status to "succeeded" and write a task completion event. If any critical artifact is missing, or the normalized PDF verification fails, or the parsing result cannot be associated with the current task, the backend server will update the parsing task status to "failed," record the error code and error message, and write a task failure event.

[0136] In this example, the static relationships between the components are as follows: the user terminal is used to submit documents and query results; the backend server is used to create tasks, manage status, and organize artifact relationships; the task queue server is used to decouple time-consuming tasks; the document conversion server is used to generate normalized PDF files; the document parsing server is used to parse the normalized PDF files; the database server is used to store task records, artifact records, and lifecycle events; and the file storage server is used to store source files, normalized PDF files, and parsing result files.

[0137] The dynamic relationships between the components are as follows: After the user terminal uploads a document, the backend server first saves the source file and creates a task; when the document to be parsed is not a PDF document, the task enters the document conversion server through the task queue server to generate a normalized PDF; after the normalized PDF passes the verification, the backend server submits the normalized PDF to the document parsing server; after the document parsing server completes the parsing, the backend server obtains the parsing result and registers the result artifact; finally, the backend server completes the verification of the parsing process based on the artifact link and lifecycle events.

[0138] This example demonstrates how a server system can unify the parsing of Word and PDF documents under a standardized PDF page baseline, avoiding inconsistencies in page baselines caused by different document formats. Furthermore, by establishing relationships between source file artifacts, standardized PDF artifacts, parsing request records, parsing result artifacts, and lifecycle events, the parsing process becomes traceable, reproducible, and allows for the identification of failure stages.

[0139] Although the methods described above are illustrated and depicted as a series of actions for the sake of simplicity, it should be understood and appreciated that these methods are not limited by the order of the actions, as some actions may occur in a different order and / or concurrently with other actions from the illustrations and descriptions herein or not illustrated and described herein but which may be understood by those skilled in the art, according to one or more embodiments.

[0140] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps are described above in a generalized manner in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as departing from the scope of the invention.

[0141] The various illustrative logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternatives, it may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors cooperating with a DSP core, or any other such configuration.

[0142] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor such that the processor can read and write information to / from the storage medium. In an alternative, the storage medium may be integrated into the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In an alternative, the processor and storage medium may reside as discrete components in the user terminal.

[0143] In one or more exemplary embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software as a computer program product, the functionality may be stored or transmitted as one or more instructions or code on or through a computer-readable medium. A computer-readable medium includes both computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. A storage medium may be any available medium accessible to a computer. By way of example and not limitation, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and is accessible to a computer. Any connection is also legitimately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. As used in this article, disk and disc include compact discs (CDs), laser discs, optical discs, digital multi-purpose discs (DVDs), floppy disks, and Blu-ray discs. Disks typically reproduce data magnetically, while discs reproduce data optically using lasers. Combinations of these should also be included within the scope of computer-readable media.

[0144] The prior description of this disclosure is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples and designs described herein, but should be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for parsing and verifying multi-format documents, characterized in that, The methods include: Step S1: Receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed; Step S2: Identify the document type of the document to be parsed, and determine the normalized PDF file based on the document type; Step S3: Perform a validity check on the standardized PDF file; Step S4: Generate a standardized PDF workpiece record and establish the association between the source file workpiece record and the standardized PDF workpiece record; Step S5: Using the standardized PDF file as the unified input file, submit a parsing request to the document parsing engine; Step S6: Record the parsing request artifact or parsing attempt record, and receive the external parsing task identifier returned by the document parsing engine; Step S7: Obtain the parsing status based on the external parsing task identifier, and obtain the parsing result after the parsing is completed; Step S8: Generate parsing result workpiece records and establish the association between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records; Step S9: Record the lifecycle events of the document parsing task, and perform phased verification of the parsing process based on the lifecycle events; Step S10: Based on the source file artifact record, normalized PDF artifact record, parsing request record, parsing result artifact record, and lifecycle events, form a document parsing artifact chain.

2. The multi-format document parsing and verification method according to claim 1, characterized in that, The document to be parsed includes PDF documents, Word documents, or other office documents that can be converted to PDF; the source file artifact record includes at least one or more of the following: file identifier, file name, file storage address, file type, file size, file hash value, upload time, and task identifier.

3. The multi-format document parsing and verification method according to claim 1, characterized in that, Document type identification is accomplished based on one or more of the following methods: file extension, content type, file header features, and file metadata. The method for determining a normalized PDF file is as follows: when the document to be parsed is a PDF, the file corresponding to the source file artifact is determined to be a normalized PDF file; when the document to be parsed is not a PDF, the document conversion engine is invoked to convert the document to be parsed into a normalized PDF file.

4. The multi-format document parsing and verification method according to claim 3, characterized in that, Normalization of non-PDF documents is performed in asynchronous tasks; when performing format conversion, the document conversion engine allocates an independent working directory, input directory, output directory, and runtime configuration directory for each conversion task.

5. The multi-format document parsing and verification method according to claim 1, characterized in that, The validity verification includes at least one of the following: verifying whether a standardized PDF file exists, verifying whether the file size is greater than a preset threshold, verifying whether the file header conforms to the PDF format, calculating and recording the file hash value, verifying whether the conversion process times out, and verifying whether the conversion output path matches the task record.

6. The multi-format document parsing and verification method according to claim 1, characterized in that, The normalized PDF artifact record includes one or more of the following: file identifier, file name, storage address, file size, hash value, generation method, source file identifier, and generation time of the normalized PDF file; the association is established in the following way: for PDF type documents to be parsed, the source file artifact record and the normalized PDF artifact record point to the same file; for non-PDF type documents to be parsed, the normalized PDF artifact record points to the PDF file generated by the document conversion engine.

7. The multi-format document parsing and verification method according to claim 1, characterized in that, The parsing request includes one or more of the following: normalized PDF file address, parsing parameters, task identifier, page number range, language parameters, table parsing parameters, and formula parsing parameters.

8. The multi-format document parsing and verification method according to claim 1, characterized in that, The parsing attempt record includes one or more of the following: task identifier, number of attempts, parsing engine identifier, submission time, request parameters, external parsing task identifier, submission status, and error information.

9. The multi-format document parsing and verification method according to claim 1, characterized in that, The parsing results include one or more of the following: a result compressed package, Markdown text, a content block list, page layout data, and intermediate structure files. The content block list includes structural units such as text blocks, heading blocks, table blocks, and image blocks, along with their page numbers, position information, or bounding box information. The page layout data includes page size, page order, page element coordinates, and intermediate output from the parsing model. The content block list in the parsing results contains page indexes and bounding box information. Based on the page size of the normalized PDF file, the bounding box information in the content block list is converted to page coordinates consistent with those of the normalized PDF file.

10. The multi-format document parsing and verification method according to claim 1, characterized in that, The parsing result artifact record includes one or more of the following: result file type, result file address, file size, file hash value, task identifier, parsing attempt identifier, and generation time.

11. The multi-format document parsing and verification method according to claim 1, characterized in that, The lifecycle events include one or more of the following: source file reception event, document type identification event, normalization processing start event, normalization processing success event, normalization processing failure event, normalized PDF verification event, parsing request submission event, parsing status polling event, parsing result acquisition event, parsing result registration event, task completion event, and task failure event.

12. The multi-format document parsing and verification method according to claim 1, characterized in that, The phased verification includes at least one of the following: Verify that the source file workpiece record exists; Verify that the standardized PDF workpiece record exists and passes the validity check. Verify whether the input file referenced by the parsing request is the normalized PDF file; Verify whether the parsed workpiece is associated with the same task identifier or the same parsing attempt identifier; Verify whether the page structure information in the parsing results corresponds to the standardized PDF file; Verify whether the task lifecycle events cover the preset key stages; When any critical stage is missing, fails, or the workpiece relationship is inconsistent, a corresponding error state and error event are generated.

13. The multi-format document parsing and verification method according to claim 1, characterized in that, The document parsing artifact chain is used to support parsing task tracking, failure stage location, result verification, page preview, parsing result backtracking, and subsequent archiving processing.

14. A multi-format document parsing and verification system, characterized in that, The system includes: The document access and source workpiece registration module is used to receive the document to be parsed and generate the source file workpiece record corresponding to the document to be parsed; The type recognition and normalization conversion module is used to identify the document type of the document to be parsed and determine the normalized PDF file based on the document type; A standardized document validity verification module is used to verify the validity of the standardized PDF file; The standardized workpiece registration and primary association module is used to generate standardized PDF workpiece records and establish the association between the source file workpiece records and the standardized PDF workpiece records; The parsing engine integration and request submission module uses the standardized PDF file as a unified input file to submit a parsing request to the document parsing engine. The parsing attempt log and token acquisition module is used to record parsing request artifacts or parsing attempt logs, and to receive external parsing task identifiers returned by the document parsing engine; The parsing status tracking and result extraction module is used to obtain the parsing status based on the external parsing task identifier, and to obtain the parsing result after the parsing is completed; The result workpiece registration and multidimensional association module is used to generate parsing result workpiece records and establish the association relationship between the parsing result workpiece records and the source file workpiece records, normalized PDF workpiece records, and parsing request records; The lifecycle monitoring and stage verification module is used to record lifecycle events of the document parsing task and perform stage-based verification of the parsing process based on the lifecycle events. The end-to-end workpiece traceability and synthesis module is used to form a document parsing workpiece chain based on the source file workpiece record, standardized PDF workpiece record, parsing request record, parsing result workpiece record, and lifecycle events.

15. A computer system comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the multi-format document parsing and verification method as described in any one of claims 1-13.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-format document parsing and verification method as described in any one of claims 1-13.

17. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the multi-format document parsing and verification method as described in any one of claims 1-13.

Images