Method and system for file non-intrusive rich text annotation, computer device and medium

Abstract

The present disclosure relates to the technical field of computer software and file system data management, in particular to a file non-intrusive rich text labeling method and system, computer equipment and medium. The file non-intrusive rich text labeling method comprises the following steps: S1, obtaining a focus target path; obtaining the path of the currently selected file or folder, and determining the path as the focus target path; S2, based on the mixed storage structure composed of hidden configuration text files, NTFS backup data streams and local index databases, the rich text note data of the focus target is accessed and cross-verified with the dual storage carrier and data recovery; S3, based on the read rich text note data, a floating display window is generated and rendered; S4, the rich text note data is indexed and synchronized and retrieved. The present disclosure can improve the accuracy of focus target recognition in a multi-window, multi-tab page environment.

Description

Technical Field

[0001] This disclosure relates to the field of computer software and file system data management technology, specifically to a method and system for non-intrusive rich text annotation of files, computer equipment, and media. Background Technology

[0002] Currently, existing file annotation technologies (including tagging methods based on hash mapping or system bus) mainly suffer from the following underlying technical shortcomings:

[0003] (1) Physical hash corruption and intrusiveness:

[0004] Traditional file annotation methods typically modify the file's attributes or extended metadata directly, which alters the file's original hash value (such as MD5 / SHA256) and compromises file integrity. Some existing technologies, in order to avoid corrupting the file hash value, choose to build an independent Markdown file repository or introduce a third-party database for annotation storage. However, this is highly dependent on a specific closed file management system. Once outside of this dedicated software environment, users find it difficult to directly perceive and maintain the file's annotation information.

[0005] (2) The openness of the system bus and API interface is limited:

[0006] Some existing tag management systems require each application to actively connect to its system bus (such as through specific APIs or DBus interfaces), or restrict users to operate within specific client interfaces. This makes it difficult to seamlessly integrate into the operating system's native resource manager interaction process, resulting in poor compatibility and universality across application scenarios.

[0007] (3) Cross-file system metadata chain break:

[0008] Existing covert storage technologies (such as NTFS Alternate Data Streams (ADS) suffer from data stream truncation and loss when files are transferred across file systems (such as copying to a FAT32 formatted USB drive); while pure external text configurations cannot automatically follow the file when it is dragged and moved individually, resulting in "files are there, but comments are lost".

[0009] (4) High interaction costs for metadata presentation:

[0010] Existing technologies rely on users actively initiating "search" commands (such as clicking a button, entering search terms, or opening a property panel) when displaying notes. In scenarios involving high-frequency browsing of massive amounts of files, this "request-response" interaction generates significant operational redundancy, lacking a zero-click accompanying display mechanism that does not obstruct the native view and allows users to leave immediately after use.

[0011] Public content

[0012] I. Technical problems to be solved

[0013] This disclosure aims to at least partially solve one of the aforementioned technical problems.

[0014] II. Technical Solution

[0015] The first aspect of this disclosure provides a method for non-intrusive rich text annotation of documents. The method for non-intrusive rich text annotation of documents includes:

[0016] Step S1: Obtain the path to the focus target;

[0017] Get the path of the currently selected file or folder, and set the path as the focus target path;

[0018] Step S2: Based on the hybrid storage structure consisting of a hidden configuration text file, an NTFS backup data stream, and a local index database, the rich text annotation data of the focus target is accessed and cross-verified by the dual storage carriers and the data is recovered.

[0019] The rich text annotation data and annotation verification information corresponding to the focus target are obtained, and the rich text annotation data and annotation verification information are stored in a hidden configuration text file associated with the focus target. When the file system where the focus target is located supports NTFS backup data stream, the rich text annotation data and annotation verification information are stored in the NTFS backup data stream of the focus target. At the same time, an index record corresponding to the focus target is created or updated in the local index database. The dual storage carriers are the hidden configuration text file and the NTFS backup data stream.

[0020] When reading the rich text annotation data, the status of the annotation data in the hidden configuration text file and the NTFS backup data stream is detected; when the annotation data in one storage medium is missing or invalid, and the annotation data in the other storage medium is valid, the missing or invalid annotation data is self-healed using the valid annotation data, and the local index database is maintained based on the valid annotation data.

[0021] Step S3: Based on the read rich text annotation data, generate and render a floating display window;

[0022] The corresponding rich text annotation data is obtained according to the focus target path, and the rich text annotation data is displayed through a floating display window.

[0023] Step S4: Index, synchronize, and retrieve the rich text annotation data;

[0024] Obtain the local physical memo record formed by the hidden configuration text file and the memo data in the NTFS standby data stream, synchronize the local physical memo record with the index record in the local index database, and query the local index database according to the search keywords to obtain the search results.

[0025] A second aspect of this disclosure provides a system for non-intrusive rich text annotation of documents. The system for non-intrusive rich text annotation of documents includes:

[0026] The context awareness and path acquisition module is used to obtain the path of the currently selected file or folder and determine the path as the focus target path;

[0027] The note editing and hybrid storage module is used to obtain rich text note data and note verification information corresponding to the focus target, store the rich text note data and note verification information in a hidden configuration text file associated with the focus target, and when the file system where the focus target is located supports NTFS backup data stream, store the rich text note data and note verification information in the NTFS backup data stream of the focus target, and at the same time create or update the index record corresponding to the focus target in the local index database.

[0028] The self-healing and index maintenance module is used to read and detect the status of the memo data in the hidden configuration text file and the NTFS backup data stream. When the memo data in one storage medium is missing or invalid, and the memo data in the other storage medium is valid, the module uses the valid memo data to perform self-healing processing on the missing or invalid memo data, and maintains the local index database based on the valid memo data. The self-healing and index maintenance module is also used to obtain local physical memo records from the NTFS backup data stream and the hidden configuration text file, and synchronize the local physical memo records with the index records in the local index database.

[0029] The adaptive floating display module is used to obtain the corresponding rich text annotation data according to the focused target path, and display the rich text annotation data through a floating display window.

[0030] The index retrieval module is used to receive search keywords, query the local index database based on the search keywords, and generate and output the corresponding search results.

[0031] A third aspect of this disclosure provides a computer device. The computer device includes: a memory storing a computer program thereon; and a processor that, when executing the computer program, implements the above-described method for non-intrusive rich text annotation of documents.

[0032] A third aspect of this disclosure provides a computer-readable storage medium. This computer-readable storage medium stores a computer program; wherein, when executed by a processor, the computer program implements the above-described method for non-intrusive rich text annotation of documents.

[0033] III. Beneficial Effects

[0034] As can be seen from the above technical solution, this disclosure has at least one of the following beneficial effects compared to the prior art:

[0035] (1) Dual-track path acquisition improves the accuracy and compatibility of focal target identification.

[0036] This disclosure obtains the focus target path by combining the operating system file manager interface with a system clipboard-assisted method. When a valid path can be obtained through the operating system file manager interface, the active shell window or active tab is determined by matching the shell window title, window hierarchy, and current directory path. When a valid path cannot be obtained, the path of the currently selected item is extracted from the system clipboard by simulating a copy operation, and the original data and formatting information in the clipboard are restored after the path acquisition is completed. This improves the accuracy of focus target identification in multi-window, multi-tab environments, and is compatible with both native file managers and third-party file managers that respond to standard copy operations, while reducing the impact of the path acquisition process on the user's original clipboard content.

[0037] (2) Three-in-one hybrid storage enables non-intrusive association of rich text annotations.

[0038] This disclosure employs a hybrid architecture comprised of a hidden configuration text file, an NTFS standby data stream, and a local index database. Rich text annotation data and annotation verification information are stored in the hidden configuration text file associated with the focus target. When the file system supports NTFS standby data streams, the corresponding data is written to the NTFS standby data stream of the focus target. For file-type focus targets, the annotation data is not written to the file's main data stream. This allows for the appending of rich text annotations to files or folders while maintaining the content and hash value of the file's main data stream, improving the applicability of this disclosure in scenarios with high requirements for master data integrity, such as engineering drawings, program code, and electronic evidence.

[0039] This disclosure enables non-intrusive association of rich text annotations. Non-intrusive means that throughout the entire lifecycle of rich text annotation and reading of a file or folder, the target file's original main data stream, file creation / modification timestamps, and MD5 / SHA256 hash checksums remain unchanged.

[0040] (3) The bidirectional state machine self-healing improves the reliability and recoverability of the notes data.

[0041] This disclosure detects the status of memo data in the hidden configuration text file and the NTFS standby data stream using memo verification information. If memo data is missing or invalid in one storage medium, but valid in another, the missing or invalid memo data is reconstructed using the valid memo data, while simultaneously maintaining a local index database. This allows the two physical storage mediums to serve as recovery sources for each other, reducing the risk of unreadable memo data due to the loss or damage of a single storage medium, and providing a data foundation for memo data recovery after the focus target is transferred across file systems.

[0042] (4) Anti-obstruction floating positioning reduces the interference of remarks display on the current operation.

[0043] This disclosure analyzes candidate display quadrants based on the screen coordinates of the mouse cursor, the display boundaries of the target monitor, the window boundaries of the currently focused window, and the size to be displayed for the floating display window. It then selects the target display quadrant that can accommodate the floating display window while avoiding obstruction of the current focus area. This reduces the likelihood of the floating display window exceeding the monitor boundaries or obscuring the current operating area, and adapts to multi-monitor and different display resolution environments, allowing rich text annotations to be displayed with less interference during document browsing.

[0044] (5) The combination of distance destruction and fixed retention enables adaptive lifecycle management of the floating display window.

[0045] This disclosure calculates the Euclidean distance between the current coordinates of the mouse cursor and the initial anchor coordinates of the floating display window, and sets a dynamic release threshold to automatically destroy the floating display window in the normal state. The dynamic release threshold refers to the critical judgment parameter that triggers the destruction of the floating display window when the mouse pointer movement speed exceeds a preset pixel / second or the distance between the pointer and the boundary of the floating display window exceeds a preset pixel value. At the same time, combined with the window stripping and state transition mechanism, the floating display window that needs to be continuously displayed is moved into an independent window queue and converted to a fixed state.

[0046] The beneficial effects of this collaborative management approach are as follows: Automatic release and low resource consumption: When browsing multiple files continuously, the floating display window in the normal state can automatically trigger destruction and release system resources based on Euclidean distance judgment as the user's focus shifts, effectively avoiding screen visual interference and memory redundancy caused by multiple window stacking; Multi-text document comparison and persistent retention: The floating display window in the fixed state achieves stable persistence in an independent window queue by being separated from the global instance and decoupled from the Euclidean distance destruction judgment logic, thereby supporting users to compare and analyze rich text notes of multiple different files on the same screen.

[0047] (6) Incremental index synchronization and version linkage improve the efficiency of note retrieval and interface response.

[0048] This disclosure obtains local physical memo records through multi-threaded scanning and directory blacklist pruning, and then verifies and synchronizes these local physical memo records with the index records in the local index database. Simultaneously, it uses a global data version number (DataVersion) to identify changes in the memo data and index records, and refreshes the front-end search results when the version number changes. Since keyword retrieval is primarily performed on the local index database, eliminating the need to re-traverse the physical file system for each search, it reduces disk I / O overhead in large-scale file environments. On-demand refreshing via DataVersion also reduces redundant loading in unchanged situations, decoupling background scanning, index maintenance, and front-end interaction, thus improving the efficiency of rich text memo retrieval and interface responsiveness. Attached Figure Description

[0049] Figure 1 This is a general flowchart of a method for non-intrusive rich text annotation of documents according to embodiments of this disclosure.

[0050] Figure 2 for Figure 1 The flowchart for obtaining the focus target path in the method shown is as follows.

[0051] Figure 3 for Figure 1 The method shown includes a flowchart for storage, status determination, and bidirectional self-healing.

[0052] Figure 4 for Figure 1 The method shown includes a flowchart of migration, index synchronization, and real-time updates.

[0053] Figure 5A This is a schematic diagram of the interaction logic of the floating display window in Example 1; Figure 5B This is a schematic diagram of the bidirectional data self-healing process in Example 2.

[0054] Figure 6 This is a hierarchical architecture diagram of a system for non-intrusive rich text annotation of documents according to embodiments of this disclosure. Detailed Implementation

[0055] This disclosure provides a method, system, computer device, and computer-readable storage medium for non-intrusive rich text annotation of files. The solution obtains the path of the currently selected file or folder through the operating system's file manager interface and system clipboard assistance; it stores, verifies, restores, indexes, and retrieves rich text annotation data using a hybrid storage structure consisting of a hidden configuration text file, an NTFS backup data stream, and a local index database; it generates and renders a floating display window based on the mouse cursor position, target display boundary, focus window boundary, and rich text content size; and it maintains the association between rich text annotation data and the corresponding file or folder when files are moved, renamed, migrated across file systems, or when some physical storage media is missing, through file system monitoring, physical annotation scanning, and index synchronization. The rich text annotation data is not written to the original main data stream of the target file, thus avoiding changes to the main data stream content of the target file and the hash value calculated based on that content due to annotation writing.

[0056] The present disclosure will be further described below with reference to the accompanying drawings and specific embodiments. It should be understood that the following embodiments are for illustrative purposes only and are not intended to limit the present disclosure.

[0057] I. Method Implementation Examples

[0058] This embodiment provides a method for non-intrusive rich text annotation of documents. The method can be executed by a computer program residing in a computer device. The computer device can run a Windows operating system and has a file manager interface, a system clipboard, a file system access interface, a monitor coordinate acquisition interface, and a window drawing interface.

[0059] In this embodiment, the focus target is the file or folder currently selected or being operated on by the user. The rich text annotation data can be in Markdown format and includes at least one of the following: text data, image reference data, hyperlink data, and attachment reference data. Image reference data can include the absolute path of a local image, and attachment reference data can include the path of other local files. The annotation verification information is a verification value calculated based on the rich text annotation data using a preset verification algorithm, used to determine whether the read annotation data is complete and valid. The verification value can be a hash value.

[0060] Figure 1 A flowchart illustrating the overall process of non-intrusive rich text annotation for documents. Figure 1 As shown, the method includes:

[0061] Step S1: Obtain the path of the currently selected file or folder, and determine the path as the focus target path.

[0062] Step S2 involves accessing and retrieving the rich text annotation data of the focus target based on the hybrid storage structure consisting of a hidden configuration text file, an NTFS backup data stream, and a local index database, as well as performing cross-validation and data recovery on the annotation data in the two physical storage carriers.

[0063] Step S3: Generate and render a floating display window based on the read rich text annotation data.

[0064] Step S4: Perform physical annotation scanning, index synchronization, and retrieval on the rich text annotation data.

[0065] In each step of this embodiment, the focus target path output in step S1 is used in step S2 to establish the association between the focus target and the rich text annotation data, and is also used in steps S3 and S4 to access the corresponding annotation data. The verified and valid rich text annotation data output in step S2 is displayed in step S3 and forms a local physical annotation record for synchronization in step S4. The search results generated in step S4 are used to locate the corresponding file or folder, or to send the corresponding rich text annotation data to step S3 for display.

[0066] (a) Step S1: Obtain the path of the focus target

[0067] The inputs to step S1 include user operation events in the operating system, foreground window change events, and the window characteristics of the current foreground window; the processing includes obtaining the operating system file manager interface path and obtaining the system clipboard auxiliary path; the output is the absolute path of the valid focus target.

[0068] Step S1 employs two complementary path acquisition methods, also known as a "dual-track path acquisition mechanism." The operating system file manager interface method serves as the first path acquisition track; if the first path acquisition track fails to obtain a valid path, the system clipboard-assisted method is activated.

[0069] Figure 2 for Figure 1 The flowchart for obtaining the focus target path in the method shown is as follows. Figure 2 As shown, step S1 includes sub-step S11 and sub-step S12.

[0070] Sub-step S11: Obtain the focus target path according to the operating system file manager interface method.

[0071] Sub-step S11 includes:

[0072] Sub-step S11a: Obtain the window characteristics of the current foreground window.

[0073] Listen for mouse movement, mouse hover, mouse click, keyboard input, and foreground window changes. When a user selects a file or folder, the foreground window switches, or a preset hover trigger condition is met, obtain the window handle, window title, window hierarchy, and current operation context of the current foreground window.

[0074] Sub-step S11b enumerates active Shell windows.

[0075] The Shell.Application component interface is used to enumerate the active Shell windows in the operating system, read the window title, Z-Order level, current directory path and tab status of each Shell window, and determine each Shell window as a candidate Shell window.

[0076] Sub-step S11c generates matching scores for candidate Shell windows.

[0077] A title matching score is generated based on the correspondence between the current foreground window and the candidate Shell window's title; a window hierarchy score is generated based on the Z-Order hierarchy of the candidate Shell window; and a path matching score is generated based on the correspondence between the current directory path of the candidate Shell window and the current operation context.

[0078] Sub-step S11d calculates the overall matching score.

[0079] The overall matching score for each candidate Shell window is calculated by weighting the scores based on title matching, window hierarchy, and path matching. The weights for each component can be preset based on window recognition accuracy and the operating system environment.

[0080] Sub-step S11e determines the active Shell window or active tab.

[0081] Background shell windows are excluded based on the overall matching score, and the active shell window corresponding to the current foreground window is determined. When the active shell window includes multiple tabs, the active tab is determined based on the activity status of each tab and the current directory path.

[0082] Sub-step S11f: Read and verify the path of the currently selected item.

[0083] The currently selected item is read from the determined active Shell window or active tab, converted into an absolute path of a file or folder, and its existence, validity, and accessibility are determined. If valid, the absolute path is designated as the focus target path; otherwise, proceed to sub-step S12.

[0084] By matching using the window title, Z-Order level, and current directory path simultaneously, the possibility of incorrectly selecting background windows or inactive tabs can be reduced.

[0085] Sub-step S12: Obtain the focus target path using the system clipboard

[0086] Sub-step S12 includes:

[0087] Sub-step S12a: Save the original data and format information in the system clipboard.

[0088] If a valid path is not obtained in the first path acquisition, a thread lock is applied to the system clipboard, an independent buffer is established in memory, and the initial binary data and corresponding clipboard format information in the system clipboard are saved to the independent buffer.

[0089] Sub-step S12b: Send a simulated copy command.

[0090] Send a simulated copy command to the current foreground window, causing the path data of the currently selected file or folder to be written to the system clipboard. The simulated copy command can be a simulated keyboard shortcut Ctrl+C. The current foreground window can be the native Windows Explorer or a third-party file manager capable of responding to standard copy operations.

[0091] Sub-step S12c reads and parses the file path data.

[0092] The system reads file path stream data from the system clipboard after sending the simulated copy command, and parses the file path stream data into the absolute path of the file or folder.

[0093] Sub-step S12d verifies the absolute path.

[0094] Determine if the absolute path exists, if the path format is valid, and if the corresponding object can be accessed; if it is valid, determine it as the focus target path.

[0095] Sub-step S12e: Restore the system clipboard.

[0096] After completing the reading of the file path stream data, the initial binary data and clipboard format information in the independent buffer are written back to the system clipboard within the preset recovery time limit, restoring the system clipboard state before sending the simulated copy command, and releasing the thread lock.

[0097] By saving and restoring the clipboard's binary data and formatting information, it is possible to avoid losing original images, file lists, or other formatted data while only restoring text content. This process can be completed by the computer program disclosed herein within its own process by calling system interfaces or performing simulated copy operations, without needing to inject dynamic link libraries into the foreground file manager process, nor requiring a dedicated annotation interface from a third-party application.

[0098] (ii) Step S2: Mixed storage, cross-validation and data recovery of rich text annotation data

[0099] The inputs to step S2 include the focus target path, focus target type, rich text comment data, comment verification information, and last modification time; the processing includes writing to two physical storage media, data status determination, bidirectional recovery, cross-file system migration recovery, and association maintenance after moving or renaming; the outputs include verified and valid rich text comment data, updated physical comment records, and index records.

[0100] The hybrid storage structure, consisting of a hidden configuration text file, an NTFS backup data stream, and a local index database, is also known as a "three-in-one hybrid storage architecture." The hidden configuration text file forms a physical memo carrier that can migrate with the focus target; the NTFS backup data stream forms a physical memo carrier directly associated with the focus target within a file system that supports this storage method; and the local index database forms a global index layer, supporting keyword retrieval, focus target location, and floating display invocation.

[0101] The hidden configuration text file and the NTFS backup data stream constitute two physical storage carriers. The local index database serves as a retrieval cache, storing the focus target path, focus target name, rich text comment data, comment verification information, comment data status, and last modification time. The comment data in the local index database is an index copy and is not used as a physical storage carrier in the bidirectional self-healing process, nor is it the sole basis for recovery when both physical storage carriers lack valid verification data. The local index database can be an SQLite database.

[0102] Figure 3 This is a flowchart for notes on storage, status determination, and bidirectional self-healing. For example... Figure 3 As shown, step S2 includes sub-steps S21 to S24.

[0103] Sub-step S21: Store rich text annotation data

[0104] Sub-step S21 includes:

[0105] Sub-step S21a: Receive the note editing operation and generate note verification information.

[0106] It receives add, modify, or delete comments for the focused target, obtains the corresponding rich text comment data, and generates comment verification information using a preset verification algorithm. Comment editing operations can be received through a visual editing and control panel or a floating display window with editing functions.

[0107] Sub-step S21b: Determine the storage location and association key of the hidden configuration text file.

[0108] When the focus target is a file, the hidden configuration text file is set in the same directory as the file, and the file name is used as the association key; when the focus target is a folder, the hidden configuration text file is set inside the folder, and the self-reference key that indicates the folder itself is used as the association key.

[0109] In one implementation, the hidden configuration text file is named ".folder_notes.txt" and its self-reference key is "THIS_FOLDER". A note record may include a related key, rich text note data, note validation information, note data status, and last modified time.

[0110] Sub-step S21c writes the rich text annotation data to the hidden configuration text file.

[0111] Based on the determined storage location and association key, the rich text comment data, comment verification information, and last modified time are written to the hidden configuration text file. A new record is added if the corresponding record does not exist; the record is updated if it already exists; when a comment is deleted, the corresponding record is deleted or cleared, and the comment data status is updated.

[0112] Sub-step S21d identifies whether the file system where the focus target is located supports NTFS backup data streams.

[0113] Obtain the file system type and storage capacity of the target file system. If NTFS backup data stream is supported, proceed to sub-step S21e; otherwise, skip writing the backup data stream and record the corresponding status as unsupported or non-existent.

[0114] Sub-step S21e writes the rich text annotation data to the NTFS standby data stream.

[0115] The rich text notes and notes validation information are written to the NTFS backup data stream of the focus target. In one implementation, a backup data stream named "MyNoteData" is set for the file "Design.dwg", forming "Design.dwg:MyNoteData".

[0116] In this embodiment, "non-intrusive" means that the rich text annotation data and annotation verification information are not written to the original main data stream of the target file. The main data stream content of the target file can be read before and after the annotation data is written, and the corresponding MD5 or SHA256 values ​​can be calculated to verify that the main data stream content and corresponding hash value of the target file remain unchanged. Therefore, it is possible to avoid changing the hash value calculated based on the main data stream content of the target file due to annotation writing, and it is beneficial to maintain the digital signature state with the main data stream content as the verification object.

[0117] Sub-step S21f: Create or update local index records.

[0118] Write the focus target path, focus target name, rich text comment data, comment validation information, comment data status, and last modification time to the local index database. Create a new record if the corresponding index record does not exist; update the corresponding fields if it already exists. Increment the global data version number (DataVersion) whenever comment data is added, modified, or deleted.

[0119] Sub-step S22: Perform cross-checking and data recovery on the dual storage media.

[0120] The process described in sub-step S22 is also called "bidirectional self-healing verification". "Bidirectional" means that the notes in the hidden configuration text file can be used to restore the NTFS backup data stream, and the notes in the NTFS backup data stream can also be used to restore the hidden configuration text file.

[0121] Sub-step S22 includes:

[0122] Sub-step S22a reads the note data from the two physical storage media.

[0123] Based on the focus target path, read the NTFS backup data stream and the associated hidden configuration text file respectively, obtain the rich text memo data and memo verification information in each physical storage medium, and record whether the corresponding medium exists, whether it can be accessed, and whether the reading is successful.

[0124] Sub-step S22b verifies the remarks data.

[0125] The same preset verification algorithm used during writing is employed to calculate the current verification value based on the read rich text annotation data, and compare it with the read annotation verification information. If they match, the corresponding annotation data is determined to be valid; if they do not match, no annotation verification information is read, or no rich text annotation data is read, the corresponding annotation data is determined to be invalid or missing.

[0126] Sub-step S22c restores the NTFS backup data stream based on the hidden configuration text file.

[0127] When the NTFS backup data stream is missing or invalid, but the comment data in the hidden configuration text file is valid, if the file system supports the NTFS backup data stream, the rich text comment data and comment verification information in the hidden configuration text file will be written to the NTFS backup data stream; if the file system does not support the backup data stream, the valid data in the hidden configuration text file will be retained and the backup data stream will not be written.

[0128] Sub-step S22d recovers the hidden configuration text file based on the NTFS backup data stream.

[0129] When the hidden configuration text file is missing or invalid, and the memo data in the NTFS standby data stream is valid, the storage location and association key of the hidden configuration text file are re-determined according to the focus target type, and the rich text memo data and memo verification information in the standby data stream are written to the hidden configuration text file.

[0130] Sub-step S22e determines the base preparation annotation data.

[0131] When the annotation data in one physical storage medium is missing or invalid, and the annotation data in another physical storage medium is valid, the valid data is determined as the base annotation data; when the annotation data in both physical storage mediums is valid, and the rich text annotation data and annotation verification information are consistent, the data in either physical storage medium is determined as the base annotation data.

[0132] When the annotation data in both physical storage media is verified to be valid, but the rich text annotation data or annotation verification information is inconsistent, the base annotation data is not determined, and automatic overwriting between the two physical storage media is not performed.

[0133] Sub-step S22f maintains the local index database.

[0134] Given the base text annotation data, query the local index database based on the focus target path. If no corresponding index record exists, generate an index record based on the focus target path and the base text annotation data; if a corresponding index record exists, compare the focus target path, rich text annotation data, annotation validation information, and annotation data status. If they match, retain the existing record; otherwise, update the record based on the base text annotation data.

[0135] After determining the base annotation data and completing the necessary data recovery and index maintenance, output the verified and valid rich text annotation data for display in step S3 or retrieval in step S4. If the annotation data in both physical storage media is valid but the content is inconsistent, automatic overwriting and automatic index updating will not be performed.

[0136] Sub-step S23: Perform comment recovery after cross-file system migration

[0137] Figure 4 The flowchart illustrates the migration, index synchronization, and real-time update processes. For example... Figure 4 As shown, sub-step S23 includes:

[0138] Sub-step S23a involves detecting the migrated NTFS backup data stream.

[0139] When a focus target is transferred from an intermediate file system that does not support NTFS alternate data streams to the current file system that does support NTFS alternate data streams, it is checked whether the migrated focus target lacks an alternate data stream. The intermediate file system can be a FAT32 file system.

[0140] Sub-step S23b: Read the hidden configuration text file that is transferred along with the focus target.

[0141] When a missing backup data stream is detected, the hidden configuration text file that was moved along with the focus target is read. For files, the hidden configuration text file is located in the same directory as the file; for folders, the hidden configuration text file resides inside the folder. Cross-file system recovery is conditional upon the hidden configuration text file being moved along with the focus target.

[0142] Sub-step S23c verifies the notes data and restores the NTFS backup data stream.

[0143] Verify the rich text comment data in the hidden configuration text file; if the verification is valid, write the rich text comment data and comment verification information to the NTFS standby data stream of the focus target.

[0144] Sub-step S23d updates the index records in the current computer device.

[0145] Based on the current path of the focus target, rich text comment data, comment verification information, and the status of the restored comment data, add or update index records in the local index database of the current computer device. The local index database does not need to be moved between different computer devices along with the focus target.

[0146] Sub-step S24: Maintain the associated notes after moving or renaming files.

[0147] The process of monitoring the movement or renaming of the focus target through the file system monitor and maintaining the association between the hidden configuration text file, the NTFS alternate data stream, and the local index records is also known as the "file-level watchdog mechanism".

[0148] Sub-step S24 includes:

[0149] Sub-step S24a: Monitor file system change events.

[0150] Obtain the event type, path before change, and path after change for file system change events using the file system monitor.

[0151] Sub-step S24b: Maintain the association of notes in the hidden configuration text file.

[0152] When a file is renamed, the original filename association key in the hidden configuration text file is updated to the new filename association key; when a file is moved, the corresponding note record is saved to the hidden configuration text file in the same directory as the changed file, and the corresponding record in the original directory is deleted; when a folder is moved or renamed, the folder's own note is saved with a self-reference key inside the changed folder.

[0153] Sub-step S24c: Update the local index records.

[0154] Update the focus target path in the index record to the changed path, and simultaneously maintain the status of the notes data and the last modification time.

[0155] Sub-step S24d maintains the modified NTFS backup data stream.

[0156] When the file system where the changed path is located supports NTFS backup data streams, and the changed focus target lacks a backup data stream, the backup data stream is restored using verified rich text memo data and memo verification information.

[0157] Sub-step S24e processes file changes that occur while the computer program is not running.

[0158] When a file is moved or renamed while the program is not running, and the changed focus target still retains the NTFS backup data stream or the hidden configuration text file that was moved, the physical memo data is read through the physical memo scanning and silent reconciliation mechanism after the program starts again, and the index records are updated or rebuilt according to the changed focus target path.

[0159] When a scan confirms that the focus target has been deleted, or if there is no corresponding focus target and valid physical memo record within the preset storage range, invalid index records should be cleaned up. When a file is moved to a file system that does not support NTFS alternate data streams, and the hidden configuration text file is not moved along with it, physical memo data cannot be reconstructed solely from the original index records.

[0160] (III) Step S3: Generation, rendering and lifecycle management of the floating display window

[0161] The inputs for step S3 include the focus target path, valid rich text annotation data, last modification time, mouse cursor coordinates, target display boundary, and current focus window boundary; the processing includes window size determination, anti-occlusion positioning, rich text rendering, and window state management; the output is a rendered floating display window.

[0162] Step S3 can be triggered in response to changes in the foreground window, changes in the path of the focused target, mouse hover, or mouse click. The system can query the local index database or read from the two physical storage media; when reading from the physical storage media, a two-way self-healing verification can be performed first.

[0163] Step S3 includes sub-steps S31 and S32.

[0164] Sub-step S31: Determine the size and display position of the floating display window.

[0165] Sub-step S31 includes:

[0166] Sub-step S31a: Determine the size to be displayed in the floating display window.

[0167] Parse the rich text annotation data to obtain the text layout content, image reference data, hyperlink data, and attachment reference data. Based on the text layout size, the original size of the local image referenced by the absolute path, the attachment display area, and the available display area of ​​the target monitor, determine the width and height to be displayed in the floating display window.

[0168] When the original size of a local image exceeds the available display area of ​​the floating display window, the scaling size of the image is determined based on the available display width and the original aspect ratio of the image to avoid image distortion or exceeding the window boundaries.

[0169] Sub-step S31b: Obtain the spatial data required for positioning.

[0170] Obtain the absolute screen coordinates of the mouse cursor, the display boundary of the target monitor where the mouse is located, the window boundary of the currently focused window, and the display size of the floating window. In a multi-monitor environment, identify the target monitor based on the screen coordinates of the mouse cursor and read the boundary of the target monitor in the virtual desktop coordinate system.

[0171] Sub-step S31c determines the available display area of ​​the candidate display quadrant.

[0172] Using the mouse cursor coordinates as the origin, the target display is divided into four candidate display quadrants: lower right, upper right, lower left, and upper left. The available display area of ​​each candidate display quadrant is determined based on the display boundaries, the current focus window boundaries, and the size of the floating display window to be displayed.

[0173] Sub-step S31d: Determine the target display quadrant and create a floating display window.

[0174] Choose the target display quadrant from the four candidate display quadrants that can accommodate the floating display window, does not exceed the display boundaries, and avoids the current focus area. If multiple quadrants meet the conditions, you can select based on the available display area, the distance from the current focus area, or a preset quadrant order.

[0175] The window display coordinates are determined based on the target display quadrant, and a borderless, transparent, floating display window that does not acquire system input focus is created through the operating system's top-level window drawing interface.

[0176] Sub-step S31e: Parse and render the rich text annotation data.

[0177] Parse Markdown text into formatted layout; load images based on their absolute paths and render them according to a defined scaling; generate corresponding link display objects for hyperlinks; and generate attachment names, file types, or operable links for attachment reference data.

[0178] The corresponding display objects are arranged in a floating display window, and the last modified time of the rich text notes is displayed in the edge area of ​​the floating display window. In one embodiment, the last modified time is displayed in the upper right corner of the floating display window.

[0179] The aforementioned window size determination, quadrant selection, and rich text rendering together constitute "anti-occlusion and follow positioning." Follow positioning means that the initial pop-up position of the window is determined based on the mouse cursor position at the time of triggering, and does not mean that the window must continuously follow the mouse movement after it is displayed.

[0180] Sub-step S32: Perform lifecycle management on the floating display window.

[0181] Sub-step S32 includes:

[0182] Sub-step S32a executes automatic destruction control based on Euclidean distance.

[0183] When creating a floating display window, set the window to normal state and record the screen coordinates of the mouse cursor as anchor coordinates. ).

[0184] While the floating display window is in the display state, the current coordinates of the mouse cursor are continuously obtained according to a preset polling cycle. And calculate the Euclidean distance D between the current coordinates and the anchor coordinates according to the following formula:

[0185] .

[0186] in, This represents the horizontal coordinate value of the anchoring coordinate; The vertical coordinate value representing the anchor coordinate; This represents the horizontal coordinate value of the current coordinate. The vertical coordinate value represents the current coordinate; D represents the distance the mouse cursor has moved relative to the anchor position.

[0187] When the floating display window is in a normal state, the Euclidean distance D is greater than the dynamic release threshold, and the window is not in a drag-locked state, the floating display window is destroyed and the window resources it occupies are released. The dynamic release threshold can be 150 pixels, or it can be set according to the display resolution, window size, or user configuration.

[0188] Sub-step S32b performs window stripping and fixed state transition.

[0189] Listen for pinned operations on the floating display window in its normal state, such as double-clicking the top edge of the floating display window. When a pinned operation is detected, the current floating display window is detached from the global instance that points to the window in its normal state, added to an independent window queue, and its state is changed from normal to pinned or independent suspended.

[0190] Automatic destruction control based on Euclidean distance is stopped for floating display windows in a fixed or independently suspended state. When the focus target changes, a new floating display window in a normal state is created according to the new focus target, while the fixed state windows associated with other focus targets in the independent window queue are retained, thereby enabling simultaneous comparison of multiple file notes on the same screen.

[0191] (iv) Step S4: Physical note scanning, index synchronization and keyword retrieval

[0192] The inputs for step S4 include a preset storage range, physical notes records, database index records, search keywords, and DataVersion; the processing includes multi-threaded scanning, directory pruning, silent reconciliation, version linkage, and fuzzy search; the outputs include synchronized index records, scan progress, task status, and a list of search results.

[0193] In step S4, a local physical memo record is obtained, which is formed by the hidden configuration text file and the memo data in the NTFS backup data stream. The local physical memo record is synchronized with the index record in the local index database, and the local index database is queried according to the search keywords to obtain the search results.

[0194] Step S4 includes sub-steps S41 to S43.

[0195] Sub-step S41: Perform physical memo scanning and index synchronization through a silent reconciliation mechanism.

[0196] Sub-step S41 includes:

[0197] Sub-step S41a: Obtain the preset storage range and divide the scanning tasks.

[0198] When the system starts up or receives a scan command, it acquires the disk, partition, or directory to be scanned, divides it into multiple scan tasks based on the directory structure, and assigns these tasks to multiple scan threads. The preset storage range can be determined by the system's runtime configuration or selected by the user.

[0199] Each scanning thread sends the scanning progress and task status of its corresponding scanning task to the front-end interface, so that the front-end interface can display the corresponding status during the background scanning and continue to respond to note editing, keyword search, or floating display operations.

[0200] Sub-step S41b involves pruning based on the directory blacklist.

[0201] The current directory is compared with a preset directory blacklist. If a match is found, the current directory and its subdirectories are skipped. The directory blacklist may include the recycle bin directory and other system directories that do not need to be scanned.

[0202] Sub-step S41c generates a local physical remarks record.

[0203] Extract the focus target path, focus target name, rich text comment data, comment verification information, comment data status, and last modification time from the scanned NTFS backup data stream and hidden configuration text file to form a physical comment record, and perform data validity verification and data recovery when the conditions are met in step S22.

[0204] Sub-step S41d: Merge physical remarks records.

[0205] Summarize the physical notes generated by each scanning thread, and merge duplicate records based on the focus target path or target identifier.

[0206] Sub-step S41e involves adding, updating, or deleting index records.

[0207] The physical memo record is compared with the index record in the local index database. If the corresponding index record does not exist, a new record is added; if the record already exists but the path, rich text memo data, memo validation information, or memo data status are inconsistent, the index is updated based on the physical memo record; if it is confirmed that there is no focus target and valid physical memo record corresponding to the index record within the preset storage range, the corresponding index record is deleted.

[0208] If the notes in both physical storage media are verified to be valid but the content is inconsistent, the index records will not be automatically updated based on the data in either physical storage media.

[0209] Sub-step S42: Refresh the front-end search results via lock-free UI linkage

[0210] DataVersion is incremented when rich text memo data is added, modified, deleted, or data is restored, or when index records are added, updated, or deleted.

[0211] The front-end search interface obtains the current DataVersion through an independent listening loop or a heartbeat listening loop and compares it with the previous DataVersion saved on the front end. If the two version numbers match, the current search result list is maintained; if they do not match, the search result list is reloaded from the local index database, and the previous DataVersion is updated with the current DataVersion.

[0212] The scan progress and task status are used to provide feedback on the background scanning process. DataVersion is used to indicate whether the searchable data has changed and to control the refresh of the search results list. The "lock-free UI linkage" is used to represent the decoupling relationship between background data processing and front-end list refresh based on DataVersion, which does not restrict access to the underlying database or shared data and does not use any concurrency control measures.

[0213] Sub-step S43: Perform keyword retrieval and process retrieval results

[0214] The system receives search keywords input by the user and performs fuzzy matching on at least one of the following in the local index database: the name of the focus target, the path of the focus target, and the rich text notes, to obtain the corresponding index record.

[0215] A search result list is generated based on the focus target path, rich text notes, and last modification time in the matched index records, and the search result list is output to the front-end search interface.

[0216] When a selection operation for a target search result is received, the operating system file manager is invoked according to the focus target path corresponding to the target search result to locate the corresponding file or folder; or the corresponding rich text annotation data, focus target path and last modification time are sent to step S3 for floating display.

[0217] The local index database serves as a globally regenerable index layer and retrieval cache, handling keyword retrieval, target location, and interface invocation functions; the hidden configuration text file and NTFS backup data stream serve as two physical storage carriers, handling the physical storage, cross-validation, and data recovery functions of the notes data.

[0218] (V) Application Example 1: Real-time observation of the annotation process

[0219] Figure 5A This is a diagram illustrating the interaction logic of the floating display window. (Example) Figure 5A As shown, the interactive logic of this floating display window includes:

[0220] (1) The user moves the mouse in the operating system, hovers or clicks to select the external power supply _t5.dwg.

[0221] (2) The system background detects the focus switch and instantly completes context awareness and database (SQLite) query to obtain rich text notes and last modification timestamp.

[0222] (3) The floating engine adaptively calculates a reasonable window size in the lower right corner of the mouse coordinates, calls the top-level non-focus drawing interface to pop up a borderless floating window, renders the Markdown text into a formatted layout, loads the local image referenced by the absolute path, and displays "2026-06-11 16:13" in the upper right corner.

[0223] (4) When the user moves the mouse away from the threshold of more than 150 pixels, the floating window will be automatically and smoothly destroyed without generating any operational redundancy.

[0224] (5) The user clicks the file again and double-clicks the top edge of the floating window to trigger the "pin" command. The system switches the window state to "independent suspension". Then the user clicks another file, and the system generates a brand new floating window, while the original fixed floating window of external_t5.dwg remains on the screen, allowing the user to compare the notes of the two files on the same screen.

[0225] (vi) Application Example 2: Rich Text Annotation, Cross-Disk Migration and Retrieval Self-Healing Process of Engineering Drawings

[0226] Figure 5B This is a schematic diagram of a two-way data self-healing process. (For example...) Figure 5B As shown, the bidirectional data self-healing process in this embodiment includes:

[0227] (1) The user selects the external power_t5.dwg file in the operating system folder and enters the remarks information in the floating box of this invention (select whether to insert pictures or other files according to the requirements): "20260611 Design requirements modification".

[0228] (2) The system identifies the file object and writes the above text into external_t5.dwg:MyNoteData (ADS); at the same time, it secretly generates .folder_notes.txt on the desktop and writes the record external_t5.dwg|20260611 Design requirement modification. At this time, the hash verification value of the underlying external_t5.dwg remains unchanged.

[0229] (3) The database manager takes over the transaction, inserts the path and notes into the local index, and increments the data version number DataVersion from 100 to 101.

[0230] (4) The user closes the software. Then, the external_t5.dwg and .folder_notes.txt are copied to the E:\Projects directory of another computer using a USB flash drive (the ADS stream is physically lost due to the cross-FAT32 file system).

[0231] (5) When the user launches this publicly available software on a new computer, the user initiates a search containing the keyword "design requirements" through the front end, or hovers the mouse directly over the file. The system attempts to read the ADS but fails, but successfully reads the .folder_notes.txt file in the same directory.

[0232] (6) Trigger self-healing mechanism: The system extracts the record in the txt file, reconstructs the missing ADS stream in E:\Projects\Design.dwg, and upserts this record into the global index library of the new computer to complete the broken link repair and rich text floating display.

[0233] II. System Implementation Examples

[0234] This embodiment also provides a system for non-intrusive rich text annotation of documents, including a context-aware and path acquisition module, a note editing and hybrid storage module, a self-healing and index maintenance module, an adaptive floating display module, and an index retrieval module.

[0235] The context awareness and path acquisition module is used to listen for operating system events and obtain the focused target path through the Shell.Application component interface, window feature weighted matching, and system clipboard assistance.

[0236] The note editing and hybrid storage module is used to receive note editing operations, generate note verification information, determine the location and association key of the hidden configuration text file according to the focus target type, write the note data to the hidden configuration text file and the available NTFS standby data stream, and create or update index records in the local index database.

[0237] The self-healing and index maintenance module is used to detect the status of the memo data in two physical storage media. When the memo data in one physical storage media is missing or invalid, and the other is valid, the corresponding data is restored. It is also used to listen for file movement or renaming events, scan physical memo records, perform directory blacklist pruning, maintain index records and DataVersion, and output the scanning progress and task status to the front end.

[0238] The adaptive floating display module is used to determine the size of the floating display window based on the rich text annotation data, determine the display position based on the mouse cursor coordinates, the monitor boundary and the focus window boundary, load local images referenced by absolute paths, render Markdown content and the last modified time, and perform automatic destruction or fixed retention based on Euclidean distance and window state.

[0239] The index retrieval module receives search keywords, performs fuzzy matching on at least one of the following: the name of the focus target, the path of the focus target, and the rich text notes, generates a list of search results, and locates the file or folder or calls the adaptive floating display module based on the selected operation.

[0240] Figure 6 This is a layered architecture diagram of a system for non-intrusive rich text annotation of documents according to embodiments of this disclosure. Figure 6 As shown, the system includes a system base and environment adaptation layer, a metadata processing and engine layer, a core control and human-computer interaction layer, and a system initialization and access layer, and adopts a combination of event-driven and metadata-driven operation mode.

[0241] The system base and environment adaptation layer may include a system context-aware listener, a multi-source media input / output processor, and a native resource manager bridging component, used to listen for operating system events, read and write hidden configuration text files and NTFS backup data streams, and call the Shell.Application component interface, system clipboard, and file system interface.

[0242] The metadata processing and engine layer may include a global lightweight index engine, a rich text renderer and visualizer, a data lifecycle management unit, and a retrieval service interface. It is used to maintain the local index database, parse and render rich text memo data, manage memo data status, DataVersion and independent window queues, and respond to retrieval requests.

[0243] The core control and human-computer interaction layer may include event routing and core business engine, adaptive floating rendering terminal and visual editing and control panel, used to distribute system events, generate and manage floating display windows, receive notes editing, search range configuration and system control operations, and display scanning progress and task status.

[0244] The system initialization and access layer may include a runtime environment loading module, a configuration and security policy loading module, and a security and permission verification unit. These modules are used to load the runtime environment, parse preset storage ranges, directory blacklists, dynamic release thresholds, and other runtime configurations, and perform initialization and access permission verification for each functional module.

[0245] III. Examples of Computer Equipment

[0246] This embodiment also provides a computer device, including a memory and a processor, wherein the memory stores a computer program; when the processor executes the computer program, it implements the aforementioned method for non-intrusive rich text annotation of documents.

[0247] The processor can acquire the focus target path through a dual-track path acquisition mechanism, write rich text annotation data and annotation verification information to a hidden configuration text file and an available NTFS backup data stream, and create or update an index copy in the local index database; perform bidirectional self-healing verification using the verified valid annotation data in the two physical storage carriers as the recovery source; maintain the annotation association after movement or renaming through a file-level watchdog follow mechanism; generate and manage floating display windows through anti-occlusion and follow positioning, Euclidean distance lifecycle management and window state transition; and perform index synchronization and retrieval through a silent reconciliation mechanism and lock-free UI linkage.

[0248] The memory may also store system runtime configuration, local index database, directory blacklist, DataVersion, independent window queue, and intermediate data generated during the execution of the methods of this embodiment. The computer device may also include communication interfaces, display devices, input devices, and file system access interfaces, and may be a desktop computer, laptop computer, workstation, server, or other computing device.

[0249] IV. Examples of Computer-Readable Storage Media

[0250] This embodiment also provides a computer-readable storage medium storing a computer program; when the computer program is executed by a processor, it implements the aforementioned method for non-intrusive rich text annotation of documents.

[0251] The computer-readable storage medium may be a hard disk, solid-state drive, read-only memory, random access memory, flash memory, optical disk, removable storage medium, or other non-transitory storage medium.

[0252] V. General Instructions

[0253] The contents used in this embodiment, such as "Design.dwg (2GB in size)," "Design.dwg:MyNoteData (ADS)," ".folder_notes.txt," "Design.dwg|Solution V2.," "E:\Projects\Design.dwg," "Block A Planning.docx," "Block B Planning.docx," SQLite database, Ctrl+C simulated copy command, 150-pixel threshold, DataVersion incrementing from 100 to 101, and "2026-06-11 10:30," are used to illustrate a specific implementation of this disclosure and are not used to limit file names, file sizes, rich text comments, alternate data stream names, hidden configuration text file names, configuration record formats, migration paths, database formats, simulated copy commands, distance thresholds, data version numbers, or time information.

[0254] The corresponding parameters and implementation form can be determined according to the operating system environment, file system type, display device configuration and application requirements, but the technical relationship between the dual-track path acquisition mechanism, the three-in-one hybrid storage architecture, the two-way self-healing verification, the file-level watchdog follow-up mechanism, the anti-occlusion and follow positioning, the Euclidean distance lifecycle management, the window peeling and state transition, the silent reconciliation mechanism and the lock-free UI linkage should be maintained.

[0255] For steps, sub-steps, and sub-sub-steps, when there are clear input-output relationships, conditional dependencies, or data flow relationships, they should be executed according to the corresponding technical relationships; for processes without prior-to-back dependencies, they can be executed sequentially, in parallel, or in an interleaved manner, but the corresponding inputs, processing actions, outputs, and output destinations should not be changed.

[0256] The aforementioned methods and steps can be implemented by a processor executing a computer program, or by software modules, hardware modules, or a combination of software and hardware functional modules. Modules or units in the system can be centrally or distributed; multiple modules can be merged, and a single module can be divided into multiple functional units without changing the input, processing actions, output, or purpose.

[0257] This disclosure does not limit the specific programming language, program framework, database framework, user interface framework, or hardware and software combination method. The technical features in the foregoing different embodiments or implementations can be combined with each other unless they contradict or exclude each other. The above embodiments are used to enable those skilled in the art to understand the technical solutions and implementation processes of this disclosure, and are not intended to limit this disclosure.

Claims

1. A method for non-intrusive rich text annotation of documents, characterized in that, include: Step S1: Obtain the path to the focus target; Get the path of the currently selected file or folder, and set the path as the focus target path; Step S2: Based on the hybrid storage structure consisting of a hidden configuration text file, an NTFS backup data stream, and a local index database, the rich text annotation data of the focus target is accessed and cross-verified by the dual storage carriers and the data is recovered. The rich text annotation data and annotation verification information corresponding to the focus target are obtained, and the rich text annotation data and annotation verification information are stored in a hidden configuration text file associated with the focus target. When the file system where the focus target is located supports NTFS backup data stream, the rich text annotation data and annotation verification information are stored in the NTFS backup data stream of the focus target. At the same time, an index record corresponding to the focus target is created or updated in the local index database. The dual storage carriers are the hidden configuration text file and the NTFS backup data stream. When reading the rich text annotation data, the status of the annotation data in the hidden configuration text file and the NTFS backup data stream is detected; when the annotation data in one storage medium is missing or invalid, and the annotation data in the other storage medium is valid, the missing or invalid annotation data is self-healed using the valid annotation data, and the local index database is maintained based on the valid annotation data. Step S3: Based on the read rich text annotation data, generate and render a floating display window; The corresponding rich text annotation data is obtained according to the focus target path, and the rich text annotation data is displayed through a floating display window. Step S4: Index, synchronize, and retrieve the rich text annotation data; Obtain the local physical memo record formed by the hidden configuration text file and the memo data in the NTFS standby data stream, synchronize the local physical memo record with the index record in the local index database, and query the local index database according to the search keywords to obtain the search results.

2. The method for non-intrusive rich text annotation of documents according to claim 1, characterized in that, Step S1, which involves obtaining the path of the currently selected file or folder, includes: Sub-step S11: Obtain the path of the currently selected file or folder according to the operating system's file manager interface; The system obtains the window characteristics of the current foreground window, enumerates all active shell windows in the operating system through the Shell.Application component interface, matches the window characteristics of the current foreground window with the window title, window level, and current directory path of each shell window to determine the active shell window or active tab corresponding to the current foreground window, and reads the selected item path in the active shell window or active tab; it validates the validity of the selected item path, and if the selected item path is valid, it determines the selected item path as the focus target path; Sub-step S12: When a valid path to the selected item cannot be obtained through the operating system file manager interface, the path to the currently selected file or folder is obtained using the system clipboard; Save the original data and corresponding clipboard format information in the system clipboard; send a simulated copy command to the current foreground window; read the file path data corresponding to the currently selected item from the system clipboard; parse the file path data into an absolute path of a file or folder; validate the absolute path; and if the absolute path is validated, determine the absolute path as the focus target path; restore the original data and corresponding clipboard format information to the system clipboard.

3. The method for non-intrusive rich text annotation of documents according to claim 2, characterized in that, In sub-step S11, the matching based on the window characteristics of the current foreground window with the window title, window hierarchy, and current directory path of each Shell window includes: Based on the correspondence between the window title of the current foreground window and the window titles of each Shell window, the Z-Order level of each Shell window, and the current directory path of each Shell window, generate the title matching score, window level score, and path matching score for each Shell window. The overall matching score for each Shell window is calculated by weighting the title matching score, window hierarchy score, and path matching score according to their respective weights. Based on the comprehensive matching score, background shell windows are excluded, a unique active shell window corresponding to the current foreground window is determined, and when the unique active shell window includes multiple tabs, the active tab in the unique active shell window is determined; In sub-step S12, saving the original data and corresponding clipboard format information in the system clipboard includes: applying a thread lock to the system clipboard and saving the initial binary data and corresponding clipboard format information in the system clipboard to an independent memory buffer; In sub-step S12, restoring the original data and the corresponding clipboard format information to the system clipboard includes: writing the initial binary data and the corresponding clipboard format information in the independent memory buffer back to the system clipboard, and releasing the thread lock.

4. The method for non-intrusive rich text annotation of documents according to claim 1, characterized in that, In step S2, storing the rich text annotation data for the focused target includes: Receive a note editing operation for the focus target, obtain rich text note data corresponding to the focus target, and generate note verification information based on the rich text note data using a preset verification algorithm; The storage location of the hidden configuration text file and the association key of the rich text annotation data are determined according to the target type of the focus target. Specifically, when the focus target is a file, the hidden configuration text file is set in the same directory as the file, and the file name is used as the association key; when the focus target is a folder, the hidden configuration text file is set inside the folder, and a self-referencing key that indicates the folder itself is used as the association key. According to the storage location and the association key, the rich text annotation data, the annotation verification information and the last modification time are written into the hidden configuration text file; Identify whether the file system where the focus target is located supports NTFS standby data stream, and if the file system where the focus target is located supports NTFS standby data stream, write the rich text comment data and the comment verification information into the NTFS standby data stream of the focus target; The focus target path, the rich text annotation data, the annotation verification information, the annotation data status, and the last modification time are written into the local index database to create or update the index record corresponding to the focus target.

5. The method for non-intrusive rich text annotation of documents according to claim 1, characterized in that, In step S2, the cross-verification and data recovery of the dual storage media includes: Based on the focus target path, read the NTFS backup data stream and the rich text comment data and corresponding comment verification information in the hidden configuration text file respectively; A preset verification algorithm is used to calculate the current verification value based on the rich text annotation data read from each storage medium, and the current verification value is compared with the corresponding annotation verification information. When the current verification value matches the corresponding memo verification information, the memo data in the corresponding storage medium is determined to be valid; when the current verification value does not match the corresponding memo verification information, the memo verification information is not read, or the rich text memo data is not read, the memo data in the corresponding storage medium is determined to be invalid or missing. When the NTFS backup data stream is missing or the annotation data in it is invalid, and the annotation data in the hidden configuration text file is valid, if the file system where the focus target is located supports the NTFS backup data stream, the rich text annotation data and annotation verification information in the hidden configuration text file are written into the NTFS backup data stream of the focus target. When the hidden configuration text file is missing or the annotation data in it is invalid, and the annotation data in the NTFS backup data stream is valid, the storage location and association key of the hidden configuration text file are re-determined according to the target type of the focus target, and the rich text annotation data and annotation verification information in the NTFS backup data stream are written into the hidden configuration text file. When the annotation data in one of the two storage media is missing or invalid, and the annotation data in the other storage media is valid, the rich text annotation data, annotation verification information and annotation data status in the other storage media are determined as the base annotation data. When the annotation data in both storage media is verified to be valid, and the rich text annotation data and annotation verification information of the two are consistent, the rich text annotation data, annotation verification information and annotation data status in either storage media are determined as the base annotation data. Query the local index database to see if there is an index record corresponding to the focus target; if there is no corresponding index record, add an index record based on the focus target path and the base annotation data; if there is a corresponding index record, compare the focus target path, rich text annotation data, annotation verification information, and annotation data status in the index record with the corresponding data in the focus target path and the base annotation data. If the comparison results are consistent, retain the index record; if the comparison results are inconsistent, update the index record based on the focus target path and the base annotation data.

6. The method for non-intrusive rich text annotation of documents according to claim 1, characterized in that, Step S3 includes: Sub-step S31: Perform anti-obstruction positioning on the floating display window; The corresponding rich text annotation data is obtained according to the focus target path. The display position of the floating display window is determined according to the screen coordinates of the mouse cursor, the display boundary of the target display, and the window boundary of the current focus window. The rich text annotation data is then displayed at the display position through the floating display window. Sub-step S32: Perform lifecycle management on the floating display window; Based on the movement distance of the mouse cursor relative to the initial anchor position of the floating display window and the window state of the floating display window, the floating display window is either automatically destroyed or fixedly retained.

7. The method for non-intrusive rich text annotation of documents according to claim 6, characterized in that, Sub-step S31 includes: Obtain the screen coordinates of the mouse cursor, the display boundary of the target display where the mouse cursor is located, the window boundary of the currently focused window, and the display size of the floating display window; Using the screen coordinates of the mouse cursor as the origin, the target display is divided into four candidate display quadrants, and the available display area of ​​each candidate display quadrant is determined according to the display boundary of the target display, the window boundary of the current focus window, and the display size of the floating display window. Based on the available display area of ​​each candidate display quadrant, select from the four candidate display quadrants the candidate display quadrant that can accommodate the floating display window, ensures that the floating display window does not exceed the display boundary of the target display and avoids the current operation focus, and select the candidate display quadrant as the target display quadrant; The display position of the floating display window is determined according to the target display quadrant, and a borderless, transparent floating display window that does not acquire system input focus when displayed is created at the display position. The rich text annotation data is displayed through the floating display window.

8. The method for non-intrusive rich text annotation of documents according to claim 6, characterized in that, Sub-step S32 includes: Sub-step S32a: Perform automatic destruction control based on Euclidean distance on the floating display window; Set the newly created floating display window to normal state, and when creating the floating display window, record the screen coordinates of the mouse cursor as anchor coordinates. ; During the display of the floating display window, the current coordinates of the mouse cursor are obtained through coordinate polling. The Euclidean distance D between the current coordinates and the anchor coordinates is calculated according to the following formula: D= ； in, and These represent the horizontal and vertical coordinate values ​​of the anchoring coordinates, respectively. and These represent the horizontal and vertical coordinate values ​​of the current coordinates, respectively. When the floating display window is in the normal state, the Euclidean distance D is greater than the dynamic release threshold, and the floating display window is not in the drag-lock state, the floating display window is destroyed and the window resources occupied by the floating display window are released. Sub-step S32b involves performing window peeling and fixed state transition on the floating display window; When a fixed operation is detected on a floating display window in the normal state, the floating display window is detached from the global instance that points to the floating display window in the current normal state, the detached floating display window is added to an independent window queue, and the floating display window is changed from the normal state to the fixed state; the automatic destruction control based on the Euclidean distance D is stopped for the floating display window in the fixed state; when the focus target changes, a new normal state floating display window is created for the changed focus target, and the fixed state floating display windows associated with different focus targets are retained through the independent window queue.

9. The method for non-intrusive rich text annotation of documents according to claim 1, characterized in that, Step S4 includes: Sub-step S41: Perform physical memo scan and index synchronization; When the system starts up or receives a scan instruction for a preset storage range, the preset storage range is divided into multiple scan tasks according to the directory structure of the preset storage range, and the multiple scan tasks are assigned to multiple scan threads; When each scanning thread executes its corresponding scanning task, it skips directories and their subdirectories that match the preset directory blacklist. Extract the focus target path, rich text comment data, comment verification information, comment data status and last modification time from the scanned NTFS backup data stream and hidden configuration text file to form the corresponding local physical comment record, and merge the local physical comment records formed by each scanning thread. Compare the local physical memo record with the index record in the local index database; When there is no index record corresponding to the local physical memo record in the local index database, an index record is added based on the local physical memo record; When an index record corresponding to the local physical memo record exists in the local index database, and the focus target path, rich text memo data, memo verification information, or memo data status in the index record are inconsistent with the corresponding data in the local physical memo record, the index record is updated according to the local physical memo record. When an index record exists in the local index database, and it is confirmed that there is no focus target and local physical note record corresponding to the index record within the preset storage range, the index record is deleted. Sub-step S42: Refresh the front-end search results based on the global data version number; When the rich text annotation data is added, modified, deleted, or self-healed and rebuilt, or when the index records in the local index database are added, updated, or deleted, the global data version number DataVersion is incremented. The current global data version number is obtained through the listening loop of the front-end search interface, and the current global data version number is compared with the previous global data version number saved in the front-end search interface. When the current global data version number is consistent with the previous global data version number, the current search result list in the front-end search interface is maintained; when the current global data version number is inconsistent with the previous global data version number, the search result list is reloaded from the local index database, and the previous global data version number is updated with the current global data version number. Sub-step S43: Perform keyword retrieval and retrieval result processing; The system receives search keywords input through the front-end search interface, and performs fuzzy matching on at least one of the focus target name, focus target path, and rich text annotation data in the local index database based on the search keywords to obtain index records that match the search keywords. A search result list is generated based on the focus target path, rich text notes, and last modification time in the matched index records, and the search result list is output to the front-end search interface; When a selection operation for a target search result in the search results list is received, the corresponding file or folder is located according to the focus target path corresponding to the target search result, or the rich text annotation data, focus target path and last modification time corresponding to the target search result are sent to step S3 for floating display.

10. A system for non-intrusive rich text annotation of documents, characterized in that, include: The context awareness and path acquisition module is used to obtain the path of the currently selected file or folder and determine the path as the focus target path; The note editing and hybrid storage module is used to obtain rich text note data and note verification information corresponding to the focus target, store the rich text note data and note verification information in a hidden configuration text file associated with the focus target, and when the file system where the focus target is located supports NTFS backup data stream, store the rich text note data and note verification information in the NTFS backup data stream of the focus target, and at the same time create or update the index record corresponding to the focus target in the local index database. The self-healing and index maintenance module is used to read and detect the status of the memo data in the hidden configuration text file and the NTFS backup data stream. When the memo data in one storage medium is missing or invalid, and the memo data in the other storage medium is valid, the module uses the valid memo data to perform self-healing processing on the missing or invalid memo data, and maintains the local index database based on the valid memo data. The self-healing and index maintenance module is also used to obtain local physical memo records from the NTFS backup data stream and the hidden configuration text file, and synchronize the local physical memo records with the index records in the local index database. The adaptive floating display module is used to obtain the corresponding rich text annotation data according to the focused target path, and display the rich text annotation data through a floating display window. The index retrieval module is used to receive search keywords, query the local index database based on the search keywords, and generate and output the corresponding search results.

11. A computer device, characterized in that, include: A memory on which computer programs are stored; A processor that, when executing the computer program, implements a method for non-intrusive rich text annotation of documents as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program; When the computer program is executed by the processor, it implements the method for non-intrusive rich text annotation of documents as described in any one of claims 1 to 9.

Images