Document tag management methods, devices and storage media
By collaborating through directory strategy matching, automatic backup, and failure retries, the issues of real-time performance and security in document tag management are resolved. This enables real-time automated updates and secure management of document tags, improving the accuracy and timeliness of document classification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHENZHEN LEAGSOFT TECH
- Filing Date
- 2026-01-28
- Publication Date
- 2026-06-02
Smart Images
Figure CN122132356A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of document classification management, and in particular to a document label management method and device and storage medium. BACKGROUND
[0002] Document labels are an important basis for enterprise data classification. In existing solutions, the management of document labels often relies on manual or single scanning, lacks coordination with directory policies, backup mechanisms, and retry processes, resulting in missing or untimely updating of labels.
[0003] Specifically, the traditional document label management method mainly relies on manual or single-execution batch scripts, which has the following problems:
[0004] (1) Lack of timeliness: When the document location or content changes, the label cannot be updated in real time, resulting in label invalidation.
[0005] (2) Easy to lose or delete: During file transfer or copying, if there is no backup mechanism, the label information is often lost or overwritten.
[0006] (3) Poor policy consistency: Different directories and different departments have inconsistent policy execution standards, which can easily result in unauthorized access or missing labels.
[0007] (4) Lack of retry mechanism: Network jitter, file occupation, and other reasons can cause label writing failure, and if there is no retry means, the label is in an uncontrollable state. SUMMARY
[0008] The purpose of the embodiments of the present application is to provide a document label management method, device and storage medium, to cooperate through directory policy matching, automatic backup, label reading and writing, failure retry and other links, and to automatically maintain document labels on the premise of ensuring data security.
[0009] To achieve the above purpose, in a first aspect, the embodiments of the present application provide a document label management method, comprising:
[0010] If a document event is triggered, a target file is determined; the document event trigger includes a change in document location or document content; the target file is a non-temporary file, a non-recycle bin file, a non-template file, a file that does not hit the whitelist, and a file in the backup record;
[0011] According to the directory policy, the directory and file type of the target file are matched to determine that the target file enters the label processing link;
[0012] Read the current label information of the target file, and process the current label information according to the policy conditions.
[0013] As one specific implementation of this application, the directory strategy includes:
[0014] Controlled file types;
[0015] Controlled directory ranges, including specified directories or exception directories;
[0016] The sources of the files include local storage, network sharing, browser downloads, or implementation in business systems;
[0017] Used to determine sensitive identification conditions that need to be processed, including keywords or whether the template is matched;
[0018] The target label definition corresponding to the processing action includes a combination of hierarchical labels and category labels;
[0019] Auxiliary constraints include whether a backup is required before tag processing, whether an audit log is generated, or whether a retry is required upon failure.
[0020] As a specific implementation of this application, determining whether the target file enters the tag processing stage specifically involves:
[0021] The target file is matched item by item according to the contents of the directory policy, including whether the file type is within the scope of the directory policy, whether the directory where the target file is located meets the specified / exception scope of the directory policy, whether the source of the target file belongs to the source allowed by the directory policy, and whether the target file hits the sensitive identification conditions.
[0022] When the above conditions are met simultaneously, the target file is determined to enter the tag processing stage.
[0023] As a preferred implementation of this application, the method includes:
[0024] Before processing the tags, determine whether file backup needs to be performed based on the auxiliary constraints of the directory strategy and the current tag information.
[0025] If necessary, copy the target file to the specified secure directory;
[0026] If not needed, read the current tag information of the target file.
[0027] As a specific implementation of this application, the current tag of the target file is read, and the current tag is processed according to the policy conditions, specifically as follows:
[0028] Call the tag reading interface to read the current tag information of the target file, including automatic tag level and category ID, and manual tag level and category ID;
[0029] The current tag information is matched with the policy conditions to determine whether the target file needs to undergo tag processing.
[0030] If necessary, execute the specified label or clear the label.
[0031] As a specific implementation of this application, the action of clearing or specifying tags is as follows:
[0032] When the target file matches the sensitive identification and scope conditions, execute the specified label and write or update the predefined target level / classification label to the target file;
[0033] When the target file is within the controlled range but does not meet the conditions for labeling, the label is cleared.
[0034] As a preferred implementation of this application, after specifying or clearing a tag, the method further includes:
[0035] Obtain new tag information; wherein, when a specified tag is executed, the new tag information is the target hierarchical tag or target classification tag or a combination of both specified by the strategy conditions; when a tag is cleared, the new tag information is the state after the automatic tags are cleared;
[0036] Call the tag writing interface to write the new tag information in an overwrite manner, and record the operation result;
[0037] If the write operation fails, the new tag information is added to the retry queue, and the retry thread is invoked to re-execute the write operation.
[0038] Secondly, embodiments of this application also provide a document tag management device, including:
[0039] The determination unit is used to determine the target file if a document event is triggered; the document event triggering includes changes in document location or document content; the target file is a non-temporary file, a non-recycle bin file, a non-template file, a file not on the whitelist, and a file not in the backup directory;
[0040] The matching unit is used to match the directory and file type of the target file according to the directory strategy in order to determine whether the target file enters the tag processing stage;
[0041] The tag processing unit is used to read the current tag information of the target file and process the current tag information according to the policy conditions.
[0042] Thirdly, embodiments of the present invention also provide a document tag management device, including a processor, an input device, an output device, and a memory, wherein the processor, input device, output device, and memory are interconnected, wherein the memory is used to store a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the method described in the first aspect.
[0043] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the method described in the first aspect.
[0044] Implementing the embodiments of the present invention, through the collaborative processes of directory policy matching, automatic backup, tag reading and writing, and failure retries, has the following advantages:
[0045] 1. Compared with manual document tag management, the embodiments of the present invention can realize real-time and automated updating of document tags, reducing manual intervention.
[0046] 2. Compared with the scheme that only marks during the upload process, the embodiments of the present invention can cover multiple scenarios such as local editing and copying.
[0047] 3. Compared with simple backup solutions, the embodiments of the present invention combine backup and retry matrix, which can take into account both document tag management and data security.
[0048] 4. The directory strategy and tag operation work together to avoid unauthorized access or omissions.
[0049] In summary, the solution provided by the embodiments of this invention can significantly reduce the cost of manually maintaining tags, improve the accuracy and timeliness of document classification, and reduce the risk of data leakage. For industries such as finance, government, and manufacturing, this solution helps to pass compliance audits and improve knowledge asset management capabilities, thus having significant economic and social benefits. Attached Figure Description
[0050] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.
[0051] Figure 1 This is a flowchart of a document tag management method provided in an embodiment of the present invention;
[0052] Figure 2 yes Figure 1 The diagram shows another flowchart of the document tag management method;
[0053] Figure 3This is a structural diagram of the document tag management device provided in an embodiment of the present invention;
[0054] Figure 4 yes Figure 3 Another structural diagram of the device shown. Detailed Implementation
[0055] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0056] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0057] To better understand the embodiments of the present invention, the terms involved are explained as follows:
[0058] Document tags: Identifiers such as classification and security level set for documents, used to control access and circulation.
[0059] Directory strategy: Tag rules specified for specific directories or file types.
[0060] Retry thread: A separate thread used to handle retry logic for tag writing failures.
[0061] Backup file: A safe copy of the document generated before modification, used for rollback.
[0062] The inventive concept of this invention is as follows:
[0063] With "policy-driven + backup protection + tag synchronization + retry error correction" as its core, the following functions are achieved:
[0064] (1) Policy-driven: The system determines whether tag management is needed based on directory policy and file type, and supports multi-level policy superposition, such as first judging the directory and then judging the file extension.
[0065] (2) Backup guarantee: Before performing any tag writing operation, back up the original file content to ensure that it can be restored in case the tag writing fails or needs to be rolled back.
[0066] (3) Tag synchronization: The current state is obtained by reading existing tags, and then the target tag set is calculated according to the strategy; the write interface adopts the overwrite method to ensure that the tags are synchronized with the strategy.
[0067] (4) Retry and error correction: Failed tasks are managed by the retry thread, which can set the number of retries, intervals and backoff strategies until success or manual intervention.
[0068] (5) Audit closed loop: Every tag read, write, backup and retry is logged to form a complete audit chain.
[0069] In actual implementation, the process of this embodiment of the invention includes the following details:
[0070] 1. Strategy matching: Supports multiple directory matching methods such as wildcards and regular expressions, and determines the final strategy based on priority.
[0071] 2. Tag Conflict Handling: If an existing tag conflicts with a policy tag, the system will first back it up and then overwrite it, while recording the differences for administrator review.
[0072] 3. Abnormal scenarios: Handle abnormal situations such as file being occupied, network disconnection, insufficient permissions, etc., automatically enter the retry queue, and notify the administrator.
[0073] 4. Policy rollback: When a policy is revoked, the system supports rolling back the tag to its original state and restoring it using the tag information in the backup file.
[0074] 5. Multi-threaded scheduling: When processing tags for a large number of documents, a thread pool is used to achieve parallelism and ensure performance.
[0075] Please refer to Figure 1 and Figure 2 The document tag management method provided in this embodiment of the invention includes:
[0076] S1, if a document event is triggered, determine the target file.
[0077] Among them, document event triggering includes changes in document location or document content; the target file is a non-temporary file, a non-recycle bin file, a non-template file, a file not on the whitelist, and a file not in the backup directory.
[0078] Specifically, when the system receives events such as file changes / generation, it will first perform a basic filtering on the changed files to ensure that the target file is an object "worth processing" (e.g., excluding temporary files, recycle bin files, template files, and files that hit the whitelist; at the same time, it will also avoid processing files in the backup directory again).
[0079] S2, Match the directory and file type of the target file according to the directory strategy to determine whether the target file enters the tag processing stage.
[0080] Directory policy refers to a set of document tagging rules issued by the system to guide the system on the conditions, types of files, and methods for tagging. The specific content of a directory policy typically includes: controlled directory scope (e.g., specified directories / excepted directories), controlled file types (e.g., file extensions or document types), file source scope (e.g., local storage / network sharing / browser download / business system deployment), sensitive identification conditions for determining whether "processing is required" (e.g., keyword / template hits), and the definition of the target tag corresponding to the processing action (a combination of hierarchical and category tags). Additionally, directory policies may include optional auxiliary constraints (e.g., whether to back up before processing, whether to generate audit logs, retrying on failure, etc.).
[0081] In practice, after performing the aforementioned basic filtering on the files, the system will match each policy item by item: whether the file type is within the policy's scope, whether the directory where the file is located conforms to the policy's specified / exception range, whether the file's source is a source allowed by the policy, and whether the sensitive identification conditions are met. Only when all these conditions are met will the system proceed to the tag processing stage.
[0082] S3 reads the current tag information of the target file before tagging, and determines whether file backup needs to be performed based on the directory policy and the current information.
[0083] S4, if required by the directory policy, calls the backup module to copy the source files to the specified secure directory.
[0084] In practice, before processing tags, the current tag information of the target file is read. If an existing tag conflicts with a policy tag, it means the policy requires a file backup first. The system performs a file backup operation to ensure rollback is possible.
[0085] S5, call the tag reading interface to read the current tag information of the target file.
[0086] The current label information includes automatic label level and category ID, and manual label level and category ID.
[0087] Specifically, the file information and detection results collected in the preceding steps serve as the basis for subsequent "decision-making" and "implementation." On one hand, this information is used to match with policy conditions to determine whether a file falls within the scope of governance and whether labeling is required. On the other hand, the current label status is used to determine specific actions (whether to add / update the target label, whether no processing is needed, or whether automatically ineligible labels need to be cleaned up). Simultaneously, information such as backup requirements, whether the file is occupied, and the reasons for operation success / failure will affect whether write operations can be performed, whether retries are necessary, and provide support for subsequent audit logs and traceability (e.g., explaining that the incomplete processing was due to backup failure, insufficient permissions, or file occupancy).
[0088] S6, match the current tag information with the policy conditions, and perform tag processing based on the matching result.
[0089] In practical implementation, embodiments of the present invention can calculate the target tag set according to strategy requirements: if tags need to be cleared, an empty tag set is passed; if feature tags need to be applied, a corresponding level and category list is generated. Here, "specific tags" refers to a predefined "target tag set" used to write to a file when conditions are met, or for consistency comparison with existing tags in the file. It typically consists of two parts: "level tags" and "category tags" (which can be used individually or in combination). Figure 1 The "strategy type" can be understood in principle as two types of processing actions: when a file hits the sensitive identification and scope conditions, "assign tag" is executed (the target level / classification tag defined by the strategy is written to or updated to the file); when a file is within the controlled scope but does not meet the conditions for tagging, "clear tag" is executed (automatic tags that should not be retained are cleaned up).
[0090] Step S6 can be understood as:
[0091] The current tag information is matched with the policy conditions to determine whether the target file needs to undergo tag processing.
[0092] If necessary, execute the specified label to write or update the predefined target level / classification label to the target file; or execute the label clearing.
[0093] S7, retrieve new tag information.
[0094] Specifically, when a specified label is executed, the new label information is the target hierarchical label or target classification label or a combination of both specified by the strategy conditions; when a label is cleared, the new label information is the state after the automatic labels are cleared.
[0095] Understandably, the new label information refers to the target label status that the file should present after this processing is completed. When a strategy that requires labeling is hit, the new label information is the target hierarchical label and the target classification label (which can be a combination) specified by the strategy. When the cleanup branch is executed, the new label information indicates the "state after clearing automatic labels", that is, both the hierarchical and classification parts are empty.
[0096] S8, call the tag writing interface to write the new tag information in an overwrite manner, and record the operation result.
[0097] S9. If the write operation fails, the new tag information is added to the retry queue, and the retry thread is called to re-execute the write operation.
[0098] The document tag management method provided in this invention, through the collaborative processes of directory policy matching, automatic backup, tag reading and writing, and failure retries, has the following advantages:
[0099] 1. Compared with manual document tag management, the embodiments of the present invention can realize real-time and automated updating of document tags, reducing manual intervention.
[0100] 2. Compared with the scheme that only marks during the upload process, the embodiments of the present invention can cover multiple scenarios such as local editing and copying.
[0101] 3. Compared with simple backup solutions, the embodiments of the present invention combine backup and retry matrix, which can take into account both document tag management and data security.
[0102] 4. The directory strategy and tag operation work together to avoid unauthorized access or omissions.
[0103] In summary, the solution provided by the embodiments of this invention can significantly reduce the cost of manually maintaining tags, improve the accuracy and timeliness of document classification, and reduce the risk of data leakage. For industries such as finance, government, and manufacturing, this solution helps to pass compliance audits and improve knowledge asset management capabilities, thus having significant economic and social benefits.
[0104] Based on the same inventive concept, embodiments of the present invention also provide a document tag management device, comprising:
[0105] The determination unit is used to determine the target file if a document event is triggered; the document event triggering includes changes in document location or document content; the target file is a non-temporary file, a non-recycle bin file, a non-template file, a file not on the whitelist, and a file not in the backup directory;
[0106] The matching unit is used to match the directory and file type of the target file according to the directory strategy to determine whether the target file enters the tag processing stage. The directory strategy includes, but is not limited to: controlled file types; controlled directory ranges, including specified directories or exception directories; file sources, including local storage, network sharing, browser downloads, or landing on business systems; sensitive identification conditions for determining processing requirements, including keywords or whether a template is matched; target tag definitions corresponding to processing actions, including combinations of hierarchical tags and category tags; and auxiliary constraints, including whether backup is required before tag processing, whether audit logs are generated, or whether retrying is necessary upon failure.
[0107] The tag processing unit is used to read the current tag information of the target file and process the current tag information according to the policy conditions.
[0108] Furthermore, the matching unit is specifically used for:
[0109] The target file is matched item by item according to the contents of the directory policy, including whether the file type is within the scope of the directory policy, whether the directory where the target file is located meets the specified / exception scope of the directory policy, whether the source of the target file belongs to the source allowed by the directory policy, and whether the target file hits the sensitive identification conditions.
[0110] When the above conditions are met simultaneously, the target file is determined to enter the tag processing stage.
[0111] Furthermore, as a preferred implementation of this application, the document tag management device further includes a backup unit, used for:
[0112] Before processing the tags, determine whether file backup needs to be performed based on the auxiliary constraints of the directory strategy and the current tag information.
[0113] If necessary, copy the target file to the specified secure directory;
[0114] If not needed, read the current tag information of the target file.
[0115] Furthermore, the label processing unit is specifically used for:
[0116] Call the tag reading interface to read the current tag information of the target file, including automatic tag level and category ID, and manual tag level and category ID;
[0117] The current tag information is matched with the policy conditions to determine whether the target file needs to undergo tag processing.
[0118] If necessary, execute the specified label or clear the label.
[0119] Specifically, clearing a tag or specifying a tag involves:
[0120] When the target file matches the sensitive identification and scope conditions, execute the specified label and write or update the predefined target level / classification label to the target file;
[0121] When the target file is within the controlled range but does not meet the conditions for labeling, the label is cleared.
[0122] Furthermore, as a preferred implementation of this application, the document tag management device further includes a writing unit, used for:
[0123] Obtain new tag information; wherein, when a specified tag is executed, the new tag information is the target hierarchical tag or target classification tag or a combination of both specified by the strategy conditions; when a tag is cleared, the new tag information is the state after the automatic tags are cleared;
[0124] Call the tag writing interface to write the new tag information in an overwrite manner, and record the operation result;
[0125] If the write operation fails, the new tag information is added to the retry queue, and the retry thread is invoked to re-execute the write operation.
[0126] It should be noted that the specific workflow of this embodiment is described in the foregoing method embodiment section, and will not be repeated here.
[0127] Furthermore, such as Figure 4 As shown, another embodiment of the present invention also provides a document tag management device, which may include: one or more processors 101, one or more input devices 102, one or more output devices 103, and a memory 104. The processors 101, input devices 102, output devices 103, and memory 104 are interconnected via a bus 105. The memory 104 is used to store a computer program, the computer program including program instructions, and the processor 101 is configured to invoke the program instructions to execute the method described in the above-described method embodiment.
[0128] It should be understood that, in this embodiment of the invention, the processor 101 may be a central processing unit (CPU), but it may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.
[0129] Input device 102 may include a keyboard, etc., and output device 103 may include a display (LCD, etc.), a speaker, etc.
[0130] The memory 104 may include read-only memory and random access memory, and provides instructions and data to the processor 101. A portion of the memory 104 may also include non-volatile random access memory. For example, the memory 104 may also store device type information.
[0131] In specific implementations, the processor 101, input device 102, and output device 103 described in the embodiments of the present invention can execute the implementation methods described in the embodiments of the document tag management method provided in the present invention, which will not be repeated here.
[0132] Accordingly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, implement the above-described document tag management method.
[0133] The computer-readable storage medium can be an internal storage unit of the system described in any of the foregoing embodiments, such as the system's hard disk or memory. The computer-readable storage medium can also be an external storage device of the system, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the system. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
[0134] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0135] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices or units, or may be electrical, mechanical or other forms of connection.
[0136] 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 network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.
[0137] Furthermore, the functional units in the various embodiments of this invention 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 units can be implemented in hardware or as software functional units. When using each module, user information is collected and stored only with the user's full authorization and in compliance with relevant laws and regulations, protecting the security and privacy of user data, and strictly prohibiting unauthorized access; data processing will be conducted within the scope stipulated by law and will not exceed the purpose and scope authorized by the user; at the same time, users have the rights to access, correct, delete, restrict processing, and refuse their personal data; and must strictly comply with applicable laws and regulations and conduct compliance reviews.
[0138] 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 the present invention, 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 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0139] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A document tag management method, characterized in that, include: If a document event is triggered, determine the target file; The document event triggering includes changes in the document's location or content; The target file is a non-temporary file, a non-recycle bin file, a non-template file, a file not on the whitelist, or a file not in the backup directory; The target file's directory and file type are matched according to the directory strategy to determine whether the target file enters the tag processing stage; Read the current tag information of the target file and process the current tag information according to the policy conditions.
2. The document tag management method as described in claim 1, characterized in that, The directory strategy includes: Controlled file types; Controlled directory ranges, including specified directories or exception directories; The sources of the files include local storage, network sharing, browser downloads, or implementation in business systems; Used to determine sensitive identification conditions that need to be processed, including keywords or whether the template is matched; The target label definition corresponding to the processing action includes a combination of hierarchical labels and category labels; Auxiliary constraints include whether a backup is required before tag processing, whether an audit log is generated, or whether a retry is required upon failure.
3. The document tag management method as described in claim 2, characterized in that, The specific steps for determining whether the target file enters the tag processing stage are as follows: The target file is matched item by item according to the contents of the directory policy, including whether the file type is within the scope of the directory policy, whether the directory where the target file is located meets the specified / exception scope of the directory policy, whether the source of the target file belongs to the source allowed by the directory policy, and whether the target file hits the sensitive identification conditions. When the above conditions are met simultaneously, the target file is determined to enter the tag processing stage.
4. The document tag management method as described in claim 2, characterized in that, The method includes: Before processing the tags, determine whether file backup needs to be performed based on the auxiliary constraints of the directory strategy and the current tag information. If necessary, copy the target file to the specified secure directory; If not needed, read the current tag information of the target file.
5. The document tag management method as described in claim 2, characterized in that, Read the current tag of the target file, and process the current tag according to the policy conditions, specifically as follows: Call the tag reading interface to read the current tag information of the target file, including automatic tag level and category ID, and manual tag level and category ID; The current tag information is matched with the policy conditions to determine whether the target file needs to undergo tag processing. If necessary, execute the specified label or clear the label.
6. The document tag management method as described in claim 5, characterized in that, To clear a specific tag, follow these steps: When the target file matches the sensitive identification and scope conditions, execute the specified label and write or update the predefined target level / classification label to the target file; When the target file is within the controlled range but does not meet the conditions for labeling, the label is cleared.
7. The document tag management method as described in claim 5, characterized in that, After executing the specified tag or clearing the tag, the method further includes: Obtain new tag information; wherein, when a specified tag is executed, the new tag information is the target hierarchical tag or target classification tag or a combination of both specified by the strategy conditions; when a tag is cleared, the new tag information is the state after the automatic tags are cleared; Call the tag writing interface to write the new tag information in an overwrite manner, and record the operation result; If the write operation fails, the new tag information is added to the retry queue, and the retry thread is invoked to re-execute the write operation.
8. A document tag management device, characterized in that, include: The determination unit is used to determine the target file if a document event is triggered. The document event triggering includes changes in the document's location or content; The target file is a non-temporary file, a non-recycle bin file, a non-template file, a file not on the whitelist, or a file not in the backup directory; The matching unit is used to match the directory and file type of the target file according to the directory strategy in order to determine whether the target file enters the tag processing stage; The tag processing unit is used to read the current tag information of the target file and process the current tag information according to the policy conditions.
9. A document tag management device, characterized in that, The system includes a processor, an input device, an output device, and a memory, which are interconnected. The memory is used to store a computer program, which includes program instructions. The processor is configured to invoke the program instructions 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 a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.