Evidence citation processing method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application provide a kind of evidence cited processing method, device, electronic equipment and storage medium.The method comprises: obtaining the reference bytecode of target document and first document content;According to reference bytecode, the first document content is checked, and checking result is obtained;In the case where checking result is not passed, generate evidence citation exception report;In the case where checking result is passed, according to first document content and reference bytecode, determine evidence object.The scheme can establish the stable binding between reference information and document content, improve the consistency, accuracy and automation degree of evidence citation verification, and enhance the abnormal discovery ability and the traceability and reproducibility of historical verification result.

Description

Technical Field

[0001] This application relates to the field of data processing, and more particularly to a method, apparatus, electronic device, and storage medium for processing evidence citations. Background Technology

[0002] Related document management and retrieval systems typically use text pointers such as URLs, document identifiers, and page number annotations to handle document references, and combine them with format parsing rules for reference location and verification.

[0003] However, this type of citation method lacks directly executable location and extraction descriptions. During programmatic verification, it still relies on natural language parsing and manual rule adaptation, resulting in inconsistent parsing standards between different document formats and easy location deviations. At the same time, the citation lacks a stable correlation with the document content version. When the document is updated and the multi-level heterogeneous storage is refreshed asynchronously, version misalignment can easily occur between the verification results and the actual content, and it is difficult to reliably reproduce historical verification results.

[0004] Therefore, how to improve the accuracy and reproducibility of programmatic verification of document citations while ensuring version consistency has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for processing evidence citations, in order to improve the accuracy and reproducibility of procedural verification of document citations, while also ensuring version consistency.

[0006] Firstly, this application provides a method for processing evidence citations, the method comprising:

[0007] Obtain the referenced bytecode of the target document and the content of the first document;

[0008] Based on the referenced bytecode, the content of the first document is validated to obtain the validation result;

[0009] If the verification result is that the verification fails, an evidence citation anomaly report will be generated;

[0010] If the verification result is successful, the evidence object is determined based on the content of the first document and the referenced bytecode.

[0011] In one possible embodiment, the referenced bytecode includes an opcode sequence, and the evidence object is determined based on the first document content and the referenced bytecode, including:

[0012] The execution result is determined based on the content of the first document and the opcode sequence;

[0013] The execution result is encapsulated to obtain the evidence object.

[0014] In one possible embodiment, determining the execution result based on the first document content and the opcode sequence includes:

[0015] Based on the opcode sequence and the content of the first document, determine the referenced text area corresponding to the target document;

[0016] Based on the preset transformation function registry and referenced text area, determine the standardized text;

[0017] Determine the fingerprint information of the opcode sequence;

[0018] The execution result is determined based on the standardized text and fingerprint information.

[0019] In one possible embodiment, the referenced bytecode includes a first hash value. Based on the referenced bytecode, the content of the first document is verified to obtain a verification result, including:

[0020] Determine the second hash value based on the content of the first document;

[0021] Determine if the first hash value is the same as the second hash value;

[0022] If so, then the verification result is determined to be successful.

[0023] If not, then the verification result is determined to be verification failed.

[0024] In one possible embodiment, the referenced bytecode is obtained by performing a first processing on the target document;

[0025] The first process includes:

[0026] In response to the received reference descriptor, retrieve the content of the second document corresponding to the target document;

[0027] The reference descriptor is parsed and the opcode is mapped to obtain the opcode sequence.

[0028] Generate the first hash value based on the content of the second document;

[0029] Based on the first hash value and the opcode sequence, a reference bytecode is generated.

[0030] In one possible embodiment, the reference descriptor is parsed and opcode mapped to obtain an opcode sequence, including:

[0031] The reference descriptor is parsed to obtain parsed data, which includes the media type;

[0032] Determine the target opcode based on the media type;

[0033] Based on the target opcode, the parsed data is processed by opcode mapping to obtain the opcode sequence.

[0034] In one possible embodiment, generating reference bytecode based on the first hash value and the opcode sequence includes:

[0035] Determine the anchor hash value based on the reference descriptor;

[0036] The check segment is determined based on the anchor hash value and the opcode sequence;

[0037] Generate reference bytecode based on the anchor hash value, the first hash value, the opcode sequence, and the check segment.

[0038] Secondly, this application provides an evidence citation processing apparatus, the apparatus comprising:

[0039] The acquisition module is used to obtain the referenced bytecode of the target document and the content of the first document;

[0040] The determination module is used to verify the content of the first document based on the referenced bytecode and obtain the verification result;

[0041] The first generation module is used to generate an evidence citation anomaly report when the verification result is that the verification fails.

[0042] The second generation module is used to determine the evidence object based on the content of the first document and the referenced bytecode if the verification result is successful.

[0043] In one possible embodiment, the referenced bytecode includes an opcode sequence, and the second generation module is specifically used for:

[0044] The execution result is determined based on the content of the first document and the opcode sequence;

[0045] The execution result is encapsulated to obtain the evidence object.

[0046] In one possible embodiment, the second generation module is specifically used for:

[0047] Based on the opcode sequence and the content of the first document, determine the referenced text area corresponding to the target document;

[0048] Based on the preset transformation function registry and referenced text area, determine the standardized text;

[0049] Determine the fingerprint information of the opcode sequence;

[0050] The execution result is determined based on the standardized text and fingerprint information.

[0051] In one possible embodiment, the referenced bytecode includes a first hash value, and the determining module is specifically used for:

[0052] Determine the second hash value based on the content of the first document;

[0053] Determine if the first hash value is the same as the second hash value;

[0054] If so, then the verification result is determined to be successful.

[0055] If not, then the verification result is determined to be verification failed.

[0056] In one possible embodiment, the referenced bytecode is obtained by performing a first processing on the target document; the first processing module is used to:

[0057] In response to the received reference descriptor, retrieve the content of the second document corresponding to the target document;

[0058] The reference descriptor is parsed and the opcode is mapped to obtain the opcode sequence.

[0059] Generate the first hash value based on the content of the second document;

[0060] Based on the first hash value and the opcode sequence, a reference bytecode is generated.

[0061] In one possible embodiment, the first processing module is specifically used for:

[0062] The reference descriptor is parsed to obtain parsed data, which includes the media type;

[0063] Determine the target opcode based on the media type;

[0064] Based on the target opcode, the parsed data is processed by opcode mapping to obtain the opcode sequence.

[0065] In one possible embodiment, the first processing module is specifically used for:

[0066] Determine the anchor hash value based on the reference descriptor;

[0067] The check segment is determined based on the anchor hash value and the opcode sequence;

[0068] Generate reference bytecode based on the anchor hash value, the first hash value, the opcode sequence, and the check segment.

[0069] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0070] The memory stores instructions that the computer executes;

[0071] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0072] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0073] Fifthly, this application provides a computer program product, including a computer program that, when executed by a computer, implements the method as described in any of the first aspects.

[0074] This application provides a method, apparatus, electronic device, and storage medium for processing evidence citations. By acquiring the citation bytecode of the target document and the content of the first document, and verifying the content of the first document based on the citation bytecode, it can determine whether the citation is consistent with the document content in advance during the evidence citation processing. By generating an evidence citation anomaly report when the verification fails, and determining the citation evidence object based on the content of the first document and the citation bytecode when the verification passes, it can effectively identify abnormal citations and accurately extract valid citations, thereby improving the accuracy and reproducibility of procedural verification of document citations and enhancing version consistency assurance. Attached Figure Description

[0075] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0076] Figure 1 A schematic diagram of the structure of an evidence citation processing system provided in an embodiment of this application;

[0077] Figure 2 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 1 ;

[0078] Figure 3 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 2 ;

[0079] Figure 4 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 3 ;

[0080] Figure 5 A schematic diagram of the structure of an evidence citation processing device provided in an embodiment of this application;

[0081] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0082] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0083] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0084] It should be noted that although the terms "first," "second," etc., are used to describe various types of information in the embodiments of this application, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. Optionally, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information.

[0085] It should be understood that the terms "comprising" or "including" indicate the presence of the previously mentioned features, steps, or operations, but do not preclude the presence, occurrence, or addition of one or more other features, steps, or operations. The terms "and / or," etc., used in this application can be interpreted as inclusive, or mean any one or any combination thereof. Optionally, "A and / or B" means "any one of the following: A; B; A and B." Additionally, the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0086] Evidence citation processing technology is commonly used in scenarios such as financial compliance review, judicial electronic evidence management, scientific research literature tracing, and enterprise document management. In these scenarios, the system generally needs to locate, compare, and retain the cited content in the target document, focusing on document storage, document retrieval, and citation verification processes.

[0087] Document management and retrieval systems typically use text pointers such as URLs, document identifiers, and page number annotations to describe citation relationships, and combine these with format parsing rules to locate and extract data from PDF, HTML, and DOCX documents. Their workflow usually involves first finding the target document based on the citation identifier, then parsing page numbers, chapters, or path information according to preset rules, and finally outputting verification content or prompting for manual review.

[0088] However, the citation descriptions in this type of technical solution do not possess directly executable verification capabilities. The program still relies on natural language understanding, format adaptation rules, and human experience during verification. The parsing standards for different formats are difficult to unify, easily leading to positioning errors or inconsistent extraction results. Furthermore, there is a lack of stable binding between citation information and document content versions. When documents are revised, archived, or refreshed asynchronously across multi-level heterogeneous storage, even if the system completes the positioning, it may obtain content inconsistent with the original citation time.

[0089] The aforementioned deficiencies can further lead to problems such as difficulty in accurately verifying evidence citations, difficulty in timely identifying abnormal states, and difficulty in reproducing historical verification results stably. This is especially true in businesses that require the formation of audit records, compliance certificates, or judicial evidence chains, which can easily affect the credibility of the citation results and the efficiency of subsequent processing.

[0090] Improving the accuracy, anomaly detection capabilities, and reproducibility of results in procedural verification of evidence citation has become an urgent technical problem to be solved.

[0091] To address the aforementioned issues, a method for processing evidence citations is provided. This method obtains the citation bytecode of the target document and the content of a first document, verifies the first document content based on the citation bytecode, and generates an evidence citation anomaly report when verification fails. When verification passes, the evidence object is determined based on the first document content and the citation bytecode, thereby achieving standardized processing of evidence citations. This method can be deployed in a document processing architecture that includes document storage, citation bytecode processing, and verification output modules to improve the consistency and reliability of citation verification.

[0092] Below, in conjunction with Figure 1 The document provides an example of the evidence citation processing system in which the evidence citation processing method is located.

[0093] Figure 1 This is a schematic diagram of an evidence citation processing system provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 , Figure 1 It can include the compiler and the execution engine, as well as the communication connection between the compiler and the execution engine.

[0094] The compiler and execution engine work together to complete the entire process of evidence document citation compilation, legality verification, instruction execution, and batch optimization, ultimately achieving programmatic verification of evidence citations, anti-tampering of document versions, and idempotent replay capabilities of instructions.

[0095] The compiler can be used to receive reference descriptors from user input, compile the reference descriptors into a standardized sequence of opcodes, bind the corresponding target document's hash value, encapsulate and generate reference bytecode, and complete the standardized encapsulation and version binding of evidence reference information.

[0096] The execution engine can be used to load referenced bytecode, prioritize verifying the consistency of evidence document versions, execute opcodes in sequence after verification, maintain the runtime execution context, and call deterministic transformation functions to determine the evidence object.

[0097] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0098] Figure 2 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 1 The executing entity can be an evidence citation processing program deployed on a server, document management terminal, or electronic evidence processing platform. This program can establish data communication connections with the document storage system, metadata management module, and verification output module. Please refer to [link to relevant documentation]. Figure 2 The method includes:

[0099] S201. Obtain the referenced bytecode of the target document and the content of the first document.

[0100] The target document can be a PDF (Portable Document Format), HTML (HyperText Markup Language), DOCX (Office Open XML (Machine Learning) Document), OFD (Open Fixed-layout Document), or a structured document object that has been uniformly extracted.

[0101] Reference bytecode serves as a carrier for verifying and processing references to the target document. It contains the information required for subsequent processing, and its specific implementation can be a data object after encoding the reference information.

[0102] The content of the first document can be used as the object to be verified and the content to be extracted and referenced. It can be the full text content parsed from the target document, or it can be a collection of page-level, paragraph-level, chapter-level, table-level, or attachment-level content after being segmented according to the document structure.

[0103] The system can first receive a processing request for a target document, which includes the target document identifier, the referencing task identifier, or the business serial number. Based on this, the processing program accesses the document repository to read the referenced bytecode record associated with the target document and simultaneously reads the target version content of the target document.

[0104] In one possible embodiment, the reference bytecode can be a pre-stored data object.

[0105] In another possible embodiment, the referenced bytecode may also be obtained in real time when the target document is retrieved.

[0106] Regardless of the method used, a correspondence can be established between the referenced bytecode and the relevant content of the target document.

[0107] The acquisition of first document content includes document reading, format parsing, and content standardization.

[0108] For PDF documents, you can use a layout parser to extract text blocks, coordinates, font levels, and object order page by page.

[0109] For DOCX documents, the body text, comments, headers, footers, and embedded objects can be read according to the XML (Extensible Markup Language) structure.

[0110] For HTML documents, node content and paths can be extracted based on the DOM (Document Object Model) tree.

[0111] The read original content is further processed by unified encoding conversion, whitespace character normalization, newline character normalization, full-width and half-width character normalization, and invisible control character cleanup to form the first document content that can be verified later.

[0112] If the target document contains multilingual characters, scanned and recognized text, or areas with signatures, OCR (Optical Character Recognition) result merging, signature area removal rules, or image-text order reconstruction rules can be superimposed before standardization to ensure that the information recorded in the referenced bytecode corresponds to the actual text to be verified.

[0113] In one possible embodiment, the referenced bytecode and the content of the first document can be associated through the same document primary key.

[0114] In another possible embodiment, the two can also be associated using a combination key of the target document identifier and the version snapshot identifier.

[0115] When the system detects that the current version of the target document is inconsistent with the version of the referenced bytecode, it can directly read the archived copy of the corresponding version as the content of the first document to ensure that subsequent verification is based on consistent data.

[0116] Based on the above analysis, this step obtains the referenced bytecode and its corresponding first document content simultaneously, forming the input required for subsequent consistency checks, thereby causing the reference relationship to be processed around the corresponding content. It should be understood that the above example is merely illustrative and not limiting.

[0117] S202. Verify the content of the first document based on the referenced bytecode and obtain the verification result.

[0118] The verification result can be used to characterize the determination result of whether the content of the first document matches the referenced bytecode. Its generation process is to perform constraint verification on the content of the first document based on the referenced bytecode.

[0119] The referenced bytecode may contain one or more types of information for verification.

[0120] After parsing the referenced bytecode, the processing program can perform one or more verification processes on the content of the first document based on the information recorded therein.

[0121] The program can first identify the content of the first document based on the association information in the referenced bytecode. After successful identification, it can then read the reference location information from the referenced bytecode. Reference location information can include page numbers, chapter paths, paragraph indexes, anchor point identifiers, character offset ranges, table cell coordinates, or structural node paths. The processing program then locates candidate content areas within the first document content based on the parsing results corresponding to the document format.

[0122] For example, for a page number plus offset positioning method, you can first locate the target page and then extract the corresponding interval according to the standardized character sequence; for a structure path positioning method, you can address the node path level by level in the chapter tree or DOM tree; for an anchor point plus context positioning method, you can first match the anchor point text and then determine the precise segment boundary based on the context window.

[0123] If the candidate region does not exist, multiple regions with the same name exist, or the region boundary is inconsistent with the information recorded in the referenced bytecode, then the location is recorded as failed or ambiguous.

[0124] After locating candidate content, the processing program performs content consistency checks. Content consistency checks may include one or more of the following: exact text comparison, standardized text comparison, and contextual comparison.

[0125] Precise text comparison is suitable for scenarios where the target text is directly carried in the referenced bytecode. The system compares the candidate fragment with the text recorded in the referenced bytecode character by character.

[0126] Standardized text comparison is suitable for scenarios where formatting perturbations exist but semantic content remains unchanged. The system compares text after unifying capitalization, spaces, and punctuation.

[0127] Contextual comparison compares the text features within a preset length window before and after the target segment to confirm that the segment has not shifted in position due to document redesign but its content has been replaced.

[0128] Optionally, consistency can also be determined based on content features. Furthermore, integrity checks can examine candidate regions for deletions, insertions, truncations, page breaks, or missing structural nodes.

[0129] If the referenced bytecode records that the referenced object is a continuous segment, the system also needs to verify whether the start and end boundaries of the segment can be closed, and whether the length of the content between the boundaries falls within the allowed range.

[0130] After completing the above verifications, the system summarizes the results of each verification sub-result and generates the verification result.

[0131] The validation results can be binary results or structured result objects.

[0132] The structured result object includes at least an overall judgment status and a failure reason field. The overall judgment status indicates whether the verification passed or failed, and the failure reason field identifies which stage of association identification, location, text consistency or integrity the failure occurred in.

[0133] In one possible implementation, the overall determination status is set to "verification passed" only when both the location verification and content consistency verification pass.

[0134] In another possible embodiment, for documents that allow format normalization, verification can be considered passed when the standardized text comparison passes.

[0135] Based on the above analysis, this step transforms the abstract reference constraints in the bytecode into executable validation processing for the content of the first document. This changes the reliance on manual understanding of reference relationships to a reliance on deterministic rule-based judgment, thereby enabling the validation results to drive subsequent processing flows. It should be understood that the above example is merely illustrative and not limiting.

[0136] Optionally, the referenced bytecode includes a first hash value, and the content of the first document can be verified based on the referenced bytecode to obtain the verification result: determine the second hash value based on the content of the first document; determine whether the first hash value is the same as the second hash value; if so, the verification result is determined to be verification passed; if not, the verification result is determined to be verification failed.

[0137] In practical implementation, after receiving the referenced bytecode and the content of the first document, the content of the first document can be normalized first, and then a second hash value can be calculated based on the normalized content using a preset hash algorithm. The preset hash algorithm can be a collision-resistant hash algorithm such as SHA-256 (Secure Hash Algorithm 256), SHA-3 (Secure Hash Algorithm 3), or SM3 (SM3 Cryptographic Hash Algorithm). The content of the first document can be the full text read from document storage or a content fragment parsed from the target version, as long as it can reflect the actual content of the document to be verified.

[0138] When generating reference bytecode, the system writes the first hash value corresponding to the content of the target document into the bytecode payload area, and directly reads the first hash value for comparison during subsequent verification.

[0139] After the second hash value is generated, the system compares it bit by bit or with the first hash value in the referenced bytecode. If the two are completely consistent, it is determined that the content of the first document has not changed and the reference relationship has not changed, and the verification result is output. If any bit is inconsistent, it is determined that the content of the first document is inconsistent with the content version bound to the referenced bytecode, and the verification result is output.

[0140] The implementation module of the hash algorithm can be completed by software calling or hardware acceleration. In practical applications, other models of the selected algorithm can also be selected, and this application does not limit this.

[0141] In this process, the first hash value provides a content benchmark at the time of citation, while the second hash value reflects the current actual state of the first document's content. Comparing the two directly yields a content consistency conclusion, ensuring that subsequent determination of evidence objects is only performed when the content is consistent. Therefore, changes in document content can be promptly identified, and the verification conclusion can be stably reproduced with the current content state.

[0142] After adopting the above method, the verification of the first document content by referencing bytecode no longer relies on text position parsing or manual review, but directly gives the result through hash value consistency, which can improve the accuracy of content consistency judgment and make the results of verification pass and verification fail have clear and reproducible technical boundaries.

[0143] S203. If the verification result is that the verification fails, generate an evidence citation anomaly report.

[0144] The evidence citation anomaly report can be used to indicate citation anomalies when verification fails. It can take the form of a structured data record, an archiveable text report, or a combination of both.

[0145] After receiving the verification result output by S102, the processing program first determines the overall judgment status. When the overall judgment status is "verification failed", the evidence object generation process is stopped, and the exception report generation process is started.

[0146] The core data in an anomaly report should include at least the target document identifier, the referenced bytecode identifier, the verification task identifier, the verification time, the failure step identifier, and the failure details.

[0147] Among them, the failure details can record the actual value and expected value of inconsistent related information, or record the target path, page number and offset of the failed location, or record the difference information between the candidate fragment of the text comparison failure and the content of the referenced bytecode record.

[0148] You can first extract the failure reason code from the validation result object, and then fill in the corresponding fields according to the predefined exception template.

[0149] For example, when the failure is due to a mismatch in associated information, the report will include the current information of the target document, the corresponding information of the referenced bytecode, and the location of the data source being read.

[0150] When the failure is due to ambiguity in the location, the report should include the number of candidate regions, the coordinate range of each candidate region, or the structural path.

[0151] When the failure is due to inconsistencies in content, the report should include the relevant discrepancies.

[0152] If the approximate area has been located in the content of the first document, the report can also include the truncated text, page number and context fragment of the approximate area for subsequent manual review or secondary system judgment.

[0153] For scenarios with high auditing requirements, anomaly reports can also include processing node identifiers, executable program version numbers, host identifiers, and log index numbers for subsequent replay verification processes.

[0154] After an exception report is generated, it can be written to the exception report library according to preset storage rules and form an associated index with the target document and the referenced task.

[0155] When writing, an unmodifiable log format or an archive format with a timestamp signature can be used to make the report content traceable in subsequent audits.

[0156] If the business system requires an immediate response, the processing program can also push the exception report to the alarm queue, workflow pending module, or review task pool. The pushed data includes fields for exception level and handling suggestions.

[0157] The level of an anomaly can be automatically determined based on the cause of the failure. For example, mismatched related information and inconsistent content can be marked as high-level anomalies, while ambiguity in location can be marked as medium-level anomalies.

[0158] In batch processing mode, the system can generate multiple exception reports when a single target document corresponds to multiple referenced bytecodes, or it can aggregate them into a single composite report within the same task. However, each exception record still retains an independent bytecode identifier and failure context.

[0159] Based on the above analysis, this step does not generate further evidence objects when verification fails. Instead, it fixes the failure status as an anomaly report with document identifiers, relevant information, and detailed reasons. This allows states such as invalid references, inconsistent content, and decoupled relationships to be clearly identified and retained. With this processing, subsequent systems can directly locate the source of the anomaly based on the report without re-parsing the original reference description, and historical verification failure scenarios can be reproduced according to the recorded content. It should be understood that the above example is for demonstration purposes only and is not a limitation.

[0160] S204. If the verification result is successful, determine the evidence object based on the content of the first document and the referenced bytecode.

[0161] Evidence objects can be used to carry the referenced evidence determined after verification, and are a structured encapsulation of the verified referenced content.

[0162] After determining that the verification result is successful, the processing program combines the reference information in the referenced bytecode with the candidate areas in the first document content that have already passed the verification to determine the final referenced segment.

[0163] The determination process includes content extraction and result object construction.

[0164] The evidence object may include at least one or more of the following: referenced content, target document identifier, target document version information, referenced bytecode identifier, content location identifier, verification pass identifier, and generation time information.

[0165] The system can extract target fragments from the first document content based on boundary or location information recorded in the referenced bytecode. If the referenced object is text content, the text fragment is extracted according to character offset, paragraph index, or chapter node boundary; if the referenced object is table content, the table sub-region is extracted according to table number, row and column coordinates, and cell range; if the referenced object is an image, attachment, or signature area, the corresponding object or image area is extracted according to object identifier or page coordinates. After extraction, the system can associate the target fragment with relevant location information, document identifier information, and verification results to form evidence objects.

[0166] During the object construction phase, the above data can be assembled into a unified data structure, such as containing an object header and a content body.

[0167] The object header records the document identifier, version identifier, bytecode identifier, task identifier, and generation time; the body records the actual referenced content and its location description in the document.

[0168] If a referenced bytecode in the target document corresponds to multiple discrete fragments, the system can record a list of fragments in the same evidence object and record the position index for each fragment separately.

[0169] If the same processing task involves multiple target documents, each target document corresponds to an independent evidence object, avoiding cross-document mixed encapsulation.

[0170] Once the evidence objects are identified, they can be output to the evidence object repository, the business review page, or the subsequent evidence collection interface.

[0171] Storage can be achieved using a combination of structured records and original fragment attachments, or it can be done using a serialized object format.

[0172] If a chain of evidence is needed to be formed later, the system can also establish an association index between the current object and the original target document snapshot, verification record, and task flow information.

[0173] Based on the above analysis, this step, assuming the verification passes, extracts the content corresponding to the referenced bytecode from the first document content. This content, along with document information, location, and verification status, forms an evidence object. Therefore, the output not only includes the referenced content itself but also related information that can be used to further verify its source and generation conditions. It should be understood that the above example is merely illustrative and not limiting.

[0174] This embodiment provides a method for processing evidence citations. It obtains the citation bytecode of the target document and the content of a first document, verifies the content of the first document based on the citation bytecode, and obtains a verification result. If the verification result is a failure, an evidence citation anomaly report is generated; if the verification result is a success, the evidence object is determined based on the content of the first document and the citation bytecode. In this application, by obtaining the citation bytecode and establishing a correspondence between it and the content of the first document, and then performing procedural verification based on the relevant citation information, an anomaly report is output when verification fails, and an evidence object is output when verification succeeds, thus providing a unified execution standard for evidence citation processing. Therefore, positioning deviations caused by target document revisions, heterogeneous format differences, and unstable citation descriptions can be identified during the verification stage. Historical verification processes can be reproduced based on bytecode and report or object records, ensuring the accuracy of procedural verification of evidence citations, anomaly identification capabilities, and result reproducibility.

[0175] Below, in conjunction with Figure 3 The referenced bytecode includes the opcode sequence, and the process (204) of determining the evidence object based on the content of the first document and the referenced bytecode is explained.

[0176] Figure 3 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 2 Based on the above embodiments, see also Figure 3 The method includes:

[0177] S301. Determine the referenced text area of ​​the target document based on the opcode sequence and the content of the first document.

[0178] After obtaining the content of the first document and the opcode sequence, the system first parses the content of the first document according to the positioning rules corresponding to each opcode in the opcode sequence, and determines the referenced text area in the target document based on page number, paragraph identifier, offset, anchor character or structured markup.

[0179] S302. Determine the standardized text based on the preset transformation function registry and referenced text area.

[0180] It can read the transformation rules in the transformation function registry that match the referenced text region, and perform character normalization, format disambiguation and redundant symbol removal on the text in the region to obtain standardized text that is independent of version differences and display differences.

[0181] S303. Determine the fingerprint information of the opcode sequence.

[0182] The opcode sequence is encoded to generate fingerprint information that can characterize the sequence structure, sequence relationship and operation type combination features.

[0183] S304. Determine the execution result based on the standardized text and fingerprint information.

[0184] The execution result can be a verification result consistent with the referenced content, a reference confirmation result for retention, or result data for subsequent encapsulation processing.

[0185] Standardized text can be correlated and compared with fingerprint information, and the execution result can be determined accordingly.

[0186] By using the location results corresponding to the opcode sequence, along with the text standardization results and sequence fingerprint information, to determine the execution result, the system can maintain a consistent processing standard for the same citation under different formats, display methods, or slight layout changes, and ensure that the citation verification results have good reproducibility and stability. Since standardized text and fingerprint information jointly participate in result generation, the system has the ability to recognize both text content differences and opcode sequence differences, thereby improving the consistency of execution result determination.

[0187] S305. Encapsulate the execution result to obtain the evidence object.

[0188] The execution results can be encapsulated to generate evidence objects.

[0189] The encapsulation process can bind the execution result with the corresponding reference bytecode, document identifier, timestamp, processing mark and integrity check value, and write it into the evidence carrier in a preset data structure, so that the evidence object has the attributes of being searchable, verifiable and retainable.

[0190] If the execution result is multiple text fragments, they can be aggregated and packaged in a unified manner according to the order of citation, position, or logical relationship, so as to ensure that the evidence object can completely reproduce the original cited content during subsequent auditing or review.

[0191] For example, the object of evidence can be represented by the following formula. :

[0192]

[0193] in, Represents standardized text. Represents fingerprint information, Indicates the first hash value, Indicates the execution timestamp.

[0194] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0195] This embodiment provides a method for processing evidence citations. It involves determining the citation text region corresponding to the target document based on the opcode sequence and the content of a first document; determining standardized text based on a preset transformation function registry and the citation text region; determining the fingerprint information of the opcode sequence; determining the execution result based on the standardized text and the fingerprint information; and encapsulating the execution result to obtain the evidence object. Through this processing, the opcode sequence can directly drive the parsing and extraction of the first document content, forming a stable hierarchical relationship between the execution result and the evidence object. This preserves the intermediate states in the citation processing while standardizing the final output, thus ensuring the consistency and reproducibility of the generated citation evidence.

[0196] In one possible implementation, the referenced bytecode is obtained by first processing the target document.

[0197] Below, in conjunction with Figure 4 The process of the first treatment will be explained.

[0198] Figure 4 A flowchart illustrating an evidence citation processing method provided in this application embodiment. Figure 3 Based on the above embodiments, see also Figure 4 The method includes:

[0199] S401. In response to the received reference descriptor, obtain the content of the second document corresponding to the target document.

[0200] Reference descriptors can be entered by the user or generated automatically by the system.

[0201] Reference descriptors can contain document identifiers, versions, media types, location descriptions, selection operators, conditional predicates, and transformation functions.

[0202] Upon receiving a reference descriptor, the target document associated with that reference descriptor can be retrieved from the document storage unit, and its second document content can be read.

[0203] S402. The reference descriptor is parsed to obtain the parsed data.

[0204] The parsed data includes media types.

[0205] The fields in the reference descriptor can be structurally decomposed, and the reference position, reference range, field type and version mark can be converted into an internal intermediate representation to obtain the parsed data.

[0206] S403. Determine the target opcode based on the media type.

[0207] Based on the media type, the mapping module can convert the intermediate representation into multiple opcodes according to preset encoding rules.

[0208] S404. Based on the target opcode, perform opcode mapping processing on the parsed data to obtain the opcode sequence.

[0209] The opcode mapping process can be implemented through table lookup, rule matching, or encoding template concatenation. The mapping rules corresponding to different media types are pre-written into the rule base. The system dynamically loads the parsing rules that match the media type at runtime and generates the opcode accordingly.

[0210] For example, opcode mapping can be implemented using Table 1:

[0211] Table 1

[0212]

[0213] The opcode sequence can be used for subsequent reference verification of the first document content and for constructing evidence objects.

[0214] Each opcode in the opcode sequence can be located, truncated, standardized, or normalized.

[0215] Based on the target opcode, opcode mapping processing is performed on the parsed data to convert the media type, location field, and associated field in the parsed data into an executable opcode encoding string, thereby obtaining the opcode sequence.

[0216] In this way, reference descriptors can be converted into opcode sequences with definite execution semantics, enabling reference information from different media types to be standardized and encoded within the same mapping framework. This improves the consistency and executability of reference processing and makes subsequent verification and validation results more reproducible.

[0217] S405. Generate the first hash value based on the content of the second document.

[0218] The first hash value can be calculated after normalizing the content of the second document. Normalization may include encoding standardization, handling of whitespace characters or line ending characters, to ensure that the same content generates consistent hash results in different storage environments.

[0219] S406. Determine the anchor hash value based on the reference descriptor.

[0220] Anchor hash values ​​can provide a baseline for generating check segments.

[0221] If the system uses a specific hash algorithm or encoding format, the algorithm or format can be determined according to the deployment environment configuration. In practical applications, other models can also be selected, and this application does not limit this.

[0222] After receiving the reference descriptor, you can first parse the reference location information within it and then calculate the anchor hash value accordingly.

[0223] S407. Determine the check segment based on the anchor hash value and the opcode sequence.

[0224] The check segment can solidify the correspondence between the opcode sequence and the anchor hash value.

[0225] The anchor hash value and opcode sequence can be input into the check segment generation module, and the check segment can be obtained by combining it with the preset check rules.

[0226] S408. Generate reference bytecode based on the anchor hash value, the first hash value, the opcode sequence, and the check segment.

[0227] Reference bytecode can encapsulate the anchor hash value, the first hash value, the opcode sequence, and the check segment in a unified manner, so that subsequent verification can restore the reference location information and verify the content consistency based on the same benchmark.

[0228] The referenced bytecode can be encapsulated using a combination of fixed-length and variable-length fields. The fixed-length fields are used to store the anchor hash value and check segment, while the variable-length fields are used to store the opcode sequence, so as to keep the field boundaries stable during parsing.

[0229] The anchor hash value, the first hash value, the opcode sequence, and the check segment are encapsulated to generate reference bytecode that can be used for storage, transmission, and verification, so that it can be directly interpreted and called in subsequent verification and execution processes.

[0230] For example, bytecode can be referenced using the following formula. :

[0231]

[0232] in, Indicates header information, Represents the opcode sequence. This indicates the check segment.

[0233] Among them, header information It can be determined using the following formula:

[0234]

[0235] in, This represents an 8-byte anchor hash value, which can be used to associate with the upper-level call context. It can represent a 16-byte first hash value, used for document version verification; The document version number is represented by 4 bytes, MediaType is represented by 2 bytes, and OpCount is represented by 2 bytes, indicating the number of opcodes.

[0236] At runtime, the resolution result of the reference descriptor determines the content of the opcode sequence, the content of the second document determines the calculation result of the first hash value, and the two together enter the bytecode generation logic to form a unique corresponding reference bytecode.

[0237] Because the referenced bytecode is bound to both the target document content characteristics and the reference processing instructions, the first hash value changes synchronously when the target document content changes, thus ensuring that the generated result remains consistent with the target document state.

[0238] Therefore, when performing verification or location based on the referenced bytecode, the reference relationship can be reconstructed in a unified encoding method, and the processing result consistent with the generation time can be output.

[0239] By adopting the above method, the reference bytecode contains baseline information and integrity constraint information that can be used for verification during generation, enabling the reference descriptor to be transformed into a structured and verifiable bytecode representation. In this way, subsequent verification processes can directly rely on the reference bytecode for matching and verification, reducing reliance on text parsing results and improving the stability and reproducibility of the reference results.

[0240] The implementation details of each step in this application embodiment can be found in the description of the corresponding steps or operations in the above method embodiments; repeated content will not be repeated.

[0241] This embodiment provides a method for processing evidence citations. In response to a received citation descriptor, the method obtains the content of a second document corresponding to the target document; parses the citation descriptor to obtain parsed data, including media type; determines the target opcode based on the media type; performs opcode mapping on the parsed data based on the target opcode to obtain an opcode sequence; generates a first hash value based on the second document content; determines an anchor hash value based on the citation descriptor; determines a check segment based on the anchor hash value and the opcode sequence; and generates citation bytecode based on the anchor hash value, the opcode sequence, and the check segment. Since the first hash value is generated from the second document content, and the opcode sequence is determined by the parsing and mapping results, consistent citation bytecode can be generated under the same rules for the same input, thereby improving the certainty and reproducibility of the citation processing results.

[0242] The following example illustrates the specific process of handling evidence citation.

[0243] For example, the compliance department of a financial institution is reviewing a reference in a contract that includes "see Article 15, Paragraph 2 of the Administrative Measures". The department needs to verify whether the reference refers to the latest "Administrative Measures for the Sale of Financial Products" which is currently in effect, and check whether the administrative measures have been recently updated, causing the reference to become invalid.

[0244] During the bytecode generation phase, the system can annotate the reference descriptors in the contract. Upon receiving the reference descriptor, the system retrieves the content of the second document corresponding to the target document. The target document is the PDF version 2 content of the management method document ID "FinReg_2023_SalesRule". The reference descriptor is then parsed to obtain parsed data containing the media type. This reference descriptor includes doc_id: "FinReg_2023_SalesRule", version: 2, media_type: PDF, locator: {type: SPAN, char_start: 4567, char_end:4689}, selector: {type: TEXT}, predicates: [], and transforms: [].

[0245] After parsing the reference descriptor, the target opcode is determined based on the media type (PDF format). Opcode mapping is then performed on the parsed data based on the target opcode, forming an opcode sequence. For this contract reference scenario, the LOCATE_SPAN opcode can be preferentially selected based on the PDF format and mapped to the opcode sequence [LOCATE_SPAN(4567,4689),SELECT_TEXT]. Here, LOCATE_SPAN(4567,4689) corresponds to the character offset range of 4567 to 4689 in Article 15, Paragraph 2 of the management regulations PDF, and SELECT_TEXT corresponds to the selected text span.

[0246] Subsequently, based on the content of the second document in version 2 of the management regulations PDF, a first hash value is generated, specifically its SHA-256 hash value H_content, and this is combined with the reference descriptor to determine the anchor hash value. A check segment is determined based on the anchor hash value and the opcode sequence, using CRC32. The anchor hash value, opcode sequence, and check segment are then combined to generate reference bytecode, ensuring that the reference bytecode contains the first hash value and the opcode sequence. The generated reference bytecode includes a 32-byte header containing AnchorHash=00000000000000000, H_content, version number 2, media type PDF, and opcode quantity 2. The final generated reference bytecode is stored in the compliance system.

[0247] In actual citation processing, the compliance system periodically executes archived citation bytecode and automatically detects citation invalidation within 24 hours of document updates. During execution, the system retrieves the citation bytecode of the target document and the content of the first document. The citation bytecode is stored in the compliance system, and the first document content is the current management regulations PDF content. The execution engine extracts the first hash value H_content from the citation bytecode and calculates the second hash value based on the first document content. This involves recalculating the SHA-256 hash value H'_content of the current content of the management regulations PDF and determining if the first hash value H_content is the same as the second hash value H'_content. If the first hash value and the second hash value are different, the verification result is determined to be a failure, and an evidence citation anomaly report is generated. In this financial compliance scenario, if the management regulations are updated to version 3, a version conflict anomaly ERRC_VERSION_CONFLICT is returned, triggering a compliance warning. If the first hash value and the second hash value are the same, the verification result is determined to be a success, and then citation resolution continues by combining the first document content and the opcode sequence.

[0248] After successful verification, the referenced text region corresponding to the target document is determined based on the opcode sequence and the content of the first document. The execution engine executes according to the opcode sequence order, first executing LOCATE_SPAN(4567,4689) to locate the character offset 4567-4689 in the Management Measures PDF, and then executing SELECT_TEXT to extract the text content within this range, i.e., the specific clause of Article 15, Paragraph 2. During execution, the execution context state is maintained, including the cursor position and the selected area content. The referenced text region is transformed according to the preset transformation function registry to obtain standardized text. In this example, transforms: [] in the reference descriptor corresponds to no transformation function, but the execution engine still calls the function in the deterministic transformation function registry to maintain consistency with the preset transformation function registry. Fingerprint information is determined from the opcode sequence, and the execution result is determined based on the standardized text and fingerprint information. After obtaining the execution result, the execution result is encapsulated to form an evidence object, and this evidence object is identified as an evidence object; this evidence object is a standardized evidence object, containing standardized text, fingerprint information, document version, and execution timestamp.

[0249] When the compliance system needs to verify references in multiple contracts simultaneously, the execution engine performs batch parallel scheduling on multiple reference bytecodes.

[0250] The concurrent execution of N referenced bytecode is scheduled according to the following formula:

[0251]

[0252] in, This represents the optimal policy scheduling. This means iterating through all possible execution sorting schemes corresponding to N referenced bytecode and selecting the execution order that minimizes the result of the subsequent summation expression. Indicates a reference to bytecode. Indicate execution The time overhead of loading the document parser during the task.

[0253] If the condition Establishment, that is If the corresponding document ID is different from the document ID of the previous ERBC, the function value will be 1, which will add the parser loading time.

[0254] If the condition If this is not true, and the preceding and following ERBC calls belong to the same document, then the function value is 0, and there is no need to reload the parser, resulting in no additional overhead.

[0255] In the scenario of verifying 200 contract references, the reference bytecodes are first grouped and sorted by document ID. Multiple reference bytecodes from the same document are executed first, including multiple reference bytecodes from the management method "FinReg_2023_SalesRule", to reduce the overhead of repeated loading by the PDF parser. During execution, a caching strategy is used to store parsed PDF content. The cached objects include parsed version 2 of the management method, with a cache capacity of 32 documents. When multiple reference bytecodes corresponding to the same version 2 of the management method PDF are executed consecutively, the parsed PDF content is retained in the cache and repeatedly invoked, so that the system only needs to parse the management method PDF once when verifying 200 contract references. For new parsing documents entering the cache, they are directly written to the cache before the cache reaches 32 documents. After the cache reaches 32 documents, the cache content is updated according to the caching strategy, and the least used parsed PDF content is removed. Then, hash verification, opcode interpretation and execution, standardized text generation, execution result determination, and evidence object encapsulation are performed based on the content of the first document in the cache.

[0256] Figure 5 This is a schematic diagram of an evidence citation processing device provided in an embodiment of this application. Please refer to... Figure 5 The evidence citation processing device 500 includes an acquisition module 501, a determination module 502, a first generation module 503, and a second generation module 504.

[0257] Module 501 is used to obtain the referenced bytecode of the target document and the content of the first document;

[0258] The determination module 502 is used to verify the content of the first document based on the referenced bytecode and obtain the verification result;

[0259] The first generation module 503 is used to generate an evidence citation anomaly report when the verification result is that the verification fails.

[0260] The second generation module 504 is used to determine the evidence object based on the content of the first document and the referenced bytecode if the verification result is that the verification passed.

[0261] In one possible embodiment, the referenced bytecode includes an opcode sequence, and the second generation module 504 is specifically used for:

[0262] The execution result is determined based on the content of the first document and the opcode sequence;

[0263] The execution result is encapsulated to obtain the evidence object.

[0264] In one possible embodiment, the second generation module 504 is specifically used for:

[0265] Based on the opcode sequence and the content of the first document, determine the referenced text area corresponding to the target document;

[0266] Based on the preset transformation function registry and referenced text area, determine the standardized text;

[0267] Determine the fingerprint information of the opcode sequence;

[0268] The execution result is determined based on the standardized text and fingerprint information.

[0269] In one possible embodiment, the referenced bytecode includes a first hash value, and the determining module 502 is specifically used for:

[0270] Determine the second hash value based on the content of the first document;

[0271] Determine if the first hash value is the same as the second hash value;

[0272] If so, then the verification result is determined to be successful.

[0273] If not, then the verification result is determined to be verification failed.

[0274] In one possible embodiment, the apparatus includes a first processing module, wherein the referenced bytecode is obtained by performing a first processing on the target document; the first processing module 505 is configured to:

[0275] In response to the received reference descriptor, retrieve the content of the second document corresponding to the target document;

[0276] The reference descriptor is parsed and the opcode is mapped to obtain the opcode sequence.

[0277] Generate the first hash value based on the content of the second document;

[0278] Based on the first hash value and the opcode sequence, a reference bytecode is generated.

[0279] In one possible embodiment, the first processing module 505 is specifically used for:

[0280] The reference descriptor is parsed to obtain parsed data, which includes the media type;

[0281] Determine the target opcode based on the media type;

[0282] Based on the target opcode, the parsed data is processed by opcode mapping to obtain the opcode sequence.

[0283] In one possible embodiment, the first processing module 505 is specifically used for:

[0284] Determine the anchor hash value based on the reference descriptor;

[0285] The check segment is determined based on the anchor hash value and the opcode sequence;

[0286] Generate reference bytecode based on the anchor hash value, the first hash value, the opcode sequence, and the check segment.

[0287] This embodiment provides an evidence citation processing device that can execute the methods provided in the above-described method embodiments. Its implementation principle and technical effects are similar, and will not be described in detail here.

[0288] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Please refer to... Figure 6 The electronic device 600 may include: a memory 601, a processor 602, and a transceiver 603.

[0289] Memory 601 is used to store program instructions;

[0290] The processor 602 is used to execute the program instructions stored in the memory so that the electronic device 600 performs the above-described method.

[0291] Transceiver 603 may include a transmitter and / or a receiver. The transmitter may also be referred to as a transmitter, transmitter port, or transmitter interface, and the receiver may also be referred to as a receiver port, receiver interface, or similar descriptions. Exemplarily, memory 601, processor 602, and transceiver 603 are interconnected via bus 604.

[0292] This application also provides a computer program product that can be executed by a processor, and when the computer program product is executed, the above-described method can be implemented.

[0293] The evidence citation processing apparatus, electronic device, computer-readable storage medium, and computer program product in the embodiments of this application can execute the technical solutions shown in the above-described evidence citation processing method embodiments. Their implementation principles and beneficial effects are similar and will not be repeated here.

[0294] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0295] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0296] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0297] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0298] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0299] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0300] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0301] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0302] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for processing evidence citations, characterized in that, The method includes: Obtain the referenced bytecode of the target document and the content of the first document; Based on the referenced bytecode, the content of the first document is verified to obtain the verification result; If the verification result is that the verification fails, an evidence citation anomaly report is generated; If the verification result is successful, the evidence object is determined based on the content of the first document and the referenced bytecode.

2. The method according to claim 1, characterized in that, The referenced bytecode includes an opcode sequence. Based on the content of the first document and the referenced bytecode, the evidence object is determined, including: The execution result is determined based on the content of the first document and the opcode sequence; The execution result is encapsulated to obtain an evidence object.

3. The method according to claim 2, characterized in that, Based on the content of the first document and the opcode sequence, the execution result is determined, including: Based on the opcode sequence and the content of the first document, the referenced text area corresponding to the target document is determined; Based on the preset transformation function registry and the referenced text area, the standardized text is determined; Determine the fingerprint information of the opcode sequence; The execution result is determined based on the standardized text and the fingerprint information.

4. The method according to any one of claims 1-3, characterized in that, The referenced bytecode includes a first hash value. Based on the referenced bytecode, the content of the first document is verified to obtain a verification result, including: Determine the second hash value based on the content of the first document; Determine whether the first hash value is the same as the second hash value; If so, then the verification result is determined to be a successful verification; If not, then the verification result is determined to be a verification failure.

5. The method according to any one of claims 1-3, characterized in that, The referenced bytecode is obtained by performing a first processing on the target document; The first process includes: In response to the received reference descriptor, the content of the second document corresponding to the target document is obtained; The reference descriptor is parsed and the opcode is mapped to obtain an opcode sequence; Generate a first hash value based on the content of the second document; Reference bytecode is generated based on the first hash value and the opcode sequence.

6. The method according to claim 5, characterized in that, The reference descriptor is parsed and opcode mapped to obtain an opcode sequence, including: The reference descriptor is parsed to obtain parsed data, which includes the media type; Determine the target opcode based on the media type; Based on the target opcode, the parsed data is subjected to opcode mapping processing to obtain an opcode sequence.

7. The method according to claim 5, characterized in that, Based on the first hash value and the opcode sequence, reference bytecode is generated, including: Determine the anchor hash value based on the reference descriptor; The check segment is determined based on the anchor hash value and the opcode sequence; Reference bytecode is generated based on the anchor hash value, the first hash value, the opcode sequence, and the check segment.

8. A processing apparatus for evidence citation, characterized in that, The device includes: The acquisition module is used to obtain the referenced bytecode of the target document and the content of the first document; The determination module is used to verify the content of the first document based on the referenced bytecode and obtain the verification result; The first generation module is used to generate an evidence citation anomaly report when the verification result is that the verification fails. The second generation module is used to determine the evidence object based on the content of the first document and the referenced bytecode, if the verification result is that the verification passed.

9. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images