A method for supporting online quick preview of files of multiple devices

Abstract

The application discloses a kind of file online quick preview method of supporting multiple devices, belong to data processing technical field.The method includes: target file stream is obtained by protocol adaptive routing technology and type is identified by server;Through buffer judgment and dynamic conversion module, various office documents are uniformly converted into PDF format;Server returns the PDF file metadata containing piece support information;Client initiates dynamic piece data request to specified page based on PDF cross-reference table;Render by responsive layout in combination with device type;And subsequent piece data is preloaded when user browses.The application is combined by unified conversion, piece loading and device adaptive rendering technical means, effectively solve the technical problems that existing online preview system is poor in cross-device compatibility, and large file is slowly loaded, realize the quick, smooth preview of multiple format files on different terminals.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a method for online rapid preview of files that supports multiple devices. Background Technology

[0002] With the rapid development of mobile internet and cloud computing technologies, enterprises have an increasing demand for online document preview. Users expect to directly view various types of files, such as documents, drawings, audio, and video, through browsers or mobile devices to improve collaboration efficiency and data security. However, existing online preview systems have significant shortcomings in cross-device compatibility, format support, loading speed, and security, making it difficult to meet the needs of complex enterprise-level scenarios. Existing online preview systems have significant weaknesses in cross-device compatibility. Differences in browser environments between different operating systems (such as Windows, macOS, and Linux) and mobile devices (phones and tablets) lead to inconsistent preview results. For example, font and layout issues: differences in font libraries between Windows and macOS systems can easily cause layout errors, and abnormal display of special characters occurs frequently. At the same time, existing technologies have significant defects when handling large files: large files load slowly, and in synchronous preview mode, response time is positively correlated with file size. For example, the method for online previewing non-Office documents only addresses online previewing of non-Office documents, supporting a limited number of document formats. The article "A Method for Fast Segmented Loading and Display of OFD Layout Files in Online Browsing" provides a method for segmented loading and displaying of OFD layout files, but does not provide a method for segmented loading and displaying of Office-related files. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to overcome the shortcomings of the prior art and provide a method for fast online preview of files that supports multiple devices. It aims to solve the problem of inconsistent cross-device rendering caused by the variety of formats in the existing solutions, as well as the problem of slow loading and lag caused by the large file size.

[0004] To achieve the above objectives, the core of the technical solution adopted by this invention lies in solving the rendering consistency problem by uniformly converting to PDF format, and using this as the foundation, constructing a collaborative architecture of "conversion-caching-sharding" chain optimization and "server-side computing-client-side rendering" dynamic and static separation, so as to achieve fast on-demand loading of large files.

[0005] Specifically, the present invention provides a method for fast online file preview supporting multiple devices, comprising the following steps:

[0006] A method for fast online file preview supporting multiple devices, characterized by the following steps:

[0007] S1: The server obtains the file stream of the target file through the online preview request link; it comprehensively identifies the file type information by analyzing the binary signature in the file stream header and / or the file extension in the request URL.

[0008] S2: The server determines whether the file has been converted based on the cache. If not, it converts the file to a PDF file according to the file type and adds it to the cache.

[0009] S3: The server pre-parses the PDF file and generates fragmented metadata based on the PDF cross-reference table; it then returns a response containing the fragmented metadata and information supporting fragmented loading to the client.

[0010] S4: The client parses the fragment metadata, queries the fragment metadata according to the required page to obtain the corresponding byte range, and sends a resource request to the server carrying the byte range information.

[0011] S5: The client uses an adaptive layout to render the fragmented data obtained from the server based on the device type;

[0012] S6: When a user browses, the client preloads the fragmented data of subsequent pages based on the fragmented metadata.

[0013] Furthermore, step s1 includes: the server obtaining the file stream via HTTP or FTP protocol, and obtaining the corresponding file type information according to the interface parameters.

[0014] Step s1 employs protocol-adaptive routing technology. The server dynamically selects the transmission strategy by parsing the protocol prefix (http: / / / https: / / / ftp: / / ) in the request URL. HTTP / HTTPS streaming uses Apache HttpClient 5 to implement chunked transmission with a Range header, supporting breakpoint resumption and efficient memory processing. HTTP Range requests conform to RFC 7233. FTP streaming uses the Apache Commons Net library to implement passive mode (PASV) data transmission, resolving firewall blocking issues. Passive mode (PASV) conforms to RFC 959; the client initiates the data connection instead of the server, avoiding the potential firewall blocking issues of active mode (PORT).

[0015] Furthermore, step s2 includes: the cache information includes the file's unique identifier and the address of the converted PDF file.

[0016] Step s2 employs a dynamic data conversion module that triggers the corresponding Apache ecosystem library for PDF conversion based on the file extension type. Modular format conversion (using dynamic conversion modules based on the Apache ecosystem (POI, iText, FOP), called on demand) and a caching mechanism (associating the conversion result (PDF file path) with a unique file identifier and persistently caching it) achieve broad file format support and efficient resource utilization. New formats only require adding a conversion module, resulting in strong system scalability. The same file only needs to be converted once; subsequent requests directly access the cache, significantly reducing server computational load and improving overall response speed.

[0017] The unified conversion in step s2 not only normalizes multiple formats to a single standard format, eliminating cross-device rendering differences at the source, but also generates a PDF file with a linear structure and cross-reference tables. This provides an essential structured foundation for the subsequent precise fragmented metadata parsing in step s3 and the on-demand / preloading in steps s4 / s6. The caching mechanism directly caches the converted PDF file and its fragmented metadata. For any subsequent preview request of the same file, the conversion and parsing steps can be skipped, directly supporting millisecond-level fragmented data response, resulting in an order-of-magnitude performance improvement in repeated access scenarios. Through the aforementioned collaborative technology chain of "unified conversion as the foundation, server-side pre-parsing navigation, client-side on-demand loading, and caching for end-to-end acceleration," this invention organically integrates format compatibility, rendering consistency, and loading performance, forming a complete and efficient technical solution.

[0018] Furthermore, in step s3, the server-side pre-parsing proactively parses the PDF cross-reference table before returning file information, generating lightweight fragmented metadata. This achieves "static-dynamic separation," placing complex structural calculations on the server side, allowing the client (steps s4 / s6) to initiate precise byte-range requests without parsing the complete PDF, greatly reducing client complexity and improving response speed.

[0019] Furthermore, step s4 includes: loading the required file bytes for the current page and the pages before and after the current page, based on the total number of bytes in the PDF file and the current page number.

[0020] The theoretical basis for the segmented rendering of the PDF file in step S4 is that the PDF file adopts a linear storage structure, and the position of each page of data in the file can be quickly located through a cross-reference table.

[0021] Furthermore, step s5 includes: rendering the page using responsive design to adaptively adjust the page layout according to the device's screen size; rendering the PDF file using pdf.js, which is entirely built using JavaScript (specifically ECMAScript 5 standard), HTML5, and CSS3, requiring no browser plugins.

[0022] Step s5's page employs responsive layout and dynamic adaptation technology, based on CSS3 media queries (@media rules) and JavaScript dynamic calculations, adjusting page element sizes, font sizes, and interactive control positions according to the device. Responsive design ensures content displays fully on different screens and avoids horizontal scrolling through fluid layouts (percentage widths) and flexible images (max-width: 100%).

[0023] Furthermore, step s6 includes loading the fragmented data of the subsequent page while the user flips through the page (fragmented data is a technique for splitting a large dataset into multiple smaller, independent segments (called "fragments").

[0024] This invention also discloses an online fast file preview system supporting multiple devices. This system performs the above-described method and is characterized by comprising:

[0025] The file acquisition module is used to execute step S1; the caching and conversion module is used to execute step S2; the information return module is used to execute step S3; the fragmentation request module is used to execute step S4; the device rendering module is used to execute step S5; and the preloading module is used to execute step S6.

[0026] The present invention also discloses a non-volatile storage medium, characterized in that the non-volatile storage medium includes a stored program, wherein the program, when running, controls the device where the non-volatile storage medium is located to execute the above-described method.

[0027] The present invention also discloses a terminal device, characterized in that the terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to execute the method described above.

[0028] Beneficial effects

[0029] (1) It fundamentally ensures consistent preview effects across devices and has excellent compatibility. By uniformly converting various office documents (such as .docx, .xlsx, .pptx) into the standard PDF format, it eliminates font and layout differences caused by different operating systems, browsers, and native rendering libraries. Combined with front-end responsive layout technology (based on CSS3 media queries and JavaScript dynamic adaptation), it ensures that users get a precise and complete preview effect on any terminal device of any size, without the need to install any plugins.

[0030] (2) Through innovative chain optimization and static / dynamic separation architecture, the system achieves instant opening and seamless browsing of large files, resulting in significant performance improvements. The core innovation of this invention lies in constructing a highly collaborative "conversion-caching-sharding" chain optimization process and adopting a static / dynamic separation architecture of "centralized computing on the server side / lightweight rendering on the client side": The synergistic effect brought by chain coupling: unified conversion to PDF not only solves the format problem, but the structural characteristics of its product directly support accurate sharding; the server-side cache directly stores the conversion and parsing results, so that the response speed of shard loading does not depend on the original file size, but only on the amount of page data currently requested. These three links are interconnected, systematically integrating format processing, performance optimization and user experience improvement; The efficiency advantage of the static / dynamic separation architecture: the server undertakes the computationally intensive PDF structure parsing work and generates "shard metadata" which is sent to the client. The client only needs to initiate a simple HTTP range request based on this "map" to achieve accurate on-demand loading and intelligent preloading. This design decouples the loading time of large files from the total file size, achieving a millisecond-level rendering effect that "only displays the current page, regardless of file size," resulting in a smooth user experience.

[0031] (3) The system is highly scalable, resource-efficient, and adaptable to complex enterprise environments. Modular expansion: Based on the Apache ecosystem (POI, iText, FOP), the dynamic conversion module design supports flexible addition of processing capabilities for new file formats; Resource efficiency: The same file only needs to be converted and parsed once, and the result is persistently cached, which greatly reduces the server's repetitive computing load; Protocol adaptation: By parsing the URL prefix, the source file is obtained by adaptively selecting HTTP / HTTPS or FTP protocol, and standard modes (such as FTP PASV) are used to avoid network restrictions, which enhances the applicability and robustness of the solution in various internal and external storage environments of enterprises. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0033] The following detailed description of the implementation method of the present invention is in conjunction with the accompanying drawings. The description only covers some embodiments and not all embodiments. For clarity, representations and descriptions unrelated to the present invention have been omitted from the drawings and description.

[0034] To provide a clearer understanding of the technical features, objectives, and beneficial effects of this invention, the following detailed description of the technical solution is provided. Obviously, the described embodiments are only a portion of the embodiments of this invention, not all of them, and should not be construed as limiting the scope of implementation of this invention. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the protection scope of this invention.

[0035] like Figure 1 As shown, this invention achieves fast previewing of large files across devices through a process of "protocol adaptive acquisition → cache judgment → format conversion → fragment return → device adaptation → preloading". Specifically, the server dynamically acquires the file stream according to the request protocol (S1), determines whether it has been converted through caching (S2), and if not, converts it to PDF and caches it (S2). The client requests fragmented data as needed based on the returned PDF information (S3) (S4), and performs responsive rendering based on the device type (S5). During user browsing, the system dynamically preloads subsequent fragments (S6) to achieve a smooth page-turning experience.

[0036] This embodiment provides a method for fast online file preview that supports multiple devices, including the following steps:

[0037] s1: The server obtains the file stream of the target file through the online preview request link; by analyzing the binary signature (magic number) in the file stream header and / or the file extension in the request URL, it comprehensively identifies the file type information.

[0038] Section s1.1 defines an HTTP interface for GET requests on the server side, which receives requests containing a URL link for downloading the target file. File type information can be provided by the client in the request parameters for reference, but the server will primarily actively identify the file stream in the manner described in section s1.3.

[0039] Step 1.2 determines whether to use the HTTP or FTP protocol for downloading based on the URL address format. This step employs protocol-adaptive routing technology (dynamically selecting the corresponding streaming client by parsing the request URL prefix (http / https / ftp) and using standard protocols (such as FTP PASV mode) to avoid network interception), enhancing the robustness and flexibility of file source acquisition. The system can seamlessly interface with files from web servers or FTP servers, adapting to complex enterprise IT environments and improving the practicality and deployment scope of the solution.

[0040] The specific implementation of protocol adaptive retrieval is as follows: The server parses the protocol prefix of the request URL. If the prefix is ​​http: / / or https: / / , an HttpClient object is instantiated, a connection pool and timeout parameters are configured, and an HttpGet request is used with the Range header set to achieve streaming chunked download. If the prefix is ​​ftp: / / , an FTPClient object is instantiated, set to passive mode (PASV), and after connecting to the FTP server, the file input stream is obtained through the retrieveFileStream method. A retry mechanism is implemented for network errors (e.g., a maximum of 3 retries). The obtained file stream is temporarily stored in the server's memory or a temporary file.

[0041] s1.3 generates a unique ID for the downloaded file, for example, using the Snowflake Algorithm to generate the ID.

[0042] The Snowflake algorithm is an open-source distributed ID generation algorithm used to generate globally unique and ordered 64-bit long integer IDs in a distributed system.

[0043] s2: Use the cache to determine if the file has been previewed. If not, use the corresponding data conversion module to convert it into a PDF file based on the file type, and add the converted PDF file information to the cache.

[0044] s2.1 Implement caching functionality based on Redis, key-value pairs<k,v> k is the file snowflake ID, and v is the path to the converted PDF file;

[0045] The dynamic data conversion module in step S2.2 follows these rules: for .docx and .doc format files, the Apache POI and iText libraries are used for conversion; for .xlsx, .xls, .pptx, and .ppt format files, the Apache POI and FOP libraries are used for conversion. This modular format conversion (using dynamic conversion modules based on the Apache ecosystem (POI, iText, FOP), called on demand) achieves broad file format support and efficient resource utilization. New formats only require adding a conversion module, resulting in strong system scalability. In step S2.2, the converted PDF file's byte count is obtained and added to the ContentLength of the response body for subsequent parsing.

[0046] s3: The server pre-parses the PDF file and generates fragmented metadata based on the PDF cross-reference table; it then returns a response containing the fragmented metadata and supporting fragmented loading to the client.

[0047] s3.1 Server-side pre-parsing and generation of fragmented metadata: After the file is converted to PDF (or after reading the PDF from the cache), the server uses a lightweight PDF parsing library (such as Apache PDFBox) to parse the cross-reference table (xref) of the PDF file, calculates the starting byte offset and length PageSize(i) of each page, and forms a page number-byte range lookup table. This table, together with the total number of bytes in the file (totalByte), constitutes the fragmented metadata referred to in this invention.

[0048] The fragment metadata includes at least: totalBytes (total bytes of the file); page index array pageIndex, where each element contains startByte (starting byte offset) and length (length of the page data); and optionally pageDimensions (page size information) for client-side pre-calculation of layout.

[0049] s3.2 Constructing and Returning File Metadata Response: The server returns the aforementioned fragmented metadata (in JSON format in the response body) to the client. Simultaneously, it sets key fields in the HTTP header of this response to indicate that the server supports fragmented loading and specifies the response body format, for example:

[0050] Accept-Ranges: bytes indicates that the server supports fragmented loading.

[0051] Content-Type: application / json: Specifies that the response body contains metadata in JSON format.

[0052] Access-Control-Expose-Headers: Accept-Ranges (optional): Ensures that the browser can read the Accept-Ranges header in cross-domain scenarios.

[0053] Content-Length: [Length of the fragment metadata JSON string]: Indicates the size of the metadata returned this time.

[0054] s4: The client parses the fragment metadata, queries the fragment metadata according to the required page to obtain the corresponding byte range, and sends a resource request carrying the byte range information to the server.

[0055] s4.1: After receiving the response from S3, the client parses it to obtain the fragment metadata (JSON format). When it needs to render the nth page, the client directly queries the page number-byte range lookup table in the fragment metadata to obtain the precise byte range of that page. Subsequently, the client constructs a GET request, setting `Range: bytes=StartByte(n)-EndByte(n)` in the request header, and sends a request to the server for dynamically segmented data within that byte range. Specifically, it constructs a GET HTTP request, with the `Range` parameter in the request body's header. For example, `Range:[0,1024]` indicates that the requested data segment range is 0-1024 bytes. The response body returns the specific data bytes requested, defining the returned data as `data`.

[0056] The obtained chunked data is injected into the PDF.js parser (for example, by calling the stream.enqueueChunk(data) method). When the chunked data covers the current viewport, PDF.js will automatically trigger page rendering.

[0057] The specific method for injecting and rendering s4.2 fragmented data is as follows:

[0058] Frontend configuration: By configuring the PDF.js rendering library and setting `disableAutoFetch: true` to disable its mechanism of automatically fetching complete files, and using the `range` parameter of `PDFJS.getDocument()` or a custom `RangeTransport`, on-demand loading of chunked data can be achieved. To ensure that PDF.js processes the incoming data chunks in a streaming manner, streaming loading must be enabled (in PDF.js, `disableStream: false` is usually enabled by default, so no additional setting or explicit setting to `false` is required). The obtained chunked data `data` is injected into the PDF.js parser using methods such as `stream.enqueueChunk(data)`.

[0059] s4.3: After receiving a byte range request (Range: bytes=StartByte-EndByte) from the client, the server reads the corresponding byte segment from the cached or stored PDF file and returns it to the client. In the HTTP header of this "fragmented data" response, the server sets:

[0060] Content-Range: bytes StartByte-EndByte / totalByte: Indicates the range of data returned this time;

[0061] Content-Length: (EndByte - StartByte + 1): Indicates the length of the data returned this time;

[0062] Content-Type: application / octet-stream: indicates that this is a binary byte stream.

[0063] s5: The client uses an adaptive layout to render the fragmented data obtained from the server based on the device type.

[0064] The S5.1 client obtains the height of the current device's browser viewport (such as window.document.documentElement.clientHeight) via JavaScript, and dynamically calculates and sets the rendering scaling ratio that is most suitable for the current screen based on this height and the original size of the PDF page.

[0065] This step utilizes responsive client-side rendering (using pure CSS3 media queries and JavaScript dynamic layout technology) to achieve absolute consistency in the preview effect and broad device compatibility. Regardless of the operating system or screen size, you can obtain an accurate and complete preview without installing any browser plugins.

[0066] s6: When a user browses, the client preloads the fragmented data of subsequent pages based on the fragmented metadata.

[0067] S6.1 Dynamic Fragment Calculation: Based on the page number n requested by the user, calculate the start byte StartByte(n) and end byte EndByte(n) of the page:

[0068] Start byte: StartByte; End byte: EndByte; n is the page number of the current request; i represents the page number preceding the current page. The system calculates the start and end bytes for each page's data size. Steps S4-S5 are repeated based on the start and end bytes of the user's current page, achieving millisecond-level pagination rendering and a seamless page-turning experience. Users experience no waiting time; the loading time for large files is no longer directly related to the total file size, but only to the amount of data on the currently viewed page, greatly improving the user experience.

[0069] Dynamic sharding computation is a technique that dynamically divides a task into multiple subtasks based on real-time parameters (such as data range and total number of shards) during task execution. It optimizes resource utilization and task execution efficiency by dynamically adjusting the sharding logic, making it particularly suitable for scenarios such as big data processing and distributed computing.

[0070] When a user initiates a preview request, the system's collaborative workflow is as follows:

[0071] Server-side pipeline (S1-S3): The protocol adaptively acquires the file stream (S1), avoids redundant work through caching, and performs a unified PDF conversion (S2). A key step is that immediately after conversion, server-side pre-parsing (S3.2) extracts the PDF's cross-reference table and generates a page number-byte range lookup table. This table, along with the overall file information, is returned, completing the preprocessing from "multi-format raw files" to "navigable, fragmented PDF data."

[0072] Client pipeline (S4-S6): After obtaining the shard metadata, the client can view it as if it were a local disk. Figure 1 Similarly, based on the user's current browsing position (page number n), the system accurately calculates the required data byte range (S4.1, S6.1) and initiates a miniature range request. The acquired data fragments are streamed into PDF.js for rendering (S4.2). Simultaneously, based on user behavior predictions, the system pre-requests data from adjacent pages (S6) to achieve seamless browsing.

[0073] Caching acceleration is implemented throughout: all the server-side preprocessing results mentioned above (PDF files, fragmented metadata) are cached. Any subsequent request for the same file will directly hit the cache, instantly completing S3 and all subsequent steps, achieving near-instantaneous preview opening.

[0074] The ingenuity of this invention lies not in the simple application of a single technology, but in the organic integration and synergistic optimization of multiple technologies to form a complete, efficient, and user-friendly solution. Specifically, this is reflected in the choice of PDF as the unified intermediate preview format. This choice cleverly leverages the wide support for the PDF format, its fixed layout, its linear file structure, and its built-in cross-reference table (a core component of the PDF file structure, used to record the physical location (offset) of all indirect objects (such as fonts, images, and page descriptions) within the file. Through the mapping relationship of "object number + offset," it enables PDF readers to load specific objects on demand, rather than parsing the entire file), providing a crucial technical foundation for subsequent accurate and efficient segmented loading. This is not obvious, as the conventional approach might be to directly render the original format or convert it to an image.

[0075] The system architecture features a collaborative "conversion-caching-sharding" chain optimization, tightly coupling format conversion, result caching, and sharding transmission. Conversion serves caching and sharding, caching accelerates sharding response, and sharding depends on the structural characteristics of the converted PDF. This architecture design generates a synergistic effect of "1+1+1>3," systematically solving the chain reaction of problems from complex formats and large files to slow user experience. The system also employs a "server-side sharding calculation + client-side on-demand rendering" separation of static and dynamic operations: the server handles complex file conversion, cache management, and sharding range calculation; the client (browser) handles lightweight sharding requests, data assembly, and device-adaptive rendering. This division of responsibilities fully leverages the strengths of each component, enabling the system to possess both powerful processing capabilities and excellent front-end responsiveness.

[0076] This invention ultimately achieves the core objective of significantly improving preview speed and cross-platform consistency without sacrificing preview quality. This enables it to effectively meet the online preview needs of massive amounts of multi-format, large-volume files in enterprise applications, giving it high practical value and market competitiveness in fields such as remote work, online education, and digital archives.

[0077] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. A method for supporting online quick preview of files of a plurality of devices, characterized by, Includes the following steps: S1: The server obtains the file stream of the target file through the online preview request link; it comprehensively identifies the file type information by analyzing the binary signature in the file stream header and / or the file extension in the request URL. S2: The server determines whether the file has been converted based on the cache. If not, it converts the file to a PDF file according to the file type and adds it to the cache. S3: The server pre-parses the PDF file and generates fragmented metadata based on the PDF cross-reference table; it then returns a response containing the fragmented metadata and information supporting fragmented loading to the client. S4: The client parses the fragment metadata, queries the fragment metadata according to the required page to obtain the corresponding byte range, and sends a resource request to the server carrying the byte range information. S5: The client uses an adaptive layout to render the fragmented data obtained from the server based on the device type; S6: When a user browses, the client preloads the fragmented data of subsequent pages based on the fragmented metadata.

2. The method of claim 1, wherein, S1 includes: dynamically selecting HTTP / HTTPS or FTP protocol to obtain the file stream in a streaming manner by parsing the protocol prefix in the request URL.

3. The method of claim 1, wherein, The cache in S2 uses a key-value pair structure, where the key is a unique file identifier and the value is the storage path of the converted PDF file.

4. The method of claim 1, wherein, The response information returned in S3 that supports fragmented loading includes: a response header indicating that the server supports fragmented loading; the response header indicating that the server supports fragmented loading is the HTTP response header Accept-Ranges.

5. The method of claim 1, wherein, Specifically, S4 involves the client setting a `Range` field in the HTTP request header of the second request, with a value representing a byte range determined based on the fragment metadata.

6. The method of claim 1, wherein, The adaptive layout in S5 is achieved through front-end stylesheet media queries and dynamic calculations by client-side scripts; the front-end stylesheet media queries are CSS3 media queries; and the client-side scripts are JavaScript.

7. The method of claim 1, wherein, The range of pages preloaded in S6 is dynamically determined based on the user's current browsing page and the preset buffer size, and the requested byte range is calculated based on the fragment metadata.

8. A system for supporting online quick preview of files for multiple devices, the system performing the method of claim 1, wherein, include: The file acquisition module is used to execute the steps in S1; The caching and transformation module is used to execute the steps of S2; The information return module is used to execute the steps in S3; The sharding request module is used to execute the steps in S4. The device rendering module is used to execute the steps of S5; A preloaded module is used to execute the steps of S6.

9. A non-volatile storage medium, characterized by, The non-volatile storage medium includes a stored program, wherein the program, when executed, controls the device where the non-volatile storage medium is located to perform the method described in any one of claims 1 to 7.

10. A terminal device, comprising: The terminal device includes: a processor, a memory, a communication interface, and a bus; the processor, the memory, and the communication interface are connected through the bus and communicate with each other; the memory stores executable program code; the processor reads the executable program code stored in the memory to run a program corresponding to the executable program code, so as to perform the method as described in any one of claims 1-7 above.

Images