CN119248272A

CN119248272A - Method and device for decompressing compressed files

Info

Publication number: CN119248272A
Application number: CN202310809851.XA
Authority: CN
Inventors: 江坤波
Original assignee: Beijing Kingsoft Office Software Inc; Zhuhai Kingsoft Office Software Co Ltd; Wuhan Kingsoft Office Software Co Ltd
Current assignee: Beijing Kingsoft Office Software Inc; Zhuhai Kingsoft Office Software Co Ltd; Wuhan Kingsoft Office Software Co Ltd
Priority date: 2023-07-03
Filing date: 2023-07-03
Publication date: 2025-01-03

Abstract

The embodiment of the present application relates to a method and device for decompressing a compressed file, the method comprising: obtaining a first code, wherein at least part of the first code does not support running on a mini-program, and the first code is used to decompress the compressed file; compiling the first code into a second code, wherein the second code supports running on the mini-program; obtaining the compressed file; and running the second code in the mini-program to decompress the compressed file. Thus, the code for decompressing the compressed file can be run on the front end of the mini-program without uploading and downloading files, which reduces the time of network transmission and relieves the pressure on the back-end server. In addition, it can also avoid problems such as data leakage and file damage in sensitive file transmission, thereby improving the efficiency and security of file decompression.

Description

Decompression method and device for compressed file

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for decompressing a compressed file.

Background

In the prior art, a compressed file is decompressed, and the compressed file to be decompressed is usually required to be sent to a server, and a decompression code is run through the server, so that the compressed file is decompressed. And after decompression is completed, the terminal downloads the decompressed file obtained by decompression from the server for the user to use.

However, in the above decompression method, the efficiency and security of file decompression are low.

Disclosure of Invention

In view of this, in order to solve some or all of the above technical problems, an embodiment of the present application provides a method and an apparatus for decompressing a compressed file.

In a first aspect, an embodiment of the present application provides a method for decompressing a compressed file, where the method includes:

Obtaining a first code, wherein the first code is at least partially unsupported for running on an applet and is used to decompress the compressed file;

compiling the first code into a second code, wherein the second code supports running on the applet;

Acquiring the compressed file;

And running the second code in the applet to decompress the compressed file.

In one possible implementation, the running the second code in the applet to decompress the compressed file includes:

Determining the compressed file as a target file, and executing a decompression step of running the second code in the applet to decompress the target file, determining whether the decompressed file obtained by decompression includes the compressed file or not, and determining that the decompression is completed if the decompressed file does not include the compressed file;

and in the case that the compressed files are included in the decompressed files, determining the compressed files in the decompressed files as target files, and executing the decompressing step based on the determined target files.

In one possible implementation, the decompressing the target file includes:

storing the target file into a memory so as to decompress the target file through the memory;

After the target file is decompressed through the memory, the target file is transferred to a stack, and the memory for storing the target file is recovered.

In one possible implementation manner, the obtaining the compressed file includes:

Acquiring a binary data stream of the compressed file;

Converting the binary data stream into an object of a preset array type;

Storing the object in a memory, and

Said running said second code in said applet to decompress said object file, comprising:

And running the second code in the applet, and reading an object corresponding to the compressed file in the memory to decompress the target file.

In one possible implementation manner, the compiling the first code into the second code includes:

compiling the first code into a second code by adopting a target compiling option;

The target compiling option is used for at least one of setting compiling speed, controlling a shared buffer zone and controlling memory consumption.

In one possible implementation, after the second code is run in the applet to decompress the compressed file, the method further comprises:

And storing the decompressed file obtained by decompression to a cloud.

In one possible implementation manner, after the decompressed file obtained by decompression is stored in the cloud, the method further includes:

Detecting a viewing operation performed on the decompressed file;

and displaying the locally stored decompressed file or displaying the decompressed file stored in the cloud under the condition that the viewing operation is detected.

In one possible implementation manner, first file data of files in the compressed files are represented by nodes of a file tree, each first file data is associated with second file data of corresponding files in the compressed files, the first file data is stored in a memory, the first file data is a file identifier, the second file data is obtained through decompression, and the second file data is stored in a stack.

In a second aspect, an embodiment of the present application provides a decompression apparatus for compressing a file, where the apparatus includes:

A first acquisition unit configured to acquire a first code, wherein the first code is at least partially not supported to run on an applet, and the first code is used to decompress the compressed file;

a compiling unit configured to compile the first code into a second code, where the second code is supported to run on the applet;

The second acquisition unit is used for acquiring the compressed file;

and the decompression unit is used for running the second code in the applet so as to decompress the compressed file.

In one possible implementation, the decompressing the target file includes:

Acquiring a binary data stream of the compressed file;

Converting the binary data stream into an object of a preset array type;

Storing the object in a memory, and

In one possible implementation, after the second code is run in the applet to decompress the compressed file, the apparatus further comprises:

And the storage unit is used for storing the decompressed file obtained by decompression to the cloud.

In one possible implementation manner, after the decompressed file obtained by decompression is stored in the cloud, the apparatus further includes:

the detection unit is used for detecting the checking operation executed on the decompressed file;

And the display unit is used for displaying the locally stored decompressed file or displaying the decompressed file stored in the cloud under the condition that the viewing operation is detected.

In a third aspect, an embodiment of the present application provides an electronic device, including:

A memory for storing a computer program;

And a processor, configured to execute a computer program stored in the memory, where the computer program is executed to implement a method according to any one of the embodiments of the method for decompressing a compressed file according to the first aspect of the present application.

In a fourth aspect, an embodiment of the present application provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method as in any of the embodiments of the method for decompressing compressed files of the first aspect described above.

In a fifth aspect, embodiments of the present application provide a computer program comprising computer readable code which, when run on a device, causes a processor in the device to implement a method as in any of the embodiments of the method of decompressing compressed files of the first aspect described above.

According to the decompression method of the compressed file, the first code can be obtained, wherein at least part of the first code is not supported to run on a small program, the first code is used for decompressing the compressed file, then the first code is compiled into the second code, the second code is supported to run on the small program, then the compressed file is obtained, and then the second code is run in the small program to decompress the compressed file. Therefore, codes for decompressing the compressed file can be operated at the front end of the applet without uploading and downloading the file, the time of network transmission is reduced, the pressure of a rear end server is lightened, and in addition, the problems of data leakage, file damage and the like in sensitive file transmission can be avoided, so that the efficiency and the safety of file decompression are improved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the method and together with the description, serve to explain the principles of the method.

In order to more clearly illustrate the embodiments of the present method or the technical solutions of the prior art, the drawings that are required to be used in the description of the embodiments or the prior art will be briefly described below, and it will be obvious to those skilled in the art that other drawings can be obtained from these drawings without inventive effort.

One or more embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which the figures of the drawings are not to be taken in a limiting sense, unless otherwise indicated.

Fig. 1 is a flow chart of a decompression method of a compressed file according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating another method for decompressing a compressed file according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating a method for decompressing a compressed file according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of a decompression device for compressing files according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

Various exemplary embodiments of the application will now be described in detail with reference to the accompanying drawings, it being apparent that the described embodiments are some, but not all embodiments of the application. It should be noted that the relative arrangement of the components and steps, numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present application unless it is specifically stated otherwise.

It will be appreciated by those skilled in the art that terms such as "first," "second," and the like in the embodiments of the present application are used merely to distinguish between different steps, devices or modules and the like, and do not represent any particular technical meaning or logical sequence therebetween.

It should also be understood that in this embodiment, "plurality" may refer to two or more, and "at least one" may refer to one, two or more.

It should also be appreciated that any component, data, or structure referred to in an embodiment of the application may be generally understood as one or more without explicit limitation or the contrary in the context.

In addition, the term "and/or" in the present application is merely an association relation describing the association object, and indicates that three kinds of relations may exist, for example, a and/or B may indicate that a exists alone, and a and B exist together, and B exists alone. In the present application, the character "/" generally indicates that the front and rear related objects are an or relationship.

It should also be understood that the description of the embodiments of the present application emphasizes the differences between the embodiments, and that the same or similar features may be referred to each other, and for brevity, will not be described in detail.

The following description of at least one exemplary embodiment is merely exemplary in nature and is in no way intended to limit the application, its application, or uses.

Techniques, methods, and apparatus known to one of ordinary skill in the relevant art may not be discussed in detail, but are intended to be part of the specification where appropriate.

It should be noted that like reference numerals and letters refer to like items in the following figures, and thus once an item is defined in one figure, no further discussion thereof is necessary in subsequent figures.

It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. For an understanding of embodiments of the present application, the present application will be described in detail below with reference to the drawings in conjunction with the embodiments. It will be apparent that the described embodiments are some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In order to solve the technical problems of low file decompression efficiency and low file decompression safety in the prior art, the application provides a compressed file decompression method which can improve the file decompression efficiency and the file decompression safety.

Fig. 1 is a flow chart of a decompression method of a compressed file according to an embodiment of the present application. The method can be applied to one or more electronic devices such as smart phones, notebook computers, desktop computers, portable computers, servers and the like. The main execution body of the method may be hardware or software. When the execution body is hardware, the execution body may be one or more of the electronic devices. For example, a single electronic device may perform the method, or multiple electronic devices may cooperate with one another to perform the method. When the execution subject is software, the method may be implemented as a plurality of software or software modules, or may be implemented as a single software or software module. For example, the execution body may be included in the application code of the applet as software. The present application is not particularly limited herein.

As shown in fig. 1, the method specifically includes:

Step 101, obtaining a first code, wherein the first code is at least partially not supported to run on an applet, and the first code is used for decompressing the compressed file.

In this embodiment, the first code may include one or more codes that do not support running on the applet. As an example, the first code may include at least one of c++ code, rust code, and the like.

In addition, in some cases, the first code may also include code that supports running on the applet, in other words, in this case, some of the code in the first code supports running on the applet and another part of the code does not support running on the applet.

The first code may be used to implement the functions of first acquiring data of a compressed file, then decompressing the compressed file, and then outputting a file list.

The applet is an application that can be used without downloading installation. Typically, the applet needs to run in dependence of the host application, e.g. the user may run the applet through an applet portal in the host application. During the running of the applet, the host application may provide a host environment for the applet.

In some cases, the applet may include files in the format JSON configuration file of JSON suffix, WXML template file of WXML suffix, WXSS style file of wxss suffix, JS script logic file.

Step 102, compiling the first code into a second code, wherein the second code supports running on the applet.

In this embodiment, a compiler may be employed to compile the first code, thereby obtaining the second code.

The compiler may be a computer program that converts source code (i.e., the first code) into executable program (i.e., the second code).

Wherein the second code is code that supports execution on the applet.

As an example, in the case of the technique of WebAssembly, the format of the second code may be WebAssembly binary format. The second code may include at least one of the JS (JavaScript) code corresponding to wasm file and wasm file.

WebAssembly (WASM) is a byte code format, and can be run in the environment of a front-end (Web) browser or in the environment outside the front-end (Web) browser, so as to realize working on a plurality of platforms. High performance applications may also be applied to the context of a front-end (Web) browser based on WebAssembly (WASM).

Specifically, webAssembly code may be loaded and run by compiling code developed in a high-level language such as C/C++/Rust/Java (corresponding to the first code described above) or a library of functions into wasm files (corresponding to the second code described above) using EMSCRIPTEN, such that it may be run in a browser environment in conjunction with WebAssembly JS API (Application Programming Interface ).

In the running process of the browser, the wasm file can be called through JS codes by adopting the following steps:

1. The bytecode of wasm files is loaded.

2. The acquired bytecode is converted to ArrayBuffer, and with this structure, it can be correctly compiled. The compilation time may verify ArrayBuffer that the verification passer can compile. After compilation, a parsed Promise object may be returned via Promise resolve. Wherein, promise resolve is a WebAssemblem. Module object (compile completed WebAssembly module).

3. After the module is acquired, the module can be synchronously instantiated through the webassembly.

4. Steps 2 and 3 above can also be equivalently replaced by instaniate asynchronous APIs.

5. It can then be invoked as if it were using the JS code module.

In some alternative implementations of the present embodiment, the first code may be compiled into the second code using a target compilation option.

Specifically, the target compiling option may include at least one of an 'O3' compiling option, an's use_ptreads=0' compiling option, and an's low_memory_grewth=1' compiling option.

The compiling speed can be set through an "-O3" compiling option, for example, the compiling speed can be improved, the problem that an iOS Safari browser is incompatible ShareArrayBuffer with a shared buffer area can be solved through an "-s USE_PTHREADS=0" compiling option, so that the shared buffer area is controlled, the second code obtained through compiling can be ensured to be compatible with various system platforms, and the MEMORY allocation can be increased when the MEMORY exhaustion is detected through an "-sALLOW _MEMORY_GROWTH=1" compiling option, so that the problem Of OOM (Out MEMORY) when the oversized compressed packet is decoded can be solved, and the MEMORY consumption is further controlled.

It should be noted that, in addition to the above-listed target compiling options, other compiling options may be adopted to realize the same functions in practice. For example, a developer may design the compiler itself as well as the compilation options that are required to be used in the compilation process. The above is merely exemplary of target compilation options and is not meant to limit the alternative implementations described above.

It can be appreciated that in the above alternative implementation manner, in the process of compiling the first code into wasm byte codes and glue JS codes, the compiling speed is set, the shared buffer is controlled, and the memory consumption is controlled through the target compiling option.

In some optional implementations of the present embodiment, in a scenario where the second code is a glue JS code, due to a compatibility problem of some applet environments, SDL related code added during compiling libwebp in the glue JS code generated by compiling may be removed, so as to save memory space.

Libwebp is a webp format picture player and decoded library. Wherein webp is a picture format. The parser refers to a process of converting text (character string) in a certain format into a certain data structure.

In some alternative implementations of the present embodiment, code that is not used by the applet may also be removed from the second code. For example, in the case where the second code includes a glue JS code, unused codes in the applet in the glue JS code may also be removed, such as the code associated with ENVIRONMENT_IS_NODE/ENVIRONMENT_IS_SHELL.

In some alternative implementations of the present embodiment, the method of streaming compiling and instantiating in the second code may be omitted, and replaced with a method of non-streaming compiling and instantiating, so as to solve the problem of compatibility of the iOS Safari and other browsers.

In some alternative implementations of the present embodiment, the error-reporting code in the second code may also be deleted or adjusted. For example, in the case where the second code is the glue JS code, when the new webassembly.memory code runs in some applet environments, an error of "refused to create a webassembly object without' unsafe-eval" is reported, which can be solved by adding unsafe-eval to the CSP (Content-Security-Policy) setting in page-frame.html.

In some alternative implementations of the present embodiment, the code that is not supported by the applet in the second code may be replaced with the code that is supported by the applet. For example, some applet ios do not support function code such as export, global, newFunction, but support functions, memory, table. Thereby, the second code can be adjusted.

It should be noted that, after the second code is adjusted (including adding, deleting, replacing, etc.), an updated second code may be obtained, and the subsequent steps are all required to be performed based on the updated second code.

For example, the glue JS code (corresponding to the second code) may be compiled through steps 2 and 3 of the glue JS code call wasm. After the glue JS codes are adjusted, the adjusted glue JS codes can be further operated. The adjusting of the glue JS codes can comprise at least one of removing SDL related codes added in libwebp compiling time in the compiling generated glue JS codes, removing codes which are not used by the applet, removing a streaming compiling and instantiating method, deleting or adjusting error reporting codes in the glue JS codes, and replacing codes which are not supported by the applet in the codes with codes supported by the applet.

And step 103, obtaining the compressed file.

In this embodiment, the compressed file may include a file in at least one format selected from the group consisting of RAR, 7z, ZIP, and the like. Further, the compressed file is a file obtained by compressing the original file, and may be one or more files. In the case that the original file corresponding to the compressed file includes a plurality of files, the files included in the original file may be compressed files or uncompressed files.

Wherein, RAR is a data compression format, which can be used on a plurality of platforms. 7z is an efficient compression algorithm and file format that provides a better compression ratio than other compression formats. ZIP is an archive format that can be used on multiple platforms.

Here, the above step 103 may be performed using the JS code of the applet so as to acquire the compressed file.

In some optional implementations of this embodiment, the compressed file may be obtained in the following manner:

first, a binary data stream of the compressed file is obtained.

And then converting the binary data stream into an object of a preset array type.

The preset array type may be a predetermined array type. The preset array type may be used to store the relevant data of the compressed file in the memory. For example, the preset Array type may be a Uint8Array (8-bit unsigned integer Array) type.

The object is then stored in memory.

On the basis, the second code can be operated in the small program to decompress the target file, namely, the second code is operated in the small program, and the object corresponding to the compressed file in the memory is read to decompress the target file.

Here, the applet and the second code may share the memory.

As an example, a binary data stream of a compressed file may be passed to WebAssembly module. In the memory management mechanism of WebAssembly, data is stored in the form of an array in memory. Thus, the binary data stream can be converted into an object of the Uint8Array type and passed to the memory Array of WebAssembly modules. This process may use the readFile function of an applet, which may take the binary data stream of the compressed file and then convert it into an object of the Uint8Array type. Therefore, the object corresponding to the compressed file in the memory can be read by running the second code in the applet, so that the decompression of the target file can be realized.

It can be appreciated that in the above alternative implementation manner, the binary data stream of the compressed file may be converted into an object of a preset array type and then stored in the memory, so that the I/O (InputOutput, input and output) operation may be minimized by directly operating the data stream in the memory, thereby improving the execution efficiency of the program and reducing the memory overhead.

In some alternative implementations of the present embodiment, the first file data of the files in the compressed file is represented by nodes of a file tree. Each of the first file data is associated with second file data of a corresponding one of the compressed files. The first file data is stored in a memory. The first file data is a file identifier. The second file data is obtained via decompression and stored in a stack.

It can be appreciated that in the above alternative implementation manner, the first file data is stored by the memory, and the second file data is stored by the stack, so that the occupation of the memory can be further reduced, and the running stability of the second code in the applet can be further improved.

And 104, running the second code in the applet to decompress the compressed file.

In this embodiment, the format of the compressed file may be first determined, and then a corresponding algorithm is adopted to implement decompression of the compressed file.

In practice, a portion of the beginning of each file (including the compressed file) may contain metadata information for determining the file format. Thus, the file format can be determined by Magic Number. Where the Magic Number is a special sequence of numbers or bytes that can be used to determine the file format.

Here, the above step 104 may be performed using JS code to run the second code in the applet to decompress the compressed file.

In some alternative implementations of the present embodiment, the compressed file may be decompressed in the following manner:

firstly, storing the compressed file into a memory so as to decompress the compressed file through the memory.

And after the compressed file is decompressed through the memory, the compressed file is transferred to a stack, and the memory for storing the compressed file is recovered.

It can be appreciated that in the above alternative implementation manner, after the file is decompressed, the memory corresponding to the decompressed file may be recovered and saved in the stack, so that the occupation of the stack memory may be reduced, and further the running stability of the second code in the applet may be improved.

Fig. 2 is a flowchart illustrating another method for decompressing a compressed file according to an embodiment of the present application. As shown in fig. 2, the method specifically includes:

step 201, obtaining a first code, wherein the first code is at least partially not supported to run on an applet, and the first code is used for decompressing the compressed file. Thereafter, step 202 is performed.

In this embodiment, step 201 is substantially identical to step 101 in the corresponding embodiment of fig. 1, and will not be described herein.

Step 202, compiling the first code into a second code, wherein the second code supports running on the applet. Thereafter, step 203 is performed.

In this embodiment, step 202 is substantially identical to step 102 in the corresponding embodiment of fig. 1, and will not be described here again.

And 203, acquiring the compressed file. Thereafter, step 204 is performed.

In this embodiment, step 203 is substantially identical to step 103 in the corresponding embodiment of fig. 1, and will not be described herein.

Step 204, determining the compressed file as a target file, and performing the following decompression step.

In this embodiment, the decompression step includes steps 211-213.

Step 211, running the second code in the applet to decompress the target file. Thereafter, step 212 is performed.

In this embodiment, the format of the target file may be first determined, and then a corresponding algorithm is adopted to implement decompression of the target file.

In practice, a portion of the beginning of each file (including the target file, the decompressed file) may contain metadata information for determining the file format. Thus, the file format can be determined by Magic Number. Where the Magic Number is a special sequence of numbers or bytes that can be used to determine the file format.

In some alternative implementations of the present embodiment, the target file may be decompressed in the following manner:

Firstly, storing the target file into a memory so as to decompress the target file through the memory.

And after the target file is decompressed through the memory, the target file is transferred to a stack, and the memory for storing the target file is recovered.

Step 212, it is determined whether the decompressed file obtained by decompression includes a compressed file. If yes, step 205 is executed, and if no, step 213 is executed.

In the present embodiment, after decompressing a compressed file (hereinafter referred to as file a), a decompressed file may be obtained, and the format of the compressed file included in the decompressed file may be the same as or different from that of the above-described file a. For example, a file in RAR format may be included in a decompressed file obtained by decompressing the file a in ZIP format.

In step 213, decompression is determined to be complete.

And step 205, determining the compressed files in the decompressed files as target files. Thereafter, step 211 is performed.

It should be noted that, in addition to the above descriptions, the present embodiment may further include the corresponding technical features described in the embodiment corresponding to fig. 1, so as to achieve the technical effects of the decompression method of the compressed file shown in fig. 1, and the detailed description with reference to fig. 1 is omitted herein for brevity.

The decompression method of the compressed file can support the decompression of the compressed file in the compressed file so as to comprehensively decompress all files in the compressed file, thereby improving the convenience and comprehensiveness of file decompression.

Fig. 3 is a flowchart illustrating a decompression method of a compressed file according to another embodiment of the present application.

Specifically, as shown in fig. 3, the method specifically includes:

step 301, obtaining a first code, wherein the first code is at least partially not supported to run on an applet, and the first code is used for decompressing the compressed file.

In this embodiment, step 301 is substantially identical to step 101 in the corresponding embodiment of fig. 1, and will not be described herein.

Step 302, compiling the first code into a second code, wherein the second code is supported to run on the applet.

In this embodiment, step 302 is substantially identical to step 102 in the corresponding embodiment of fig. 1, and will not be described herein.

Step 303, obtaining the compressed file.

In this embodiment, step 303 is substantially identical to step 103 in the corresponding embodiment of fig. 1, and will not be described herein.

Step 304, running the second code in the applet to decompress the compressed file.

In this embodiment, step 304 is substantially identical to step 104 in the corresponding embodiment of fig. 1, and will not be described herein.

And step 305, storing the decompressed file obtained by decompression to a cloud.

In this embodiment, the decompressed file obtained by decompression is stored in the cloud end so as to backup the decompressed file.

In some alternative implementations of the present embodiment, after performing step 305 described above, the following steps may also be performed:

first, a viewing operation performed on the decompressed file is detected.

And then, under the condition that the checking operation is detected, displaying the locally stored decompressed file or displaying the decompressed file stored in the cloud.

It may be appreciated that in the above alternative implementation manner, after the decompressed file is stored in the cloud, if the user needs to view the decompressed file, the decompressed file may be obtained from the local or cloud so as to display the decompressed file, thereby preventing the decompressed file from being lost due to the applet being closed.

According to the decompression method of the compressed file, the decompressed file obtained through decompression is stored in the cloud, so that the decompressed file can be stored in the cloud, and the decompressed file can be backed up.

The following description is given by way of example of the embodiments of the present application, but it should be noted that the embodiments of the present application may have the features described below, and the following description does not limit the scope of protection of the embodiments of the present application.

In the current technical environment, the industry has temporarily no mature file decompression scheme in the front-end scenario. For example, conventional c++/Rust applications need to run on a local computer and cannot be used in browser kernels in browser and web applications. The server decompression scheme requires uploading files to the server, thus requiring more computing resources and time, and having a certain risk in terms of privacy and security.

The technology of the browser is mainly applied to HTML (HyperText Markup Language ) application, which is a trend, can be developed by a platform and used by multiple platforms, and the local application of the computer is limited by the platform, such as the application in mac and windows needs to be designed respectively.

Compared with the scheme, the embodiment of the application provides a decompression scheme based on WebAssembly technology, and the scheme can directly decompress RAR, 7z and ZIP files at the applet end. By utilizing WebAssembly technology, file operability can be improved by simulating the running environment of C. Furthermore, webAssembly technology is also one of the advantages of compatibility and ease of use in Web platforms. Therefore, the file decompression method and device can provide a faster, safer and more reliable file decompression experience.

Specifically, the C++/Rust code (i.e., the first code described above) may be compiled into WebAssembly binary format (i.e., the second code described above) using WebAssembly techniques, which may enable high-performance operation on a local computer while also being directly usable in a browser. Secondly, the file (such as the compressed file and the target file) can be read into the memory through the memory mapping technology, so that the efficiency of file reading and analysis can be greatly improved. Meanwhile, the file format is rapidly judged by using a file header identification technology, so that a corresponding decompression algorithm is selected. Finally, by optimizing the decompression algorithm, the memory occupation and the CPU (Central Processing Unit ) utilization rate can be reduced as much as possible while the decompression speed and the file integrity are ensured. And the file is not required to be uploaded to a server side when being decompressed, and the full decompression of the compression packet in the compression packet can be supported.

In the method, binary data streams in compressed packets (i.e., compressed files as described above) may be passed to WebAssembly modules. In the memory management mechanism of WebAssembly, data is stored in the memory in the form of an Array, so that the data stream can be converted into an object of the Uint8Array type (i.e., the preset Array type described above) and transferred to the memory Array of the WebAssembly module. This process can be implemented using a readFile of an applet, which API (Application Programming Interface ) can read the file as a binary data stream and then convert it to an object of the Uint8Array type.

Next, the decompression function is implemented by the written WebAssembly module code. WebAssembly is a low-level bytecode that needs to be written in a high-level language such as c++ and then compiled into WebAssembly modules by a compiler. In this scheme, webAssembly modules may be written in the c++ language. In modules, memory management may be performed using memory pool techniques. The memory pool is used for pre-distributing a certain amount of memory and then distributing the memory when needed, so that frequent memory application and recovery are avoided, and the efficiency is improved. At the same time, the full decompression function of the compressed package inside the compressed package is realized, and the function is realized by using a recursion algorithm.

The memory pool is a memory allocation technology, which allocates a certain number of memory blocks in advance, called a memory pool, and allocates memory therefrom when needed. Compared with the traditional dynamic memory allocation method, the memory pool has the advantages that frequent memory application and recovery operations can be avoided, and therefore the running efficiency and performance of the program are improved.

There are many ways in which memory pools may be implemented, with the most common being to use a linked list or array to manage the memory pools. When a program first uses a memory pool, it creates a certain number of memory blocks and links them into a linked list. When memory needs to be allocated, the program can search a memory block with enough size from the linked list and put the memory block into the linked list again after the use is completed. Thus, when the program needs to allocate memory again, it can find an available memory block from the linked list instead of calling the system function to apply for memory.

The memory is stored using a linked list and then when the file is read, the memory is dynamically reclaimed when an identifier of the beginning or end of the file is found. Therefore, the situation that the memory is forcedly and automatically recovered by the small program to cause the decompressed file to be lost is avoided to a certain extent.

In addition to memory management and decompression algorithms, there may be compatibility issues with using WebAssembly modules in the applet. For example, webAssembly has better compatibility on Web platforms, but compatibility in applets still has certain problems. At the same time, attention is paid to the problem of memory occupation. The applet has a certain memory limit, and if the memory is used too much, the applet can be automatically killed, so that the program is crashed. Therefore, the control of memory occupation can be realized in the program in the following way, so as to avoid program crash caused by excessive memory usage.

(1) When compiling, an "-O3" option (namely the target compiling option) is added, so that the compiling speed is greatly set.

(2) The "-s use_ptrleads=0" option (i.e., the target compilation option described above) is added at compile time because iOS Safari browser is incompatible ShareArrayBuffer with the shared buffer.

(3) The coding time needs to add an "-s ALLOW_MEMORY_GROWTH=1" option (namely the target coding option) so as to solve the OOM problem when decoding the oversized compression packet.

(4) Due to the compatibility problem of the applet environment, SDL related codes added during the compiling of libwebp in the glue JS codes (namely the second codes) are removed, and the space of about 100KB can be saved.

(5) And removing codes related to the ENVIRONMENT_IS_NODE/ENVIRONMENT_IS_SHELL in the compiled glue JS codes, wherein the applet ENVIRONMENT IS not used.

(6) Due to the compatibility problem of the iOS Safari browser, the method of streaming compiling and instantiating in the glue JS codes is removed and replaced by a method of non-streaming compiling and instantiating.

(7) When the new WebAssemblem.memory code in the glue JS code runs in the applet environment, an error of ' refused to create a webassembly object without ' unsafe-eval ' can be reported, and unsafe-eval needs to be added in CSP setting in page-frame.html to be solved.

(8) The applet iOS does not support export support functions, memory, table, and the iOS platform does not support Global.

(9) The applet environment does not support codes in the glue JS codes, such as new Function and other functional codes, and the codes need to be converted into codes which can be identified by the applet.

Furthermore, the same object in the present method can be achieved in a variety of implementations.

For example, for the memory management scheme described above, there may be alternatives to using virtual memory or file swapping, among others. Virtual memory is a technique that increases the available memory by moving part of the memory into virtual memory in a hard disk to meet the memory requirements of processes. However, the implementation of virtual memory involves a large number of hard disk I/O operations, which can result in reduced program performance. Meanwhile, file exchange is also a technology for exchanging contents in a memory to a hard disk, but there is also a bottleneck in performance. In contrast, by adopting the memory management scheme, the data flow in the memory can be directly operated to minimize the I/O operation, so that the execution efficiency of the program is improved.

In addition, for the compressed file decompression technology, the applet end has no other mature scheme. The existing schemes in the industry are mostly completed by a service end, so that the experience of users is reduced to a certain extent.

The method can solve the requirement on file decompression in the development of small programs, and the traditional decompression scheme often needs to upload files to a back-end server, thereby increasing the time of network transmission and the pressure of the server. The method adopts WebAssembly technology to compile C++/Rust code into a cross-platform low-level code (namely the second code), and the code is directly executed at the front end of the small program, so that the network transmission time is shortened, the burden of a server is lightened, and meanwhile, the decompression efficiency and the security are ensured. In addition, the method also supports decompression of files in various compression formats and compression package decompression in the compression package, and enhances flexibility and comprehensiveness of decompression schemes, so that more efficient and convenient file decompression service is provided, requirements of users on file processing are met, and use experience of the users is improved.

It should be noted that, in addition to the above descriptions, the present embodiment may further include the technical features described in the above embodiments, so as to achieve the technical effects of the decompression method of the compressed file described above, and the detailed description is referred to above, and is omitted herein for brevity.

The decompression scheme of the method is suitable for various document application scenes developed based on the small program, including but not limited to decompression of various document types such as electronic books, PDF, word, PPT and the like. By using the decompression scheme of the method, a user can rapidly decompress the document at the front end of the applet, so that the document processing efficiency and the user experience are improved. In addition, the WebAssembly technology of the method can be applied to other document application scenes needing to efficiently process big data, such as document editing, reading, conversion and other fields, and can improve the data processing efficiency and cross-platform compatibility. The method compiles the C++/Rust code into the code which can be operated at the front end of the applet by utilizing WebAssembly technology, realizes the decompression function of the front end of the applet, and avoids the defect that the file needs to be uploaded to the server in the traditional decompression scheme. The method supports various compression file formats including RAR, 7z, ZIP and the like, and supports decompression of the compression files in the compression package, so that the decompression flexibility is improved. The method utilizes WebAssembly technology, can run the existing C++/Rust code on the front end of the applet without greatly changing, and has cross-platform compatibility. The method effectively reduces the memory occupation of the program through a fine read-write and recovery mechanism of the memory. Compared with the traditional file operation mode, the method does not need to read the whole file into the memory, but reduces the cost of the memory by a mode of reading data in a streaming mode. The decompression method can directly operate the file through the streaming data, so that the time and space waste of the operation after decompressing the whole file in the traditional method is avoided. In addition, the method uses the technology of memory reading and recycling, so that the file can be rapidly and efficiently read and processed in the decompression process, thereby greatly improving the decompression speed and efficiency. The decompression method ensures the decompression precision through fine memory management and streaming data operation, and avoids the problems of data loss, file damage and the like possibly occurring in the traditional method. The decompression method of the method uses the operation of streaming data, simplifies a plurality of operation steps in the traditional decompression method, ensures that a user can complete the decompression of all compressed files in the same file through simple operation, and improves the use experience of the user.

Fig. 4 is a schematic structural diagram of a decompression device for compressing files according to an embodiment of the present application.

The method specifically comprises the following steps:

a first obtaining unit 401, configured to obtain a first code, where the first code is at least partially not supported to run on an applet, and the first code is used to decompress the compressed file;

a compiling unit 402, configured to compile the first code into a second code, where the second code supports running on the applet;

a second obtaining unit 403, configured to obtain the compressed file;

and a decompression unit 404, configured to run the second code in the applet to decompress the compressed file.

In one possible implementation, the decompressing the target file includes:

Acquiring a binary data stream of the compressed file;

Converting the binary data stream into an object of a preset array type;

and storing the object in a memory.

and the storage unit (not shown in the figure) is used for storing the decompressed file obtained by decompression to the cloud.

a detection unit (not shown in the figure) for detecting a viewing operation performed on the decompressed file;

and a display unit (not shown in the figure) configured to display the decompressed file stored locally or display the decompressed file stored in the cloud in a case where the viewing operation is detected.

The decompression device for compressed files provided in this embodiment may be a decompression device for compressed files as shown in fig. 4, and may perform all the steps of the decompression method for compressed files described above, so as to achieve the technical effects of the decompression method for compressed files described above, and specific reference is made to the above related description, which is omitted herein for brevity.

Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application, and the electronic device 500 shown in fig. 5 includes at least one processor 501, a memory 502, at least one network interface 504, and other user interfaces 503. The various components in the electronic device 500 are coupled together by a bus system 505. It is understood that bus system 505 is used to enable connected communications between these components. The bus system 505 includes a power bus, a control bus, and a status signal bus in addition to a data bus. But for clarity of illustration the various buses are labeled as bus system 505 in fig. 5.

The user interface 503 may include, among other things, a display, a keyboard, or a pointing device (e.g., a mouse, a trackball, a touch pad, or a touch screen, etc.).

It will be appreciated that the memory 502 in embodiments of the application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (STATIC RAM, SRAM), dynamic random access memory (DYNAMIC RAM, DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate Synchronous dynamic random access memory (Double DATA RATE SDRAM, DDRSDRAM), enhanced Synchronous dynamic random access memory (ENHANCED SDRAM, ESDRAM), synchronous link dynamic random access memory (SYNCH LINK DRAM, SLDRAM), and Direct memory bus random access memory (DRRAM). The memory 502 described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

In some implementations, the memory 502 stores elements, executable units or data structures, or a subset thereof, or an extended set thereof, an operating system 5021 and application 5022.

The operating system 5021 includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, for implementing various basic services and processing hardware-based tasks. The application 5022 includes various application programs, such as a media player (MEDIA PLAYER), a Browser (Browser), and the like, for implementing various application services. A program for implementing the method according to the embodiment of the present application may be included in the application 5022.

In this embodiment, the processor 501 is configured to execute the method steps provided in the method embodiments by calling a program or an instruction stored in the memory 502, specifically, a program or an instruction stored in the application 5022, for example, including:

Acquiring the compressed file;

And running the second code in the applet to decompress the compressed file.

The method disclosed in the above embodiment of the present application may be applied to the processor 501 or implemented by the processor 501. The processor 501 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuitry in hardware or instructions in software in the processor 501. The Processor 501 may be a general purpose Processor, a digital signal Processor (DIGITAL SIGNAL Processor, DSP), an Application SPECIFIC INTEGRATED Circuit (ASIC), an off-the-shelf programmable gate array (Field Programmable GATE ARRAY, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software elements in a decoding processor. The software elements may be located in a random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory 502, and the processor 501 reads information in the memory 502 and, in combination with its hardware, performs the steps of the method described above.

It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For a hardware implementation, the Processing units may be implemented within one or more Application SPECIFIC INTEGRATED Circuits (ASICs), digital signal processors (DIGITAL SIGNAL Processing, DSPs), digital signal Processing devices (DSPDEVICE, DSPD), programmable logic devices (Programmable Logic Device, PLDs), field-Programmable gate arrays (Field-Programmable GATE ARRAY, FPGA), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units for performing the above-described functions of the application, or a combination thereof.

For a software implementation, the techniques described herein may be implemented by means of units that perform the functions described herein. The software codes may be stored in a memory and executed by a processor. The memory may be implemented within the processor or external to the processor.

The electronic device provided in this embodiment may be an electronic device as shown in fig. 5, and may perform all the steps of the above-described decompression method of each compressed file, so as to achieve the technical effects of the above-described decompression method of each compressed file, and specific reference is made to the above-described related description, which is omitted herein for brevity.

The embodiment of the application also provides a storage medium (computer readable storage medium). The storage medium here stores one or more programs. The storage medium may include volatile memory, such as random access memory, or nonvolatile memory, such as read only memory, flash memory, hard disk, or solid state disk, or a combination of the foregoing.

When one or more programs in the storage medium are executable by one or more processors, the above-described method for decompressing a compressed file executed on the electronic device side is implemented.

The above processor is configured to execute a decompression program of a compressed file stored in a memory, so as to implement the following steps of a method for decompressing a compressed file executed on an electronic device side:

Acquiring the compressed file;

And running the second code in the applet to decompress the compressed file.

Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of function in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, in a software module executed by a processor, or in a combination of the two. The software modules may be disposed in Random Access Memory (RAM), memory, read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

It is to be understood that the terminology used herein is for the purpose of describing particular example embodiments only, and is not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises," "comprising," "includes," "including," and "having" are inclusive and therefore specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order described or illustrated, unless an order of performance is explicitly stated. It should also be appreciated that additional or alternative steps may be used.

The foregoing is merely a specific embodiment of the present method to enable one skilled in the art to understand or practice the present method. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the method. Thus, the present method is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of decompressing a compressed file, the method comprising:

Acquiring the compressed file;

And running the second code in the applet to decompress the compressed file.

2. The method of claim 1, wherein the running the second code in the applet to decompress the compressed file comprises:

3. The method of claim 2, wherein decompressing the target file comprises:

4. The method of claim 1, wherein the obtaining the compressed file comprises:

Acquiring a binary data stream of the compressed file;

Converting the binary data stream into an object of a preset array type;

Storing the object in a memory, and

5. The method of claim 1, wherein compiling the first code into a second code comprises:

6. The method of claim 1, wherein after running the second code in the applet to decompress the compressed file, the method further comprises:

And storing the decompressed file obtained by decompression to a cloud.

7. The method of claim 6, wherein after storing the decompressed file obtained by decompression to the cloud, the method further comprises:

Detecting a viewing operation performed on the decompressed file;

8. The method according to one of claims 1 to 7, wherein first file data of files in the compressed files are represented by nodes of a file tree, each of the first file data is associated with second file data of a corresponding file in the compressed files, the first file data is stored in a memory, the first file data is a file identification, the second file data is obtained via decompression, and the second file data is stored in a stack.

9. A decompression apparatus for compressing a file, the apparatus comprising:

The second acquisition unit is used for acquiring the compressed file;

10. An electronic device, comprising:

A memory for storing a computer program;

A processor for executing a computer program stored in said memory, and which, when executed, implements the method of any of the preceding claims 1-8.

11. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any of the preceding claims 1-8.