Browser large file downloading method and device

Abstract

The invention discloses a method and equipment for downloading a large file of a browser, belongs to the technical field of front-end Web, and is used for solving the problems that a large file downloading scheme in a traditional browser environment is low in memory use efficiency and data storage efficiency, insufficient in network interruption processing capability and lack of effective integration of a browser underlying technology, and the network interruption processing capability is poor. And offline caching and high-efficiency recovery are difficult to realize. The method comprises the steps of fragmenting a target file in a file downloading task according to a preset fragmentation rule, and creating a fragmentation downloading task for each fragmentation; dynamically distributing fragmented downloading tasks through a parallel task pool; after each fragment downloading task is completed, the downloaded fragment data and metadata thereof are stored through an IndexedDB database, and integrity verification of the fragment data is carried out; according to a fragment integrity verification result, re-downloading the current fragment; and after all fragment downloading tasks are executed, reading all fragment data according to a fragment sequence and splicing the fragment data into a complete file.

Description

Technical Field

[0001] The present invention relates to the field of front-end Web technology, and in particular to a browser large file downloading method and device. Background Art

[0002] When downloading large files in a traditional browser environment, there are multiple challenges and limitations. The primary problem is the limitation of memory usage: traditional solutions require that when downloading large files, the entire data file must be loaded into memory completely. This practice can easily trigger a memory overflow error, which in turn causes the browser to crash, seriously affecting the user experience and data integrity.

[0003] Secondly, network stability has become another major obstacle. The traditional HTTP request mechanism is unable to handle network interruptions and lacks an automatic resuming mechanism. Once the network connection is interrupted during the download process, users often need to download again from the beginning, which not only wastes precious time and bandwidth resources, but also greatly reduces download efficiency.

[0004] Furthermore, the limitations of storage solutions cannot be ignored. Existing browser storage technologies such as LocalStorage have relatively limited storage capacity and cannot meet the needs of large file shard storage. Even if shard storage is possible, when merging these shard data, they all need to be loaded into memory for processing. This step is not only inefficient, but may also cause memory problems again.

[0005] In addition, existing technologies have not been able to fully integrate and utilize advanced features of the browser's underlying capabilities, such as Service Worker and IndexedDB. These technologies could have provided users with offline caching and efficient data recovery capabilities, but due to the lack of corresponding integration strategies, these potentials have not been fully realized. This situation has greatly limited the effective application of traditional download solutions in high-load and high-demand scenarios such as cloud storage, and cannot meet the growing demand for online data storage and access. Summary of the invention

[0006] The embodiment of the present invention provides a browser large file download method and device, which are used to solve the following technical problems: large file download solutions in traditional browser environments have low memory usage efficiency and data storage efficiency, insufficient network interruption processing capabilities, and lack of effective integration of browser underlying technologies, making it difficult to achieve offline caching and efficient recovery.

[0007] The embodiment of the present invention adopts the following technical solution: On the one hand, an embodiment of the present invention provides a method for downloading large files from a browser, the method comprising: intercepting a file download request from a browser through a Service Worker script, and proxying the file download task to a background thread for execution; Segment the target file in the file download task according to a preset segmentation rule, and create a segment download task for each segment; Creating a parallel task pool, and dynamically allocating the segment download tasks through the parallel task pool; After each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; According to the fragment integrity check result, re-download the current fragment; After all the shard download tasks are completed, all the shard data are read in the IndexedDB database in shard order and spliced ​​into a complete file; After the complete file is written to the user-specified path, the corresponding shard data and its metadata are deleted in the IndexedDB database to release storage space.

[0008] In a feasible implementation, the target file in the file download task is segmented according to a preset segmentation rule, and a segment download task is created for each segment, specifically including: Obtain the file size of the target file, and retrieve the currently set preset sharding rules; wherein the preset sharding rules at least include: sharding according to a fixed sharding size, sharding according to a preset percentage of the target file size, and sharding according to a user-defined sharding size; Based on the preset sharding rule and the file size, the number of shards and the shard size of each shard data are calculated to shard the target file; Create an identifier for each shard data and create a shard download task for each shard; At the same time, a target file metadata record table and a shard metadata record table are created in the IndexedDB database to store the metadata of the target file and the metadata of the shard data; wherein the metadata of the target file includes at least: the file size, file type, number of shards and hash value of each shard of the target file; the metadata of the shard data includes at least: the shard identifier, start byte, end byte, download status, hash value, number of retries and last update time of the shard data.

[0009] In a feasible implementation, creating a parallel task pool and dynamically allocating the segment download tasks through the parallel task pool specifically includes: Obtain the concurrent limit of the current browser and create a parallel task pool; the number of parallel threads in the parallel task pool is the same as the concurrent limit; The parallel task pool is cyclically filled through a task queue mechanism, and unexecuted tasks are stored in a waiting queue to dynamically allocate the segment download tasks.

[0010] In a feasible implementation, after each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; according to the shard integrity check result, the current shard is re-downloaded, specifically including: After each shard download task is completed, the downloaded binary shard data is stored in the IndexedDB database and associated with the corresponding shard metadata record table in the IndexedDB database; Calculate the hash value of the downloaded shard data and compare it with the hash value of the shard recorded in the target file metadata record table. If the comparison is consistent, update the download status in the shard metadata record table to completed. If the comparison is inconsistent, trigger the automatic retry logic to re-download the shard data; trigger automatic retry up to 3 times, and update the retry count field of the shard in the IndexedDB database before each retry; After the number of retries is exceeded, the download status of the shard data is marked as "failed", and the user is prompted to intervene manually through the user interface.

[0011] In a feasible implementation manner, before re-downloading the current segment according to the segment integrity check result, the method further includes: Performing interruption detection during the segment download process to determine the interruption cause; wherein the interruption cause includes network interruption and other causes; When the interruption reason is a network interruption, the unfinished shard request information is stored in the offline task table of the IndexedDB database; wherein the shard request information includes at least the shard URL, shard index and request time; When the network is detected to be restored, the offline task resuming is automatically triggered by listening to the sync event, and the unfinished segment download tasks are read from the offline task table, re-added to the task queue, and executed first; When the terminal reason is other reasons, the downloaded shard list is read from the IndexedDB database to determine the breakpoint; the unfinished shard download tasks after the breakpoint are re-added to the task queue to perform breakpoint download recovery.

[0012] In a feasible implementation, the file download request of the browser is intercepted by a Service Worker script, and the file download task is delegated to the Service Worker thread for execution, which specifically includes: Register the Service Worker script through the navigator.serviceWorker.register method and specify its scope as the root path to ensure that all file download requests can be intercepted; The browser's file download request is intercepted through the registered Service Worker script, and the intercepted file download task is delegated to the background thread for execution.

[0013] In a feasible implementation manner, the method further includes: During the shard data download process, the data stream of the current shard data is written to the browser's persistent disk space in real time through the Streams API. At the same time, the data stream is read in real time from the persistent disk space through the parallel thread in the memory for downloading, and the downloaded data stream is directly written to the disk file.

[0014] In a feasible implementation manner, the method further includes: After each shard is processed, memory resources are released immediately, and residual data is forcibly cleaned up through the WeakMap garbage collection mechanism to prevent memory leaks; For repeated download requests for the same target file, determine whether the target file has changed; If there is no change, directly read the shard data stored in the IndexedDB database; If a change occurs, the shard data of the unchanged part in the IndexedDB database is read, and only the shard data of the changed part is downloaded again to reduce redundant traffic consumption.

[0015] In a feasible implementation, it specifically includes: The number of shards that have been downloaded is obtained from the metadata download status change event of the IndexedDB database through the event monitoring mechanism; Determine the download progress of the target file according to the number of downloaded segments; and display the download progress in real time on the front-end interface; When the user clicks the Pause button, all ongoing shard requests are interrupted through AbortController, and the current state is saved to the IndexedDB data; when the user clicks Resume, the current state is reloaded and the download continues.

[0016] On the other hand, an embodiment of the present invention further provides a browser large file downloading device, the device comprising: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, so that the at least one processor can execute the browser large file downloading method.

[0017] Compared with the prior art, the browser large file downloading method and device provided by the embodiment of the present invention has the following beneficial effects: This invention innovatively proposes an efficient download solution for large files in a browser environment, which cleverly combines dynamic sharding strategy and parallel download control technology, significantly optimizing data transmission efficiency. By introducing IndexedDB database as a persistent storage medium, it not only realizes the reliable preservation of shard data and download status, but also perfectly supports the breakpoint resume function and strict verification of shard integrity. In addition, with the powerful capabilities of Service Worker, this method further realizes the intelligent scheduling of background silent download and offline task management.

[0018] In terms of technical innovation, this solution uses advanced streaming technology and a strategy of writing shards directly to disk. This revolutionary design greatly reduces the use of memory resources. At the same time, combined with a sophisticated priority scheduling algorithm, it effectively improves the efficiency of network bandwidth utilization. This series of optimization measures fundamentally solves the common problems of traditional single-threaded download mode, such as memory overflow risks, inability to resume after download interruption, and performance bottlenecks.

[0019] Therefore, the present invention is particularly suitable for large file transfer scenarios on the Web side. It not only realizes functions such as dynamic segmentation, intelligent scheduling, breakpoint resumption, memory optimization, and offline management, which can greatly improve the download speed, but also significantly enhances the stability and reliability of the download process, bringing users a smoother and more efficient download experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. In the drawings: Figure 1 A flow chart of a browser large file downloading method provided by an embodiment of the present invention; Figure 2 A schematic diagram of the structure of a browser large file downloading device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0021] In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0022] The embodiment of the present invention provides a browser large file download method, such as Figure 1 As shown, the browser large file download method specifically includes steps S101-S106: S101. Intercept the browser's file download request through the Service Worker script, and delegate the file download task to a background thread for execution.

[0023] Specifically, first, the front-end main thread registers the Service Worker script through the navigator.serviceWorker.register method and specifies its scope as the root path to ensure that all file download requests can be intercepted.

[0024] Furthermore, the browser's file download request is intercepted through the registered Service Worker script, and the intercepted file download task is delegated to the background thread for execution.

[0025] In one embodiment, the browser's download request is intercepted by a registered Service Worker script, and the task is delegated to a background thread for execution. For example, when a user clicks a download button, the main thread intercepts the task information (such as URL, shard configuration, etc.) and sends it to the background Service Worker thread, which independently manages the shard download, storage, and progress reporting.

[0026] As a feasible implementation method, Service Worker listens to the fetch event and intercepts all chunk download requests (such as requests with the URL path containing / chunk / ). After interception, it first searches for cached responses from Cache Storage. If the cache is hit and has not expired (such as the cache time is within 30 days), the cached data is directly returned; if it is not hit or has expired, a request is made to the network and the response is cached in Cache Storage.

[0027] S102: Segment the target file in the file download task according to a preset segmentation rule, and create a segment download task for each segment.

[0028] Specifically, the file size of the target file is obtained, and the currently set preset fragmentation rules are retrieved; wherein the preset fragmentation rules at least include: fragmentation according to a fixed fragmentation size, fragmentation according to a preset percentage of the target file size, and fragmentation according to a user-defined fragmentation size.

[0029] Furthermore, based on the preset sharding rule and the file size, the number of shards and the shard size of each shard data are calculated to shard the target file.

[0030] As a feasible implementation method, the file is divided into several fragments according to the fragment size, and different fragmentation strategies can be set: set a fixed fragment size, set a percentage size, or set by the user. For example, the file is divided according to a fixed ratio (such as 1%-5% as a fragment), or divided according to a fixed fragment size. For example, if the file size exceeds 1GB, the default fragment size is 10MB; if the file is less than 100MB, the fragment size is 1MB, balancing the number of fragments and download efficiency.

[0031] Furthermore, an identifier is created for each shard data, and a shard download task is created for each shard. At the same time, a target file metadata record table and a shard metadata record table are created in the IndexedDB database to store the metadata of the target file and the metadata of the shard data; wherein the metadata of the target file includes at least: the file size, file type, number of shards and hash value of each shard of the target file; the metadata of the shard data includes at least: the shard identifier, start byte, end byte, download status, hash value, number of retries and last update time of the shard data.

[0032] As a feasible implementation method, the front-end obtains the metadata of the target file from the server through HTTP requests, including the total file size (e.g. 2GB), the number of shards (pre-calculated or dynamically generated by the server), the unique hash value of each shard (e.g. SHA-256), the file type (e.g. video / mp4), etc. The server returns the metadata in JSON format, which is parsed by the front-end and stored in the browser memory or temporary cache. A unique identifier (e.g. fileId_index) is generated for each shard, and a metadata record table is created in IndexedDB to record the shard index, download status (not started / downloading / completed / failed), hash value, and number of retries (initialized to 0).

[0033] S103: Create a parallel task pool, and dynamically allocate shard download tasks through the parallel task pool.

[0034] Specifically, the concurrency limit of the current browser is obtained, and a parallel task pool is created; the number of parallel threads in the parallel task pool is the same as the concurrency limit.

[0035] Furthermore, the parallel task pool is cyclically filled through the task queue mechanism, and the unexecuted tasks are stored in the waiting queue to dynamically allocate the fragment download tasks to ensure the maximum bandwidth utilization.

[0036] As a feasible implementation method, the front-end main thread uses the task queue mechanism to control the number of parallel downloads to 6 based on the concurrent request limit of the browser (such as a maximum of 6 concurrent requests per domain name in the http1.x protocol). For example, if the parallelism is set to 6, a maximum of 6 shards will be downloaded at the same time, and unexecuted tasks will enter the task queue and be triggered in sequence.

[0037] Even if the user closes the browser or switches tabs, ServiceWorker can continue downloading tasks in the background after the user agrees to authorize the "background sync" permission. For example, the Background Sync API can automatically wake up the Service Worker when the network is available to complete the download of the remaining segments. Set a timeout threshold for each segment download task. If it is not completed before the timeout, the request is automatically terminated and the segment is marked as "pending retry"; when the number of retries reaches the upper limit, the error callback is triggered and the user is prompted.

[0038] S104. After each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; based on the shard integrity check result, the current shard is re-downloaded.

[0039] Specifically, after each shard download task is completed, the downloaded binary shard data is stored in the IndexedDB database and associated with the corresponding shard metadata record table in the IndexedDB database.

[0040] Furthermore, the hash value of the downloaded shard data is calculated and compared with the hash value of the shard recorded in the target file metadata record table. If the comparison is consistent, the download status in the shard metadata record table is updated to completed. If the comparison is inconsistent, the automatic retry logic is triggered to re-download the shard data; the automatic retry is triggered up to 3 times, and the retry count field of the shard in the IndexedDB database is updated before each retry. After the number of retries is exceeded, the download status of the shard data is marked as "failed", and the user is prompted to manually intervene through the user interface.

[0041] If the download is successful, the binary data of each shard (ArrayBuffer format) is stored in the "shard data table" of IndexedDB, with the primary key being the shard's unique identifier (such as fileId_index). When writing, use IndexedDB transactions to ensure atomicity and avoid inconsistent states caused by partial data writing.

[0042] As a feasible implementation method, each shard is downloaded through an HTTP Range request, and the byte range is specified in the request header (such as bytes=0-10485759 for the first 10MB shard). After the download is complete, the front end uses the browser's built-in crypto.subtle.digest API to calculate the SHA-256 hash value of the shard data and compares it with the hash value stored in the IndexedDB database; if they are consistent, the shard is marked as "completed"; if they are inconsistent, the automatic retry logic is triggered. If the shard download fails (such as network interruption or hash verification failure), the system automatically retries up to 3 times; before each retry, the "Retry Count" field of the shard in IndexedDB is updated. After the number of retries is exceeded, the shard is marked as "failed" and the user is prompted to intervene manually through the user interface.

[0043] Furthermore, an interruption detection is performed during the segment downloading process to determine the interruption cause; wherein the interruption cause includes network interruption and other causes.

[0044] When the interruption is caused by a network interruption, the unfinished shard request information is stored in the offline task table of the IndexedDB database; the shard request information includes at least the shard URL, shard index, and request time. When the network is detected to be restored, the offline task resume is automatically triggered by listening to the sync event, and the unfinished shard download task is read from the offline task table, re-added to the task queue, and executed first.

[0045] When the terminal reason is other reasons, the downloaded shard list is read from the IndexedDB database to determine the breakpoint; the unfinished shard download tasks after the breakpoint are re-added to the task queue to perform breakpoint download recovery.

[0046] As a feasible implementation method, when the network is interrupted, Service Worker stores the unfinished shard request information (including shard URL, shard index, and request time) in the "offline task table" of IndexedDB to ensure data persistence. When the browser detects that the network connection is restored, Service Worker automatically triggers the resumption of offline tasks by listening to the sync event (the event label is retry-offline-tasks); the system will read the unfinished shard tasks from IndexedDB, re-add them to the download queue, and execute them first. If it is interrupted for other reasons, the download is initiated again, and the list of downloaded shards is read directly from IndexedDB, and only the unfinished shards are requested; for example, if the total file size is 1GB and 600MB has been downloaded, only the shards corresponding to the remaining 400MB need to be requested, skipping the stored data.

[0047] Furthermore, during the download process, the present invention adopts streaming writing to disk storage: during the download process of sharded data, the data stream of the current sharded data is written to the persistent disk space of the browser in real time through the Streams API, and at the same time, the data stream is read in real time in the persistent disk space through the parallel threads in the memory for downloading, and the downloaded data stream is directly written to the disk file.

[0048] As a feasible implementation method, the sharded data stream is written to the persistent disk space allocated by the browser (such as Chrome's File System Access API) in real time through the Streams API to avoid loading the complete sharded data into the memory. For example, when downloading shards, the data stream is read block by block through response.body.getReader() and written directly to the disk file, and only the data block being processed by the current thread is retained in the memory.

[0049] S105. After all the shard download tasks are completed, all shard data are read in the IndexedDB database in shard order and spliced ​​into a complete file.

[0050] Specifically, after each shard is processed, memory resources are released immediately, and residual data is forcibly cleaned up through the WeakMap garbage collection mechanism to prevent memory leaks.

[0051] Furthermore, for repeated download requests for the same target file, it is determined whether the target file has changed. If not, the shard data stored in the IndexedDB database is directly read; if changed, the shard data of the unchanged part in the IndexedDB database is read, and only the shard data of the changed part is re-downloaded to reduce redundant traffic consumption.

[0052] Furthermore, the present invention also monitors the download progress: the number of downloaded segments is obtained from the metadata download status change event of the IndexedDB database through an event monitoring mechanism. According to the number of downloaded segments, the download progress of the target file is determined; the download progress is displayed in real time in the front-end interface. When the user clicks the pause button, all ongoing segment requests are interrupted through AbortController, and the current state is saved to the IndexedDB data; when the user clicks resume, the current state is reloaded and the download continues.

[0053] Furthermore, after all download tasks are completed, all downloaded shard data are read from IndexedDB in shard order (starting byte ascending order). Then the shard data is spliced ​​into a complete file through the BlobAPI to generate a Blob object of the final file. The showSaveFilePicker method of the File System Access API is called to write the Blob to the user-specified path (such as the download directory) to complete the download.

[0054] S106: After writing the complete file to the path specified by the user, the corresponding shard data and its metadata are deleted in the IndexedDB database to release storage space.

[0055] Specifically, after the file is downloaded successfully, the corresponding shard metadata and binary data in IndexedDB are deleted to release storage space.

[0056] For the shard data that has not been downloaded, after the system starts, register a scheduled task to be executed daily (through setInterval) to check the "creation time" field of all files in IndexedDB. If the file has not been downloaded for more than 7 days, or has been completed but not cleaned up for more than 3 days, all its shard data and metadata will be automatically deleted to free up storage space.

[0057] In addition, the embodiment of the present invention also provides a browser large file download device, such as Figure 2 As shown, the equipment specifically includes: at least one processor; and a memory in communication with the at least one processor; wherein, The memory stores instructions executable by at least one processor to enable the at least one processor to perform: Intercept the browser's file download request through the Service Worker script and delegate the file download task to the background thread for execution; Segment the target file in the file download task according to a preset segmentation rule, and create a segment download task for each segment; Creating a parallel task pool, and dynamically allocating the segment download tasks through the parallel task pool; After each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; According to the fragment integrity check result, re-download the current fragment; After all the shard download tasks are completed, all the shard data are read in the IndexedDB database in shard order and spliced ​​into a complete file; After the complete file is written to the user-specified path, the corresponding shard data and its metadata are deleted in the IndexedDB database to release storage space.

[0058] Each embodiment of the present invention is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0059] The above describes specific embodiments of the present invention. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0060] The above description is only an embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiments of the present invention should be included in the protection scope of the present invention.

Claims

1. A browser large file download method, characterized in that: The method comprises: Intercept the browser's file download request through the Service Worker script and delegate the file download task to the background thread for execution; Segment the target file in the file download task according to a preset segmentation rule, and create a segment download task for each segment; Creating a parallel task pool, and dynamically allocating the segment download tasks through the parallel task pool; After each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; According to the fragment integrity check result, the current fragment is re-downloaded; After all the shard download tasks are completed, all the shard data are read in the IndexedDB database in shard order and spliced ​​into a complete file; After the complete file is written to the user-specified path, the corresponding shard data and its metadata are deleted in the IndexedDB database to release storage space.

2. A browser large file downloading method according to claim 1, characterized in that: The target file in the file download task is segmented according to a preset segmentation rule, and a segment download task is created for each segment, specifically including: Obtain the file size of the target file, and retrieve the currently set preset sharding rules; wherein the preset sharding rules at least include: sharding according to a fixed sharding size, sharding according to a preset percentage of the target file size, and sharding according to a user-defined sharding size; Based on the preset sharding rule and the file size, the number of shards and the shard size of each shard data are calculated to shard the target file; Create an identifier for each shard data and create a shard download task for each shard; At the same time, a target file metadata record table and a shard metadata record table are created in the IndexedDB database to store the metadata of the target file and the metadata of the shard data; wherein the metadata of the target file includes at least: the file size, file type, number of shards and hash value of each shard of the target file; the metadata of the shard data includes at least: the shard identifier, start byte, end byte, download status, hash value, number of retries and last update time of the shard data.

3. A browser large file downloading method according to claim 1, characterized in that: Creating a parallel task pool and dynamically allocating the shard download tasks through the parallel task pool specifically includes: Obtain the concurrent limit number of the current browser and create a parallel task pool; the number of parallel threads in the parallel task pool is the same as the concurrent limit number; The parallel task pool is cyclically filled through a task queue mechanism, and unexecuted tasks are stored in a waiting queue to dynamically allocate the segment download tasks.

4. A browser large file downloading method according to claim 1, characterized in that: After each shard download task is completed, the downloaded shard data and its metadata are stored in the browser's IndexedDB database, and the integrity of the shard data is checked; According to the fragment integrity check result, the current fragment is re-downloaded, including: After each shard download task is completed, the downloaded binary shard data is stored in the IndexedDB database and associated with the corresponding shard metadata record table in the IndexedDB database; Calculate the hash value of the downloaded shard data and compare it with the hash value of the shard recorded in the target file metadata record table. If the comparison is consistent, update the download status in the shard metadata record table to completed. If the comparison is inconsistent, trigger the automatic retry logic to re-download the shard data; trigger automatic retry up to 3 times, and update the retry count field of the shard in the IndexedDB database before each retry; After the number of retries is exceeded, the download status of the shard data is marked as "failed" and the user is prompted to intervene manually through the user interface.

5. A browser large file downloading method according to claim 1, characterized in that: Before re-downloading the current segment according to the segment integrity check result, the method further includes: Performing interruption detection during the segment download process to determine the interruption cause; wherein the interruption cause includes network interruption and other causes; When the interruption reason is a network interruption, the unfinished shard request information is stored in the offline task table of the IndexedDB database; wherein the shard request information includes at least the shard URL, shard index and request time; When the network is detected to be restored, the offline task resuming is automatically triggered by listening to the sync event, and the unfinished segment download tasks are read from the offline task table, re-added to the task queue, and executed first; When the terminal reason is other reasons, the downloaded shard list is read from the IndexedDB database to determine the breakpoint; the unfinished shard download tasks after the breakpoint are re-added to the task queue to perform breakpoint download recovery.

6. A browser large file downloading method according to claim 1, characterized in that: The ServiceWorker script intercepts the browser's file download request and delegates the file download task to the Service Worker thread for execution, including: Register the Service Worker script through the navigator.serviceWorker.register method and specify its scope as the root path to ensure that all file download requests can be intercepted; The browser's file download request is intercepted through the registered Service Worker script, and the intercepted file download task is delegated to the background thread for execution.

7. A browser large file downloading method according to claim 1, characterized in that: The method further comprises: During the shard data download process, the data stream of the current shard data is written to the browser's persistent disk space in real time through the Streams API. At the same time, the data stream is read in real time from the persistent disk space through the parallel thread in the memory for downloading, and the downloaded data stream is directly written to the disk file.

8. A browser large file downloading method according to claim 1, characterized in that: The method further comprises: After each shard is processed, memory resources are released immediately, and residual data is forcibly cleaned up through the WeakMap garbage collection mechanism to prevent memory leaks; For repeated download requests for the same target file, determine whether the target file has changed; If there is no change, directly read the shard data stored in the IndexedDB database; If a change occurs, the shard data of the unchanged part in the IndexedDB database is read, and only the shard data of the changed part is downloaded again to reduce redundant traffic consumption.

9. A browser large file downloading method according to claim 1, characterized in that: Specifically include: The number of shards that have been downloaded is obtained from the metadata download status change event of the IndexedDB database through the event monitoring mechanism; Determine the download progress of the target file according to the number of downloaded segments; and display the download progress in real time on the front-end interface; When the user clicks the Pause button, all ongoing shard requests are interrupted through AbortController, and the current state is saved to the IndexedDB data; when the user clicks Resume, the current state is reloaded and the download continues.

10. A browser large file downloading device, characterized in that: The device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, so that the at least one processor can execute the browser large file downloading method according to any one of claims 1-9.

Images