File retrieval method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a file retrieval method and device, a nonvolatile storage medium and electronic equipment. The method comprises the steps that a file retrieval request is received, and the file retrieval request carries a service scene to which a to-be-retrieved file belongs; the retrieval request is analyzed through a mapping relation model, a file category list is obtained, the file category list is used for recording file types meeting the service scene, and the mapping relation model is constructed according to the mapping relation between the file types and the service scene; a file pool corresponding to the target user identifier is determined, a target file of a target type is searched in the file pool according to the file category list, the target user identifier is used for indicating an object for sending the file retrieval request, and each file pool is used for uniquely recording all files associated with one user identifier; the target type is a file type recorded in the file type list. According to the method and the device, the technical problem of low file retrieval efficiency in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of information management technology, and more specifically, to a method and apparatus for retrieving documents, a non-volatile storage medium, and an electronic device. Background Technology

[0002] In the enterprise service sector, processing various business applications often requires collecting and submitting a large number of documents, which are diverse and frequently updated. Current document management methods scatter these documents across different systems or platforms and lack effective classification and tagging systems, resulting in low retrieval efficiency and long search times when searching through massive amounts of data.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a method and apparatus for retrieving files, a non-volatile storage medium, and an electronic device, to at least solve the technical problem of low file retrieval efficiency in related technologies.

[0005] According to one aspect of the embodiments of this application, a method for retrieving files is provided, comprising: receiving a file retrieval request, wherein the file retrieval request carries a business scenario to which the file to be retrieved belongs; analyzing the retrieval request using a mapping relationship model to obtain a file category list, wherein the file category list is used to record file types that satisfy the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios; determining a file pool corresponding to a target user identifier, and searching for a target file of a target type in the file pool according to the file category list, wherein the target user identifier is used to indicate the object that sent the file retrieval request, each file pool is used to uniquely record all files associated with a user identifier, and the target type is the file type recorded in the file category list.

[0006] Optionally, the mapping relationship model is constructed using the following methods: Obtaining historical business data, which includes multiple business scenarios, multiple historical business objects, and historical files used in each business scenario. Historical business objects include users who use historical files within a business scenario. Determining multiple transaction records based on the historical business data, where each transaction record records related business scenarios, historical files, and historical business objects. For each historical business object, determining a set of file types associated with each business scenario based on multiple transaction records, and defining the association between the business scenario and the set of file types as a mapping relationship between file types and business scenarios. The set of file types associated with each business scenario is obtained by iteratively filtering the types of multiple historical files associated with the business scenario. Finally, defining the data structure recording the mapping relationship as the mapping relationship model.

[0007] Optionally, the types of multiple historical files related to the business scenario are iteratively filtered, including: for each business scenario, in each iteration, iterative objects with support less than a preset support are deleted to obtain the remaining iterative objects. The remaining iterative objects are combined to obtain higher-order frequent itemsets until the iteration stops. The order of the higher-order frequent itemset is used to indicate the number of types contained in the higher-order frequent itemset. The higher-order frequent itemset output in each iteration increases by 1 compared to the number of types contained in the iterative object. The support is used to indicate the frequency of the iterative object appearing in the business scenario. The iterative object in the first iteration is each type, and the iterative object in subsequent iterations is the higher-order frequent itemset output in the previous iteration. The iteration stops when: the higher-order frequent itemsets in the previous iteration do not contain higher-order frequent itemsets with support greater than or equal to the preset support; the output of the previous iteration contains only one higher-order frequent itemset; and the target higher-order frequent itemset generated in the last iteration is a set of file types related to the business scenario.

[0008] Optionally, the file pool corresponding to each user identifier stores the fuzzy processing results of files used by the user in multiple business scenarios, the unique code of each file, and the storage path of each file in the file pool; searching for the target file of the target type in the file pool according to the file category list includes: combining the business scenario identifier contained in the file retrieval request and each file type recorded in the file category list into a query condition; for each query condition, matching the target storage path containing the query condition among the multiple storage paths recorded in the file pool; and determining the file indicated by the target storage path as the target file.

[0009] Optionally, the storage path is generated using the following method: for each file, the file type is encoded as a first encoding result, the business object associated with the file is encoded as a second encoding result, and the business scenario associated with the file is encoded as a third encoding result. The first encoding result, the second encoding result, the third encoding result, and the custom encoding are combined to form a unique encoding corresponding to the file. The custom encoding is used to indicate the order in which the unique encodings of the files are generated, and each file has a different custom encoding. The storage path of the file is generated based on the unique encoding and the file name.

[0010] Optionally, the fuzzing result of the file is obtained through the following method: obtaining multiple files used by a user in multiple business scenarios, as indicated by the user identifier corresponding to the file pool; for each file, determining key information in the content recorded in the file; determining the first area of ​​multiple independent regions recording the key information, and generating a graphic identifier code with an area equal to the first area based on the user identifier, wherein the first area is the sum of multiple independent regions; determining the second area and region number of each independent region, cutting the graphic identifier code into multiple sub-graphic identifier codes with an area equal to the second area, and marking the sub-graphic identifier codes using the region numbers of the independent regions corresponding to the sub-graphic identifier codes; filling each sub-graphic identifier code into the independent region corresponding to the sub-graphic identifier code according to the region number, thereby obtaining the fuzzing result of the file.

[0011] Optionally, the method further includes: if the target file is found, performing permission verification on the object that sent the file retrieval request and performing an operation corresponding to the permission verification result; if the target file is not found, returning a prompt message, wherein the prompt message is used to suggest supplementary files.

[0012] Optionally, permission verification is performed on the object sending the file retrieval request, including: querying the permissions of the object sending the file retrieval request in the permission record table to obtain the query results, wherein the permission record table is used to record the operation permissions of each file associated with each user identifier, and the operation permission types include at least one of the following: view, download, delete; if the query results indicate that the target user identifier is associated with the operation permissions of the target file, the permission verification result is determined to be verification passed; if the query results indicate that the target user identifier is not associated with the operation permissions of the target file, the permission verification result is determined to be verification failed.

[0013] Optionally, the operation corresponding to the permission verification result is performed, including: if the permission verification result is successful, deblurring the fuzzing result of each file stored in the file pool corresponding to the target user identifier to obtain the original file corresponding to the fuzzing result, and returning the original file, wherein the original file is the file used by the user indicated by the user identifier in multiple business scenarios; if the permission verification result is unsuccessful, returning the fuzzing result of each file stored in the file pool corresponding to the target user identifier.

[0014] Optionally, the fuzzing result includes: multiple sub-graphic identifier codes filled in multiple independent regions where multiple key information is located, and a region number carried by each sub-graphic identifier code, wherein each region number is associated with an independent region; the fuzzing result of each file stored in the file pool corresponding to the target user identifier is defuzzified, including: concatenating multiple sub-graphic identifier codes according to the region number carried by the sub-graphic identifier code to obtain a concatenated result; and converting the concatenated result into key information.

[0015] According to another aspect of the embodiments of this application, a file retrieval apparatus is also provided, comprising: a receiving module, configured to receive a file retrieval request, wherein the file retrieval request carries a business scenario to which the file to be retrieved belongs; a file category list generation module, configured to analyze the retrieval request using a mapping relationship model to obtain a file category list, wherein the file category list is used to record file types that satisfy the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios; and a file search module, configured to determine a file pool corresponding to a target user identifier, and search for a target file of the target type in the file pool according to the file category list, wherein the target user identifier is used to indicate the object that sent the file retrieval request, each file pool is used to uniquely record all files associated with a user identifier, and the target type is the file type recorded in the file category list.

[0016] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, in which a computer program is stored, wherein the above-described method for retrieving files is executed by running the computer program on the device where the non-volatile storage medium is located.

[0017] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to execute the above-described method for retrieving files through the computer program.

[0018] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the above-described method for retrieving files.

[0019] In this embodiment, a file retrieval request is received, which carries the business scenario to which the file to be retrieved belongs. A mapping relationship model is used to analyze the retrieval request to obtain a file category list. The file category list records file types that meet the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios. A file pool corresponding to a target user identifier is determined, and the target file of the target type is searched in the file pool according to the file category list. The target user identifier indicates the object that sent the file retrieval request. Each file pool uniquely records all files associated with a user identifier. The target type is the file type recorded in the file category list. By analyzing data, the mapping relationship between business scenarios and file types is discovered and established, forming a business scenario-file mapping relationship model. The mapping relationship model is used to intelligently match the files required under various business scenarios, thereby improving the efficiency of file retrieval and achieving the technical effect of improving business processing efficiency. This solves the technical problem of low file retrieval efficiency in related technologies. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a hardware structure block diagram of a computer terminal for implementing a file retrieval method according to an embodiment of this application;

[0022] Figure 2 This is a flowchart illustrating the steps of a document retrieval method according to an embodiment of this application;

[0023] Figure 3 A flowchart of constructing a mapping relationship model according to an embodiment of this application;

[0024] Figure 4 A schematic diagram of a transaction list according to an embodiment of this application;

[0025] Figure 5 A flowchart of an iterative generation of high-order frequent itemsets according to an embodiment of this application;

[0026] Figure 6 A structural diagram of a document retrieval device according to an embodiment of this application;

[0027] Figure 7 A flowchart illustrating the steps of a document retrieval apparatus according to an embodiment of this application. Detailed Implementation

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

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

[0030] In related technologies, within the enterprise service sector, account managers often need to collect and submit a large number of documents, such as business licenses, legal representative identification documents, and powers of attorney, when handling various business applications. These documents are not only diverse but also frequently updated, making management difficult. In related technologies, these documents are typically stored scattered across different systems or platforms, lacking unified centralized management and integration, and lacking an effective classification and tagging system, resulting in time-consuming document searches. Furthermore, account managers often need to remember the documents required for various business scenarios when handling business, and this method of manually classifying documents according to their corresponding business scenarios is unreliable, leading to low document retrieval accuracy. Additionally, in actual business processes, some types of documents (such as business licenses) are universal and reusable, but related technologies do not associate these documents with specific users, requiring them to be re-uploaded or provided each time a business is processed, resulting in low business processing efficiency. To address these issues, this application provides relevant solutions, which are detailed below.

[0031] According to an embodiment of this application, a method embodiment for document retrieval is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal for implementing a file retrieval method is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0033] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10. As involved in the embodiments of this application, the data processing circuits serve as a form of processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0034] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the file retrieval method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned file retrieval method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0036] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10.

[0037] This application provides a file retrieval method that can run in the above-described operating environment. Figure 2 This is a flowchart of the document retrieval method provided in the embodiments of this application, such as... Figure 2 As shown, the method includes the following steps:

[0038] Step S202: Receive a file retrieval request, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs.

[0039] The file retrieval method provided in this application embodiment uses an association analysis learning algorithm to construct a business scenario-attachment mapping relationship, automatically forming an efficient and unified user-level file pool management. By first locating the file pool and then retrieving files from the file pool, the file retrieval time is shortened, and the efficiency of file retrieval is improved. In step S202, a file retrieval request is received. The file retrieval request includes the following information: the identifier of the user / account sending the file retrieval request (i.e., user identifier), business scenario, etc. The file retrieval request is used to request the retrieval of files that meet business requirements. Whether the business requirements are met can be determined by the following method: whether the business scenario to which the file belongs is the business scenario recorded in the file retrieval request. If it is, the file meets the business requirements; if not, the file does not meet the business requirements. In this embodiment, business scenarios include: business application, business change, business cancellation, etc.

[0040] Step S204: Analyze the retrieval request using a mapping relationship model to obtain a file category list. The file category list records file types that meet the business scenario. The mapping relationship model is constructed based on the mapping relationship between file types and business scenarios.

[0041] In step S204, a mapping relationship model is used to analyze the retrieval request. The mapping relationship model is constructed based on the mapping relationship between file types and business scenarios. That is, the mapping relationship model knows which types of files are needed in which business scenarios. Therefore, the mapping relationship model generates a file category list based on the business scenarios recorded in the file retrieval request. The file category list output by the mapping relationship model records all file types used in the business scenarios recorded in the file retrieval request.

[0042] Optionally, the mapping relationship model is constructed using the following methods: Obtaining historical business data, which includes multiple business scenarios, multiple historical business objects, and historical files used in each business scenario. Historical business objects include users who use historical files within a business scenario. Determining multiple transaction records based on the historical business data, where each transaction record records related business scenarios, historical files, and historical business objects. For each historical business object, determining a set of file types associated with each business scenario based on multiple transaction records, and defining the association between the business scenario and the set of file types as a mapping relationship between file types and business scenarios. The set of file types associated with each business scenario is obtained by iteratively filtering the types of multiple historical files associated with the business scenario. Finally, defining the data structure recording the mapping relationship as the mapping relationship model.

[0043] The mapping relationship model used in step S204 is a data structure that stores the association between file types and business scenarios (i.e., mapping relationship). The association between file types and business scenarios (i.e., mapping relationship) is obtained through analysis of historical business data. Figure 3 This is a flowchart for constructing a mapping relationship model, such as... Figure 3 As shown, the process for constructing the mapping relationship model is as follows: First, according to the designed collection strategy, the required historical business data is collected from relevant business systems. The historical business data records the following information: business scenario, files submitted when processing various business scenarios before the current time (i.e., historical files), users / accounts who submitted historical files (i.e., historical business objects), users / accounts who downloaded historical files (i.e., historical business objects), and orders associated with historical files (i.e., historical business objects). For example, for the historical business data "when executing a business application before the current time, the user submitted a business license or other supporting documents," the business scenario is the business application scenario, the historical business object is the user who submitted the business license, and the business license or other supporting documents are historical files. In this embodiment, the historical business data uses a business scenario identifier to represent the business scenario, an object identifier (such as an identifier or order number) to represent the historical business object, and a file identifier to represent the historical file. Figure 3As shown, in the process of constructing the mapping relationship model, a transaction list is first generated based on the collected historical business data. Figure 4 This is a diagram of a transaction list, such as... Figure 4 As shown, the transaction list is a list of multiple transaction records generated based on historical business data. Each transaction record details related business scenarios, historical files, and historical business objects. Each transaction record includes a user identifier (referring to the corresponding historical business object), a business scenario identifier, and one or more attachments. For example, if a user uploads three files A, B, and C when completing a business task, this can be converted into a single transaction record: "User Identifier - Business Scenario Identifier - File Set {A, B, C}". Figure 4 In the transaction record, user ID 1001, business scenario ID (scenario A), and file IDs (file A, file B) form a transaction record. This indicates that user ID 1001 needs to use files A and B when performing business related to scenario A. Similarly, user ID 1002, business scenario ID (scenario A), and file IDs (file B, file C) form a transaction record. This indicates that user ID 1002 needs to use files C and B when performing business related to scenario A. User ID 1003... A transaction record is formed by the business scenario identifier (Scenario A) and file identifiers (File A, File B, File C). This indicates that when user ID 1003 performs business related to Scenario A, the required files are File A, File C, and File B. Similarly, a transaction record is formed by the business scenario identifier (Scenario A) and file identifiers (File A, File B, File C, File D). This indicates that when user ID 1004 performs business related to Scenario A, the required files are File A, File C, File B, and File D. Figure 4 As shown, after generating the transaction list, the mapping relationship between file types and business scenarios is analyzed based on the multiple transaction records recorded in the transaction list. Specifically, the set of file types associated with each business scenario is analyzed based on the transaction records, and the relationship between the file types recorded in the set of file types associated with the business scenario is determined as the mapping relationship between the business scenario and these file types. The set of file types may contain only one file type (a file type identifier). The set of file types associated with each business scenario can be generated by iteratively filtering the types of historical files recorded in multiple transaction records containing that business scenario.

[0044] Still Figure 3As shown, during the process of generating a transaction list based on historical business data, a data cleaning operation can also be added. Data cleaning is to remove invalid data, duplicate data, etc. contained in the collected historical business data. Invalid data includes null values, outliers, or data that does not conform to business rules.

[0045] According to some optional embodiments of this application, the types of multiple historical files that are related to a business scenario are iteratively filtered, including: for each business scenario, in each iteration, iterative objects with support less than a preset support are deleted to obtain the remaining iterative objects, and the remaining iterative objects are combined to obtain higher-order frequent itemsets, until the iteration stops. The order of the higher-order frequent itemset is used to indicate the number of types contained in the higher-order frequent itemset. The higher-order frequent itemset output in each iteration increases by 1 compared to the number of types contained in the iterative object. The support is used to indicate the frequency of the iterative object appearing in the business scenario. The iterative object in the first iteration is each type, and the iterative object in subsequent iterations is the higher-order frequent itemset output in the previous iteration. The iteration stops when: the higher-order frequent itemsets in the previous iteration do not contain higher-order frequent itemsets with support greater than or equal to the preset support; the output of the previous iteration contains only one higher-order frequent itemset; and the target higher-order frequent itemset generated in the last iteration is a set of file types related to the business scenario.

[0046] like Figure 3 As shown, in the process of constructing the mapping model, after generating the transaction list, based on the information recorded in the transaction list, a pruning operation is used to iteratively filter out the highest-order frequent itemset associated with each business scenario (i.e., the target high-order frequent itemset). The file types recorded in this target high-order frequent itemset are the file types (types) that have a mapping relationship with this business scenario. In this embodiment, when iteratively generating the target high-order frequent itemset, a combination of pruning and file type methods is used. Specifically, for each business scenario contained in the historical business data, each transaction record in the transaction list is traversed to determine multiple historical files associated with each business scenario in the transaction list. By analyzing the file types of these historical files, the set of file types associated with each business scenario is determined. Then, the set of file types is iterated to finally generate the target high-order frequent itemset. Figure 3 As shown, during the iterative filtering process, the following steps are performed in each iteration: determine the iteration object → calculate the support of the iteration object → prune the iteration object based on the support and the preset support → output the result of this iteration (at least one higher-order frequent itemset). Figure 5 This is a flowchart of iteratively generating higher-order frequent itemsets. Next, according to... Figure 5 To illustrate the iterative filtering process, for example... Figure 5As shown, in the first iteration, each (file) type related to the business scenario, determined by traversing the transaction list, is used as the iteration object. For example... Figure 5 Before starting the iteration, the process iterates through the transaction list to determine the (file) types related to the business scenario, including "M, N, P, Q". These file types form a candidate set of types; where M is... Figure 4 The file type of file A is recorded in the document, and N is... Figure 4 The file type of file B recorded in the document is P. Figure 4 The file type C is recorded in the document, and Q is... Figure 4 The file type D is recorded in the dataset. In the first iteration, M, N, P, and Q are each an iteration object. During the first iteration, the support for each file type is determined according to the support calculation formula: Support(X) = (Number of times X appears in the dataset) / (Total dataset size). Figure 5 As shown, according to the above formula, the support scores for types M, N, P, and Q are calculated to be 3 / 4, 4 / 4, 3 / 4, and 1 / 4, respectively. In the above support calculation formula, Support(X) represents the support score of X, where X is the iterable object. (The number of times X appears in the dataset refers to the number of times X appears in the transaction list, and the total dataset size is the number of transaction records contained in the transaction list.) Next, we will take the calculation of the support score for file type M of file A as an example to illustrate the method of calculating support. File A in... Figure 4 The number of occurrences in the transaction list shown is 3, and the transaction list contains 4 transaction records. Therefore, Support(M) = 3 / 4.

[0047] Next, pruning is performed based on the support of the iterative objects. Pruning means deleting iterative objects with support less than a preset support in each iteration. File type combination means combining iterative objects with support greater than or equal to the preset support (e.g., 0.5) (i.e., the remaining iterative objects). The result of the combination is a higher-order frequent itemset, which is the output of this iteration. In this embodiment, the preset support is set to 0.5. Figure 5As shown, during the first iteration, a pruning operation was performed, deleting iterable objects (type Q) with support less than 0.5. The remaining iterable objects were file types M, N, and P. After the combination operation, the result of this iteration was obtained: multiple high-order frequent itemsets. Each high-order frequent itemset will be used as the iterable object for the next iteration. That is, the file type set {M, N} composed of M and N, the file type set {M, P} composed of M and P, and the file type set {P, N} composed of P and N are all iterable objects for the next iteration. In this embodiment, the order of each high-order frequent itemset is used to indicate the number of file types contained in this high-order frequent itemset. For example, for the following three high-order frequent itemsets output in the first iteration: {M, N}, {M, P}, and {P, N}, their order is 2. In this embodiment, the stopping conditions for iterative filtering include two types: one is that no new higher-order frequent itemsets can be generated based on the result of the previous iteration, for example, the output of the previous iteration only contains one higher-order frequent itemset; the other is that during pruning, the support of all iterative objects (including a single file type and combinations of multiple file types (i.e., higher-order frequent itemsets) is less than the preset support. Figure 5 In the example shown, after multiple rounds of iterative filtering, the output set of file types associated with business scenario A (i.e., the target high-order frequent itemset) is: {M, N, P}.

[0048] Step S206: Determine the file pool corresponding to the target user identifier, and search for the target file of the target type in the file pool according to the file category list. The target user identifier is used to indicate the object that sent the file retrieval request. Each file pool is used to uniquely record all files associated with a user identifier. The target type is the file type recorded in the file category list.

[0049] After obtaining the file category list in step S204, in step S206, the (target) file of the (target) file type recorded in the file category list is retrieved from the file pool corresponding to the user who sent the retrieval request. The file types include: business licenses, contracts, agreements, etc. In this embodiment, the file pool is bound to a user / account, and each user identifier has a corresponding file pool. Therefore, the file pool to be retrieved can be determined by the unique identifier (i.e., the target user identifier) ​​of the object (user or account) that sent the file retrieval request. The files stored in each file pool are those used by the user / account corresponding to that file pool in multiple business scenarios during historical business processing; they are all files associated with the identifier information (i.e., the user identifier) ​​of the user / account corresponding to that file pool.

[0050] Optionally, the file pool corresponding to each user identifier stores the fuzzy processing results of files used by the user in multiple business scenarios, the unique code of each file, and the storage path of each file in the file pool; searching for the target file of the target type in the file pool according to the file category list includes: combining the business scenario identifier contained in the file retrieval request and each file type recorded in the file category list into a query condition; for each query condition, matching the target storage path containing the query condition among the multiple storage paths recorded in the file pool; and determining the file indicated by the target storage path as the target file.

[0051] As mentioned in the above embodiments, the files stored in each file pool are those used by the user / account corresponding to that file pool in multiple business scenarios during historical business processing. In this embodiment, the fuzzy processing results of the files stored in each file pool are also included. Furthermore, the file pool also stores the unique code of each file and the storage path of each file. In step S206, when searching for files (i.e., target files) of the file type (i.e., target type) recorded in the file category list in the file pool, files are matched in the file pool according to the query conditions. Specifically, the storage paths containing all the information recorded in the query conditions are filtered from the multiple storage paths recorded in the file pool, and the file indicated by the storage path containing all the information recorded in the query conditions (i.e., target path) is determined as the file to be retrieved (i.e., target file). The above query conditions are generated based on the business scenario identifier carried in the file retrieval request received in step S202 and the file types recorded in the file category list generated in step S204. Specifically, if the file retrieval request includes a business scenario identifier, the business scenario identifier is combined with each (file) type recorded in the file category list to form a query condition; if the file retrieval request includes multiple business scenario identifiers, step S204 will generate a corresponding file category list for each business scenario identifier, and combine each business scenario identifier with each file type recorded in its corresponding file category list to form a query condition; that is, for each business scenario, the number of generated query conditions is the same as the number of file types recorded in the file category list corresponding to that business scenario.

[0052] According to some optional embodiments of this application, the storage path is generated by the following method: for each file, the file type is encoded as a first encoding result, the business object associated with the file is encoded as a second encoding result, and the business scenario associated with the file is encoded as a third encoding result. The first encoding result, the second encoding result, the third encoding result, and the custom encoding are combined to form a unique encoding corresponding to the file. The custom encoding is used to indicate the order in which the unique encoding of the file is generated, and the custom encoding corresponding to each file is different. The storage path of the file is generated according to the unique encoding and the file name.

[0053] In this embodiment, the storage path recorded in the file pool is composed of the file's unique code and the file's original filename. The file's unique code is generated uniquely for each file using the unified encoding rules defined in this application embodiment. The unique encoding of a file is represented as a number, generated based on four types of information: user identifier, business scenario, file type, and custom encoding. The method for generating a unique encoding for each file is as follows: The identifier of the business object associated with the file (e.g., the user / account downloading the file) is encoded to obtain the user identifier encoding (i.e., the second encoding result); the file type is encoded to obtain the file type encoding (i.e., the first encoding result); the identifier of the business scenario applying the file (i.e., the business scenario associated with the file) is encoded to obtain the business scenario encoding (i.e., the third encoding result); and after determining the custom encoding corresponding to the file, the first, second, and third encoding results, this custom encoding, and the original file name (i.e., the original file name) are combined to generate the file's storage path. The file's storage path can be represented in the following form: " / user identifier (i.e., the second encoding result) / business scenario ID (i.e., the third encoding result) / file type ID (i.e., the first encoding result) / custom encoding_original file name", or in the following form: "file type encoding (i.e., the first encoding result)_business object encoding (i.e., the second encoding result)_business scenario encoding (i.e., the third encoding result)_custom encoding". To ensure that each file has a unique custom code, and to ensure that two files of the same type, associated business object, and associated business scenario have different storage paths, in this embodiment, the custom code can be an array used to indicate the order in which unique codes are generated for each file. For example, the custom code of the first file to generate a unique code is 1, and the custom code of the second file to generate a unique code is 2. The original file name refers to the name of the file when it is first entered into the file pool and no operation is performed on the file. For example, the files to be uniquely encoded include: business licenses, contracts / agreements, and operator identity documents submitted by user / account with user ID 1001 under business scenario A. Each file is encoded in the following order: first, the business license; second, the contract / agreement; and third, the operator identity document. If the encoding result for business scenario A is 2001, the encoding result for the business license is 3001, the encoding result for the contract / agreement is 3002, and the encoding result for the operator identity document is 3003, then the unique encoding for the business license is: “3001_1001_2001_001”, where 001 is a custom encoding, and the storage path for the business license can be represented as “3001_1001_2001_001_business license file”.

[0054] According to some optional embodiments of this application, the fuzzing result of the file is obtained by the following method: obtaining multiple files used by a user in multiple business scenarios, indicated by a user identifier corresponding to the file pool; for each file, determining key information in the content recorded in the file; determining the first area of ​​multiple independent regions recording the key information, and generating a graphic identifier code with an area equal to the first area based on the user identifier, wherein the first area is the sum of multiple independent regions; determining the second area and region number of each independent region, cutting the graphic identifier code into multiple sub-graphic identifier codes with an area equal to the second area, and marking the sub-graphic identifier codes using the region number of the independent region corresponding to the sub-graphic identifier code; filling each sub-graphic identifier code into the independent region corresponding to the sub-graphic identifier code according to the region number, thereby obtaining the fuzzing result of the file.

[0055] As mentioned in the above embodiments, the file pool stores the fuzzy processing results of each file. In this embodiment, Optical Character Recognition (OCR) technology or other file processing technologies can be used to perform fuzzy processing on each file to generate the fuzzy processing result. The fuzzy processing of files can be performed using the following method: For each file used by the user indicated by the user identifier in multiple business scenarios (such as files downloaded or uploaded when processing historical business), OCR technology is used to extract key information from the content recorded in the file. Key information includes character-based information, such as enterprise code, ID number, amount, date, etc. Next, based on the distribution of key information in the file, multiple independent rectangular regions are identified and divided in the file. Each independent region is a region that completely contains the key information but does not contain other information; it is a key information point. These independent regions will be used to generate graphic identification codes for fuzzy representation of the key information. In this embodiment, when generating a graphic identifier code based on the region (i.e., independent region) where each key information is located, the area of ​​multiple independent regions (i.e., the first area) is first determined. Further, a graphic identifier code with the same area as the sum of the areas of the multiple independent regions (i.e., the first area) is generated. The graphic identifier code with the area of ​​the first area records the user identifier and the key information extracted from the file; that is, the graphic identifier code with the area of ​​the first area is generated based on the user identifier associated with the file and the key information recorded in the file. Further, to ensure that each key information can be accurately blurred (completely blurring the key information but not blurring other information that is close to the key information), in this embodiment, the graphic identifier code with the same area as the sum of the areas (i.e., the first area) is divided into multiple sub-graphic identifier codes, and the area of ​​each sub-graphic identifier code is equal to the sum of the areas of the multiple independent regions (i.e., the first area). Each key piece of information belongs to an independent region with an area (i.e., a second area). Specifically, a region number is first generated for each independent region, which indicates the location of its corresponding independent region in the file. When dividing the graphic identifier code using the area (i.e., the second area) of each independent region, the region number of that independent region is marked in the resulting sub-graphic identifier code. Thus, each sub-graphic identifier code also carries a region number. In the final step of the fuzzing process, the location of each sub-graphic identifier code in the file is determined based on the region number it carries. The sub-graphic identifier code is then filled into the location indicated by its region number, thus achieving the fuzzification of the key information at the location indicated by the region number. After all the key information in a file has been fuzzified, the fuzzing result of the file can be obtained.

[0056] According to some alternative embodiments of this application, the method further includes: if the target file is found, performing permission verification on the object that sent the file retrieval request, and performing an operation corresponding to the permission verification result; if the target file is not found, returning a prompt message, wherein the prompt message is used to suggest supplementary files.

[0057] The method provided in this application adopts an access control mechanism: different users / accounts have different default access settings. For example, administrators usually have the highest access (level 1 access) and can view and manage all files in the file pool. Employees who have handled business in multiple business scenarios can view attachments associated with the business scenarios they have handled, while employees who have handled business in one business scenario can only view attachments associated with the business scenarios they have handled. However, only users / accounts whose access is verified can view and download the original file (the file without obfuscation) according to actual business needs. Therefore, even if the target file is found in the file pool in step S206, if the user wants to download or view the original file of the target file, it is necessary to verify the access of the object that sent the file retrieval request. The subsequent operations will be different depending on the access verification result. If the target file is not found in the file pool in step S206, a prompt message will be returned to the object that sent the file retrieval request. The prompt message is used to prompt the user to supplement the files associated with this business scenario (the business scenario recorded in the retrieval request).

[0058] Optionally, permission verification is performed on the object sending the file retrieval request, including: querying the permissions of the object sending the file retrieval request in the permission record table to obtain the query results, wherein the permission record table is used to record the operation permissions of each file associated with each user identifier, and the operation permission types include at least one of the following: view, download, delete; if the query results indicate that the target user identifier is associated with the operation permissions of the target file, the permission verification result is determined to be verification passed; if the query results indicate that the target user identifier is not associated with the operation permissions of the target file, the permission verification result is determined to be verification failed.

[0059] In this embodiment, the permission verification result is determined by querying the target user identifier (i.e., the identifier information of the object sending the file retrieval request) in the access control list (i.e., permission record table). The access control list (i.e., permission record table) records the operation permissions for each identifier on each file. For example, the access control list is a table where the first column contains a row storing a user identifier, the second column stores at least one file type identifier, and the third column stores at least one operation permission. There is a correlation between the user identifier, file type, and operation permission recorded in the same row of the access control list (i.e., permission record table). The user identifier represents a user who can perform one or more types of operations indicated by the operation permission in the same row on files of the same file type. These operations include: downloading (reading), viewing the original file, editing (writing), deleting, etc. In this embodiment, if the query result of the target user identifier in the access control list indicates that the target user identifier and the target file and their operation permissions are on the same line (i.e., they are associated), the permission verification result is successful. If the query result of the target user identifier in the access control list indicates that the target user identifier and the target file are not on the same line (i.e., they are not associated), or if the target user identifier and the target file are on the same line, but the operation permissions for this line are empty (when the operation permissions are empty, viewing the fuzzy processing result of the file is allowed), the permission verification result is unsuccessful.

[0060] The method provided in this application supports the dynamic adjustment of user roles and permissions. For example, when an employee's responsibilities change, their access permissions to the file pool can be updated immediately.

[0061] Optionally, the operation corresponding to the permission verification result is performed, including: if the permission verification result is successful, deblurring the fuzzing result of each file stored in the file pool corresponding to the target user identifier to obtain the original file corresponding to the fuzzing result, and returning the original file, wherein the original file is the file used by the user indicated by the user identifier in multiple business scenarios; if the permission verification result is unsuccessful, returning the fuzzing result of each file stored in the file pool corresponding to the target user identifier.

[0062] As mentioned in the previous embodiment, the subsequent operations performed differ depending on the permission verification results. In this embodiment, as mentioned in the previous embodiment, when the permission verification result is "verification failed," it may be because the object sending the file retrieval request does not have the operation permission for the target file. In this case, the file is returned in response to the file retrieval request; specifically, the returned file is the fuzzy processing result of the target file. If the permission verification result is "verification passed," the fuzzy processing result of each file stored in the file pool corresponding to the target user identifier is defuzzified to obtain the original file corresponding to the fuzzy processing result, and the original file of the target file is returned in response to the file retrieval request.

[0063] According to some optional embodiments of this application, the fuzzing result includes: multiple sub-graphic identifier codes filled in multiple independent regions where multiple key information is located, and a region number carried by each sub-graphic identifier code, wherein each region number is associated with an independent region; the fuzzing result of each file stored in the file pool corresponding to the target user identifier is defuzzified, including: concatenating multiple sub-graphic identifier codes according to the region number carried by the sub-graphic identifier code to obtain a concatenation result; and converting the concatenation result into key information.

[0064] After blurring the file using the blurring method described in the above embodiments, the resulting blurring result includes: sub-graphical identifiers filling independent regions containing multiple key information items, and a region number carried by each sub-graphical identifier. Each independent region completely covers the key information but does not cover other information adjacent to it. Each region number is generated based on the location information of an independent region; that is, each region number is associated with an independent region. In this embodiment, the following method can be used to deblur the file's blurring result: multiple sub-graphical identifiers are concatenated into a complete graphic identifier (i.e., the concatenated result) based on the region number carried by the sub-graphical identifier. Since the graphic identifier with the first area (i.e., the concatenated result) is generated based on the user identifier associated with the file and the key information recorded in the file, the concatenated result simultaneously contains the user identifier and the key information recorded in the file. In this embodiment, a decoder is used to convert the concatenated result into key information to restore the original content of the independent regions. The user identifier recorded in the splicing result can be used to perform secondary verification on the identifier of the object that sent the retrieval request (i.e., the target user identifier). When the user identifier recorded in the splicing result is the same as the target user identifier, the key information obtained above will be refilled back into its corresponding independent area.

[0065] Through the above steps, big data analysis is used to discover and establish the inherent connections and patterns between business scenarios and files, thereby generating a mapping relationship model. This model is then used to intelligently match the files required in various business scenarios, achieving the technical effect of intelligently retrieving files based on business scenarios. This improves business processing efficiency and the accuracy of file retrieval.

[0066] Figure 6 This is a structural diagram of a document retrieval device according to an embodiment of this application, such as... Figure 6 As shown, the file retrieval device includes: a receiving module 60, used to receive a file retrieval request, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs; a file category list generation module 62, used to analyze the retrieval request using a mapping relationship model to obtain a file category list, wherein the file category list is used to record file types that meet the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios; and a file search module 64, used to determine the file pool corresponding to the target user identifier, and search for the target file of the target type in the file pool according to the file category list, wherein the target user identifier is used to indicate the object that sent the file retrieval request, each file pool is used to uniquely record all files associated with a user identifier, and the target type is the file type recorded in the file category list.

[0067] Optionally, the file retrieval device further includes a permission verification module. The permission verification module is used to perform permission verification on the object that sent the file retrieval request when the target file is found, and to perform the operation corresponding to the permission verification result; when the target file is not found, it returns a prompt message, wherein the prompt message is used to suggest supplementary files.

[0068] Figure 7 This is a flowchart illustrating the steps involved in a file retrieval device. Figure 7As shown, when using a file retrieval device for file retrieval, the receiving module 60 receives a file retrieval request sent by a user (such as an account manager). The request must include the business scenario identifier to which the file to be retrieved belongs. After determining the business scenario, the file category list generation module 62 analyzes the file retrieval request received by the receiving module using a mapping relationship model. Based on the analyzed business scenario, it determines the file types that need to be provided and outputs these file types in the form of a file type list to the file search module 64. The file search module 64 is used to match files in the file pool corresponding to the object of the sent file retrieval request with files of the type (i.e., target type) recorded in the file category list (i.e., target files). In this embodiment, if the target file is found in the file pool, it is considered a successful match. At this time, the permission verification module performs permission verification on the object that sent the file retrieval request. If the verification passes, the target file is returned; if the verification fails, a prompt message is returned, which indicates the need for supplementary files.

[0069] It should be noted that, Figure 6 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 2 The relevant descriptions of the embodiments shown will not be repeated here.

[0070] This application also provides a non-volatile storage medium storing a computer program, wherein the above-described method for retrieving files is executed by running the computer program on the device where the non-volatile storage medium is located.

[0071] The aforementioned non-volatile storage medium is used to store programs that perform the following functions: receiving file retrieval requests, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs; analyzing the retrieval request using a mapping relationship model to obtain a file category list, wherein the file category list is used to record file types that meet the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios; determining the file pool corresponding to the target user identifier, and searching for the target file of the target type in the file pool according to the file category list, wherein the target user identifier is used to indicate the object that sent the file retrieval request, each file pool is used to uniquely record all files associated with a user identifier, and the target type is the file type recorded in the file category list.

[0072] This application also provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to execute the above-described method for retrieving files through the computer program.

[0073] The processor in the aforementioned electronic device is used to run a program that performs the following functions: receiving a file retrieval request, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs; analyzing the retrieval request using a mapping relationship model to obtain a file category list, wherein the file category list is used to record file types that meet the business scenario, and the mapping relationship model is constructed based on the mapping relationship between file types and business scenarios; determining the file pool corresponding to the target user identifier, and searching for the target file of the target type in the file pool according to the file category list, wherein the target user identifier is used to indicate the object that sent the file retrieval request, each file pool is used to uniquely record all files associated with a user identifier, and the target type is the file type recorded in the file category list.

[0074] This application also provides a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the above-described method for retrieving files.

[0075] It should be noted that each module in the above-mentioned file retrieval device can be a program module (e.g., a set of program instructions that implement a certain function) or a hardware module. For the latter, it can be manifested in the following forms, but is not limited to them: each of the above modules is manifested as a processor, or the functions of each of the above modules are implemented by a processor.

[0076] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0077] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0078] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0079] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0081] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, 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 storage medium 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0082] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for retrieving files, characterized in that, include: Receive a file retrieval request, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs; The retrieval request is analyzed using a mapping relationship model to obtain a list of file categories. The list of file categories is used to record file types that meet the business scenario. The mapping relationship model is constructed based on the mapping relationship between file types and business scenarios. A file pool corresponding to a target user identifier is determined, and a target file of the target type is searched in the file pool according to the file category list. The target user identifier is used to indicate the object that sent the file retrieval request. Each file pool is used to uniquely record all files associated with a user identifier. The target type is the file type recorded in the file category list.

2. The method according to claim 1, characterized in that, The mapping model is constructed using the following method: Acquire historical business data, wherein the historical business data includes: multiple business scenarios, multiple historical business objects, and historical files used in each of the business scenarios, wherein the historical business objects include: users who use the historical files in the business scenarios; Multiple transaction records are determined based on the historical business data, wherein each transaction record is used to record the related business scenarios, historical files and historical business objects; For each historical business object, a set of file types associated with each business scenario is determined based on multiple transaction records, and the association between the business scenario and the set of file types is determined as a mapping relationship between the file types and the business scenario. The set of file types associated with each business scenario is obtained by iteratively filtering the types of multiple historical files that are associated with the business scenario. The data structure that records the mapping relationship is defined as the mapping relationship model.

3. The method according to claim 2, characterized in that, Iterative filtering of the types of multiple historical files that are related to the aforementioned business scenario includes: For each business scenario, in each iteration, iterative objects with support less than a preset support are deleted to obtain remaining iterative objects. These remaining iterative objects are then combined to obtain higher-order frequent itemsets until the iteration stops. The order of the higher-order frequent itemset indicates the number of types it contains. The higher-order frequent itemset output in each iteration increases by 1 compared to the number of types it contains. The support indicates the frequency with which the iterative object appears in the business scenario. The iterative object in the first iteration is each type, and the iterative object in subsequent iterations is the higher-order frequent itemset output in the previous iteration. The iteration stops when: the higher-order frequent itemsets in the previous iteration do not contain any higher-order frequent itemsets with support greater than or equal to the preset support; the output of the previous iteration contains only one higher-order frequent itemset; and the target higher-order frequent itemset generated in the last iteration is the set of file types associated with the business scenario.

4. The method according to claim 1, characterized in that, Each user identifier corresponds to a file pool that stores the fuzzy processing results of files used by the user indicated by the user identifier in multiple business scenarios, the unique code of each file, and the storage path of each file; Based on the file category list, the target file of the target type is located in the file pool, including: The business scenario identifier contained in the file retrieval request and each file type recorded in the file category list are combined into a query condition; For each query condition, a target storage path containing the query condition is matched among the plurality of storage paths recorded in the file pool; The file indicated by the target storage path is identified as the target file.

5. The method according to claim 4, characterized in that, The storage path is generated using the following method: For each file, the file type is encoded as a first encoding result, the business object associated with the file is encoded as a second encoding result, and the business scenario associated with the file is encoded as a third encoding result. The first encoding result, the second encoding result, the third encoding result, and the custom encoding are combined to form the unique encoding corresponding to the file. The custom encoding is used to indicate the order in which the unique encoding of the file is generated, and the custom encoding corresponding to each file is different. The storage path of the file is generated based on the unique code and the name of the file.

6. The method according to claim 4, characterized in that, The obfuscation result of the file was obtained through the following method: Obtain multiple files used by a user in multiple business scenarios, as indicated by the user identifier corresponding to the file pool; For each document, identify key information from the content recorded in the document; A first area is determined for a plurality of independent regions that record the key information, and a graphic identification code with an area equal to the first area is generated based on the user identifier, wherein the first area is the sum of the plurality of independent regions; Determine the second area and area number of each independent region, cut the graphic identifier code into multiple sub-graphic identifier codes with an area equal to the second area, and mark the sub-graphic identifier codes using the area number of the independent region corresponding to the sub-graphic identifier codes; The sub-graphic identifier is filled into the independent region corresponding to the sub-graphic identifier according to the region number to obtain the fuzzy processing result of the file.

7. The method according to claim 1, characterized in that, The method further includes: If the target file is found, the permissions of the object that sent the file retrieval request are verified, and the operation corresponding to the permission verification result is executed. If the target file is not found, a prompt message is returned, which suggests that a supplementary file be provided.

8. The method according to claim 7, characterized in that, Perform permission verification on the object that sent the file retrieval request, including: The permissions of the object that sent the file retrieval request are queried in the permission record table to obtain the query results. The permission record table is used to record the operation permissions of each file associated with each user identifier. The types of operation permissions include at least one of the following: view, download, delete. If the query result indicates that the target user identifier is associated with the operation permissions of the target file, the permission verification result is determined to be successful. If the query result indicates that the target user identifier is not associated with the operation permissions of the target file, the permission verification result is determined to be a verification failure.

9. The method according to claim 8, characterized in that, Perform the operation corresponding to the permission verification result, including: If the permission verification result is that the verification is passed, the fuzzing result of each file stored in the file pool corresponding to the target user identifier is defuzzified to obtain the original file corresponding to the fuzzing result, and the original file is returned. The original file is the file used by the user indicated by the user identifier in multiple business scenarios. If the permission verification result is a failure, the fuzzy processing result of each file stored in the file pool corresponding to the target user identifier is returned.

10. The method according to claim 9, characterized in that, The fuzzing result includes: multiple sub-graphic identifier codes filled in multiple independent regions where multiple key information is located, and a region number carried by each sub-graphic identifier code, wherein each region number is associated with one independent region; Deblurring is performed on the obfuscated results of each file stored in the file pool corresponding to the target user identifier, including: Multiple sub-graphic identifiers are concatenated according to the area number carried by the sub-graphic identifier to obtain the concatenation result; The splicing result is converted into the key information.

11. A device for retrieving documents, characterized in that, include: The receiving module is used to receive a file retrieval request, wherein the file retrieval request carries the business scenario to which the file to be retrieved belongs; The file category list generation module is used to analyze the retrieval request using a mapping relationship model to obtain a file category list. The file category list is used to record file types that meet the business scenario. The mapping relationship model is constructed based on the mapping relationship between file types and business scenarios. The file search module is used to determine the file pool corresponding to the target user identifier, and search for the target file of the target type in the file pool according to the file category list. The target user identifier is used to indicate the object that sent the file search request. Each file pool is used to uniquely record all files associated with a user identifier. The target type is the file type recorded in the file category list.

12. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, wherein the device containing the non-volatile storage medium executes the method for retrieving files according to any one of claims 1 to 11 by running the computer program.

13. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method for retrieving documents as described in any one of claims 1 to 11 through the computer program.

14. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the method for retrieving documents as described in any one of claims 1 to 11.

Images