WO2014101208A1

WO2014101208A1 - Method and device for obtaining file

Info

Publication number: WO2014101208A1
Application number: PCT/CN2012/088091
Authority: WO
Inventors: 王嗣琛; 周皓隽
Original assignee: 华为技术有限公司
Priority date: 2012-12-31
Filing date: 2012-12-31
Publication date: 2014-07-03
Also published as: CN104137073B; CN104137073A

Abstract

Disclosed are a method and device for obtaining a file; the method applies to a file system based on the sandbox mechanism. The method comprises: a browser receiving a file saving request initiated by an application programming interface of a first file system which is provided by a first application through the browser; saving the file needed to be stored by the first application in the file system according to the file saving request; receiving an instruction of obtaining the file triggered by a second application whose source is different from that of the first application, wherein the instruction carries the path of the file; and obtaining the path of the file, obtaining the file from the file system according to the path of the file, and providing the file to the second application. Embodiments of the present invention are applied to implement cross-source access in the file system.

Description

Method and device for acquiring files

The present invention relates to the field of communications technologies, and in particular, to a method and apparatus for acquiring a file.

BACKGROUND OF THE INVENTION With the development of Internet services, the use of web applications for the World Wide Web has become more widespread. A web application is an application that causes a browser to execute commands or actions required by the web application by invoking a web application programming interface (API). Among them, the web API is a call interface that the browser opens to the web application. Currently, the browser provides a set of APIs for the file system filesystem in the API that is open to the application. Applications can be obtained by calling the filesystem API interfaces, application data is written f ilesystem ₀ f ilesysem is a sandbox sandbox mechanism-based file system, the source (origin) to determine the unit who follow the principles of preservation who acquired from different sources can not be applied Get the other party's data. The application invokes the filesystem API interface to instruct the browser to allocate a file system storage space of a certain size, which is used to save the application data, and to read and write files and directories in the application-defined filesystem.

The origin is a subset of the URL, and each web application has a URL. The source consists of the scheme part, the host part, and the port part of the application's URL. Due to different rules (3⁄4. hUps and hup), the source of the hups:〃 www. hello, com page and http: //www. hello, com page are different. The concept of the source does not take into account the path, such as http: //www.hel lo. com/ index, html and hup: //www.hel lo. com/ ages, html has the same source.

For example, the following sources are different sources:

Http: / / example, com/ Http: / / example, com: 8080/

Http: //www. example, com/

Hups: / / example, com: 80/

Hups: / / example, com/

Http: //example, org/

The following sources are homologous:

Http: / / example, com/

Http: / / example, com: 80/

Http: / / example, com/ ath/ file

In the prior art, the file automatically saved by the browser is directly saved by the browser to the filesystem on the user device, and only the browser can directly operate (such as modifying, reading, etc.) the previously saved file. Since the filesystem is a file system based on the s andbox mechanism, the file automatically saved by the application through the browser can only be obtained by the application with the same application as the application, and the application different from the application cannot obtain the file. The file, that is, the source A web application cannot obtain the file of the source B application saved in the filesystem.

SUMMARY OF THE INVENTION Embodiments of the present invention provide a method and an apparatus for acquiring a file, so as to obtain a file across a source in a filesystem.

In the first aspect, the method for obtaining a file is applied to a file system filesystem based on a sandbox sandbox mechanism, and the method includes:

Receiving, by the browser, a file save request initiated by the first application by the first file system application programming interface filesystem API provided by the browser;

Saving the file to be saved by the first application to the file system filesystem according to the file save request; Receiving an instruction for acquiring the file triggered by a second application that is different from the first application, where the instruction carries a path of the file;

Obtaining a path of the file, and obtaining the file from the system according to a path of the file, and providing the file to the second application.

In a first possible implementation manner of the first aspect, the method further includes:

Recording a creation source of the file, the creation source is a source of the first application that saves the file, and receiving an authorization source of the file specified by the first application, where the authorization source is authorized to obtain the Source of the file;

Recording an authorization source of the file, where the authorization source includes a source of the second application.

With reference to the first possible implementation manner of the first aspect, in a second possible implementation manner, the acquiring the file from the file system of the first application according to the path of the file, Providing to the second application specifically includes:

Locating the file in the f lesyetem according to the path of the file;

After finding the file, matching the source of the second application with the creation source of the file and the authorization source, and when determining that the source of the second application is an authorization source of the file, A file is provided to the second application.

With reference to the first aspect, or the first possible implementation manner of the first aspect, or the second possible implementation manner of the first aspect, in a third possible implementation manner, the receiving is different from the first application The instructions for acquiring the file triggered by the second application include:

Receiving, by the second application, a second trigger API provided by the browser to acquire a call instruction of the file.

In conjunction with the third possible implementation of the first aspect, in a fourth possible implementation, the method further includes:

Receiving a path of the file sent by the first application to the second application after saving the file;

Forwarding the path of the file to the second application, so that the second application is according to the The path of the file initiates the call instruction.

With the fourth possible implementation of the first aspect, in a fifth possible implementation, the path of the file is carried in a cross-document communication message postMessage sent by the first application to the second application, or And carried in the Hypertext Transfer Protocol (HTTP) message sent by the first application to the second application.

In conjunction with the first possible implementation of the first aspect, in a sixth possible implementation, the method further includes:

The browser receives a file acquisition request initiated by the second application by using the file API, where the file acquisition request instructs the browser to acquire the file by using a manner selected by the user;

The browser opens a file selection interface according to the file acquisition request, and displays an optional file in the filesystem in the file selection interface;

The instruction for acquiring the file triggered by the second application receiving the different source of the first application comprises: receiving an instruction of the user to select the file in the file selection interface.

In conjunction with the sixth possible implementation of the first aspect, in a seventh possible implementation, the displaying, in the file selection interface, the optional file in the filesystem includes:

The browser determines an optional file in the filesystem that can be obtained by the second application, generates an associated virtual file for each optional file, and uses the path of the optional file as the information associated with the virtual file, and The generated virtual file is presented in the file selection interface such that the user selects a file associated with the virtual file through the virtual file.

In conjunction with the sixth possible aspect of the first aspect or the seventh possible implementation of the first aspect, in an eighth possible implementation, before the optional file in the filesystem is displayed in the file selection interface, : generating a filesystem virtual folder, and displaying the filesystem virtual folder as a system disk in the file selection interface, and executing the file selection interface after receiving an operation of the user selecting the filesystem virtual folder The operation of displaying optional files in filesystem.

In conjunction with the eighth possible implementation of the first aspect, in a ninth possible implementation manner, When the browser determines an optional file that can be obtained by the second application in the filesystem, the method further includes: determining a creation source of the optional file, and respectively generating a virtual folder of each creation source; The virtual file being displayed in the file selection interface specifically includes: using the virtual folder of the creation source as a subfolder in the filesystem virtual folder, and placing the virtual file of the optional file in a corresponding In the virtual folder of the creation source, the subfiles in the virtual folder as the creation source are presented.

Combining the sixth possibility of the first aspect or the seventh possibility of the first aspect or the eighth possible aspect of the first aspect or the ninth possible implementation manner of the first aspect, in a tenth possible implementation manner, The browser determines that the optional file that can be obtained by the second application in the filesystem specifically includes:

A file that creates a source including the source of the second application, and a file whose source of authorization includes the source of the second application is determined to be an optional file in the filesystem that is obtainable by the second application.

In a second aspect, a device for acquiring a file is applied to a file system filesystem based on a sandbox sandbox mechanism, the device comprising:

An interface unit, configured to provide a first file system application programming interface filesystem API, and a request processing unit, configured to receive a file save request initiated by the first filesystem API provided by the first application by the interface unit;

a saving unit, configured to save the file to be saved by the first application to the file system f i 1 e s y s t em according to the file save request received by the request processing unit;

An event processing unit, configured to receive an instruction for acquiring a file saved by the first application triggered by a second application that is different from the first application, where the instruction carries a path of the file;

An obtaining unit, configured to acquire a path of the file from an instruction received by the event processing unit, and obtain the file from the filesystem according to a path of the file;

And a providing unit, configured to provide the file acquired by the acquiring unit to the second application. In a first possible implementation manner of the second aspect, the request processing unit is further configured to receive an authorization source of the file specified by the first application, where the authorization source is authorized to obtain Take the source of the file;

The saving unit is further configured to record a creation source of the file and an authorization source of the file, where the creation source is a source of a first application that saves the file, and the authorization source includes the second application. Source.

With reference to the first possible implementation of the second aspect, in a second possible implementation, the acquiring unit specifically includes:

Obtaining a subunit, configured to acquire a path of the file from an instruction received by the event processing unit;

a searching subunit, configured to search for the file in the f i lesys according to the path obtained by the obtaining subunit;

An authentication subunit, configured to: after the searching subunit finds the file, match a source of the second application with a creation source and an authorization source of the file, and determine a source of the second application. When the authorization source is the file, the providing unit is notified to send the file found by the searching module to the second application.

With reference to the second aspect or the first possible implementation of the second aspect or the second possible implementation of the second aspect, in a third possible implementation, the interface unit is further configured to provide the second fi Lesys tem API interface;

And the event processing unit receives, by using the second terminal API provided by the interface unit, the calling instruction that is triggered by the second application to acquire the file.

In conjunction with the third possible implementation of the second aspect, in a fourth possible implementation, the device further includes:

a forwarding unit, configured to receive a path of the file sent by the first application to the second application after saving the file, and forward a path of the file to the second application, so that the The second application initiates the call instruction according to the path of the file.

With reference to the fourth possible implementation manner of the second aspect, in a fifth possible implementation manner, the path of the file carries a cross-document communication message sent by the first application to the second application In the pos tMes sage, or in the Hypertext Transfer Protocol HTTP message sent by the first application to the second application.

In conjunction with the first possible implementation of the second aspect, in a sixth possible implementation, the interface unit is further configured to provide a f i le API;

The event processing unit specifically includes:

a receiving subunit, configured to receive a file obtaining request initiated by the second application through the interface provided by the interface unit, where the file obtaining request indicates that the file is obtained by using a mode selected by the user;

An interaction subunit, configured to open a file selection interface according to the file acquisition request received by the receiving subunit, and display an optional file in the file in the file selection interface, and receive the user in the file selection interface, An instruction to select a file saved by the first application.

With reference to the sixth possible implementation of the second aspect, in a seventh possible implementation, the interaction sub-unit specifically includes:

An interface module, configured to open a file selection interface according to a file acquisition request received by the receiving subunit;

a content module, configured to determine an optional file in the system that can be obtained by the second application; a generating module, configured to generate an associated virtual file for each optional file determined by the content module, to select the The path of the file as the information associated with the virtual file,

a presentation module, configured to display the virtual file generated by the generation module in a file selection interface opened by the interface module, so that the user selects a file associated with the virtual file by using the virtual file;

And an event module, configured to receive an instruction that the user selects a file saved by the first application in the file selection interface.

With reference to the sixth possible aspect of the second aspect, or the seventh possible implementation manner of the second aspect, in the eighth possible implementation, the generating module is further configured to generate a virtual folder; The presentation module is further configured to display the filesystem virtual folder generated by the generating submodule as a system disk in the file selection interface;

The event module is further configured to receive an operation of the user selecting the filesystem virtual folder, and after receiving the operation, instructing the presentation module to perform the displaying the optional file in the filesystem in the file selection interface. operating.

With reference to the eighth possible implementation of the second aspect, in a ninth possible implementation, the content module is further configured to determine a source of creation of the optional file;

The generating module is further configured to separately generate a virtual folder of each creation source determined by the content module;

The presentation module specifically includes:

a first presentation submodule, configured to display the filesystem virtual folder generated by the generating module as a system disk in the file selection interface;

a second presentation submodule, configured to display the virtual folder of the creation source generated by the generation module as a subfolder in the filesystem virtual folder;

And a third presentation submodule, configured to place the virtual file of the optional file generated by the generation module in a virtual folder of the corresponding creation source, as a subfile presentation in the virtual folder of the creation source.

With reference to the sixth possible aspect of the second aspect or the seventh possible aspect of the second aspect or the ninth possible implementation of the eighth possible aspect or the second aspect, in a tenth possible implementation manner, The optional file that can be obtained by the second application in the filesystem includes: a file whose creation source includes the source of the second application, and a file whose source of authorization includes the source of the second application.

In the embodiment of the present invention, the path of the file saved by the application of different sources may be provided to the browser in the file system filesystem based on the sandbox mechanism, thereby realizing the cross-source file acquisition.

DRAWINGS In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention. One of ordinary skill in the art can also obtain other drawings based on these drawings without undue creative effort.

FIG. 1 is a flowchart of a method for acquiring a file according to an embodiment of the present invention;

2 is a flowchart of a method for obtaining a file according to another embodiment of the present invention;

3 is a flowchart of a method for obtaining a file according to another embodiment of the present invention;

FIG. 4 is a flowchart of a method for acquiring a file in an application scenario according to an embodiment of the present invention; FIG. 5 is a flowchart of another embodiment of a method for acquiring a file in an application scenario;

FIG. 6 is a schematic diagram of an interface of a virtual folder of a virtual thread according to an embodiment of the present invention; FIG. 7 is a schematic diagram of a display interface of a virtual folder for creating a source according to an embodiment of the present invention; FIG. 8 is a schematic diagram of providing a virtual file according to an embodiment of the present invention; Interface diagram;

FIG. 9 is a schematic structural diagram of an apparatus for acquiring a file according to an embodiment of the present invention; FIG. 10 is a schematic structural diagram of an apparatus for acquiring a file according to another embodiment of the present invention; FIG. 12 is a schematic structural diagram of a device for acquiring a file according to an embodiment of the present invention; FIG. 13 is a schematic diagram of a hardware structure of an apparatus for acquiring a file according to an embodiment of the present invention.

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. example. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

The source in the embodiment of the present invention includes a rule part in the Uniform Resource Locator URL of the application, Host part and port part.

FIG. 1 is a flowchart of a method for acquiring a file according to an embodiment of the present invention. The method can be applied to a file system filesystem based on a sandbox sandbox mechanism. As shown in the figure, the method for obtaining a file in this embodiment includes:

S100. The browser receives a file save request initiated by the first application through the first file system application programming interface filesystem API provided by the browser.

The first application is an application running in a browser, such as a web application.

The first file system application programming interface filesystem API can include at least one filesystem API. Specifically, the first application can initiate a file save request by calling the getFile API and the Write API in the filesystem API. Among them, getFi le is used to get the file entry, Write is used to write the data to be saved to the file. That is, the first application first obtains the filesystem file, and then writes the data to be saved in the file. Obtaining a file can be:

getFi le ( "DOMString path" , {create: true} );

Where "DOMString path" is the file path. In filesystem, the application saved by the originating file specifies the path to save the file and uses that path as the file identifier to uniquely identify the file. For example, getFile ( "/BenPicture/Ben. jpg", {create: true} ); where " /BenPicture/Ben. jpg " can be considered as the identifier of the file, which can be obtained by "/BenPicture/Ben. jpg" The entry to the file to save. {create: true} means that if the file does not exist, it is created.

It should be noted that different applications can apply for their own filesystem space in filesystem. Therefore, when the first application initiates the file save request, the reques tFi leSystem API in the filesystem API may be invoked to instruct the browser to allocate a file system storage space of a certain size for saving the file of the first application.

Because the application has applied for its own filesystem space, there may be different filesystems for the same source. But each time the application requests a filesystem space through reques tf i lesys tern, the browser will return a unique object to the requested application, for unique identifiers. Know each filesystem, when the application saves the file, you can also carry the fi 1 esyst em identifier in the save request. S102. Save the file to be saved by the first application to the file system filesystem according to the file save request.

Specifically, the browser finds the file specified by "DOMString path" in the getFile in the filesystem, and writes the data to be saved by the first application into the file, and the file after the data is written is the file saved by the first application. . If the file specified by "DOMString path" does not exist in filesystem, create the file and write the data to be saved to the file.

S104. Receive an instruction for acquiring the file triggered by a second application that is different from the first application, where the instruction carries a path of the file.

The second application is an application that runs in a browser. The source of the second application is known by the URL of the second application.

In the case that each application has its own filesystem space, the instruction may also carry the identifier.

S106. Obtain a path of the file, and obtain the file from the filesystem according to the path of the file, and provide the file to a second application.

Specifically, the browser can obtain the path of the file from the received instruction.

Optionally, when the filesystem identifier is carried in the instruction, the browser obtains the file from the filesystem specified by the filesystem identifier.

In the above embodiment, the path of the file saved by the application of different sources may be provided to the browser in the file system filesystem based on the sandbox mechanism, thereby realizing the cross-source file acquisition.

In the embodiment of the present invention, when the second application acquires the file saved by the first application in the filesystem, the browser can be notified in the following two ways:

Method 1: The second application may invoke a second filesystem API provided by the browser to instruct the browser to obtain the file from the filesystem of the first application, and specify the path of the file to be obtained when the filesystem API is called.

Method 2: The second application can invoke a file API provided by the browser to initiate a file acquisition request. For example, <1叩1^ type="file">, the file obtaining request instructs the browser to provide a file selection interface to the user, so that the user selects a file to be provided to the second application in the file selection interface.

It should be noted that regardless of which of the above methods is used, it is triggered by the second application. In an embodiment of the present invention, the instruction for acquiring the file triggered by the second application that is different from the first application in the step 104 may include: receiving the second application to invoke the browser. The second filesystem API is to obtain a call instruction of the file saved by the first application. The path information provided by the second application to the browser may be sent by the first application to the second application after saving the file. The specific processing flow can be seen in Figure 2.

FIG. 2 is a flowchart of a method for instructing a browser to acquire a file, as shown in FIG. 2, the method includes:

S200. The browser receives a file save request initiated by the first application through the first file system application programming interface filesystem API provided by the browser.

S202. Save the file to be saved by the first application to the file system filesystem according to the file save request.

For the specific implementation of the steps S200-S202, reference may be made to the embodiment shown in FIG. 1, and details are not described herein again.

S204: After the first application saves the file, the browser receives the path of the file sent by the first application to the second application, and forwards the path of the file to the second application, so that the second application initiates according to the path of the file. Call the instruction.

Specifically, the first application may send the storage information of the file to the second application by using the cross-document communication message postMessage, and instruct the second application to obtain the file from the filesystem.

The message format of postMessage is as follows:

postMessage ( "f ilesystemRetrieve: DOMString path" , "second application URL");

Where "f ilesystemRetrieve: DOMString path" is the message content field, f ilesystemRetrieve means ":" after the "DOMString path" indicates that the file is to be fetched from filesystem; after the colon "DOMString path" is the file in fi lesys tem The save path, which can be used as an identifier for the file, is used to uniquely identify and locate the file in the filesystem; "The URL of the second application" is the message destination field.

Of course, other methods, such as setting ilesystemRetrieve as a field, to obtain files from filesystem, and "DOMString path" in the message content field, the format is as follows:

postMessage ( " DOMString path " , " URL of the second application,, , "f ilesystemRetrieve" );

Optionally, the first application may further send the storage information of the file to the second application by using a Hypertext Transfer Protocol (HTTP). For example, when the first application is directed to the second application, the "file path" and "f ilesystemRetrieve" identifiers are added to the GET message sent by the first application to the second application, and the specific format is as follows:

GEThttp: 〃 second application URL /? filesystemRetrieve = "DOMString path" head;

Where filesystemRetrieve indicates that "="DOMString path" represents the file to be retrieved from filesystem; "DOMString path" after the equal sign is the file save path in filesystem; "second application URL" indicates orientation to second application.

S206. Receive a second application that invokes a second filesystem API provided by the browser to obtain a call instruction of the file saved by the first application.

After receiving the file storage information sent by the first application, the second application knows that the file needs to be obtained from the filesystem. Therefore, the second function provided by the browser is used to obtain the file, and the file is carried in the calling instruction. path.

The second filesystem API may include at least one filesystem API, and may include a filesystem API in the first filesystem API. For example, the second application may invoke the getfile API and the FileReaderAPI to instruct the browser to obtain the file. Among them, getFile is used to get the file entry, and FileReader is used to read the data from the file found by getFile. The second application carries the path of the file received from the first application in getFile, for example, getFile ("DOMString path").

S208. Obtain a path of the file, and obtain the file from the filesystem according to the path of the file, and send the file to a second application.

The foregoing embodiment sends the path of the file saved by the first application in the file system to the second application by extending the interaction message between the first application and the second application, so that the second application can obtain the first application by using the path. Files in filesystem for cross-source access.

Optionally, in order to increase the security in the process of the cross-source access, the embodiment of the present invention may further allow the first application to specify the authorization source, and the other source may obtain the saved by the first application only in the authorization source specified by the first application. file.

Specifically, before the step S206, the method further includes: recording a creation source of the file, where the creation source is a source of the first application that saves the file, and receiving an authorization source of the file specified by the first application, where The authorization source is a source that is authorized to obtain the file; an authorization source of the file is recorded, and an authorization source of the file includes a source of the second application.

The browser can extend the following filesystem API to enable the first application to specify 4 authorized sources through the following filesystem API, such as:

a. The browser can extend the getFile API so that the first application can specify the authorization source in the file save request of S202 using the API provided by the browser. Such as:

Void getFile (DOMString path, {create: true} , optional DOMString Pemissions);

Among them, "DOMString path" is a file path, which is used to uniquely identify the file in filesystem, and "DOMString Pemiss ions" is a new field, indicating 4 authorized sources. For example: getFile ( "/BenPicture/Ben. jpg", {create: ture} , "*. drawing, com" ), then the picture /BenPicture/Ben. jpg can be obtained from the source of *. drawing, com.

b. The browser can extend the requestFileSystem API, so that the first application uses the API provided by the browser to specify the authorization source when obtaining the filesystem space. All files in the ilesystem space take effect. mouth:

Void reques tFi leSys tern (..., optional DOMString Pemissions); where "DOMString Pemissions" is a new field that represents the authorization source.

The c browser can extend a new API so that the first application uses the browser to provide this new API to specify the file authorization source. Such as:

createFilePermissions (DOMString path, DOMString Pemissions); where createFilePermissions is the new API, "DOMString path" is the file path, which is used to uniquely identify the files in the fleetsystem, and "DOMString Pemissions" is the authorization source.

It should be noted that one or more authorization sources can be specified, and the browser can create a relationship table to record the relationship between the file and the creation source and the authorization source, as shown in Table 1:

Table 1

Optionally, the obtaining, according to the path of the file, the file is obtained from the file system of the first application, and the providing the file to the second application may include: searching for the file in the filesyetem according to the path of the file. After finding the file, matching the source of the second application with the creation source of the file and the authorization source, and providing the file when determining that the source of the second application is the authorization source of the file Give the second application.

The browser may first determine whether the source of the request (ie, the source of the second application) is the same as the source of the creation. If the source is different, and then determine whether the source is the authorized source, the two may simultaneously determine the specific judgment sequence. The embodiment of the invention is not limited.

Optionally, when you specify an authorization source, you can further specify the authority of the authorization source. Specifically, the field "DOMString Pemissions" for specifying the authorization source can be expressed as "permission: authorization source". Among them, the permissions can be: Access: can operate files, such as uploading servers, modifying, etc.

Read: can only read files;

Take the extended getFile as an example. When specifying the authorization source permission, it can be expressed as getFile ( "/BenPicture/Ben. jpg", "read: *. drawing, com" ); indicating *. drawing, com can get the file /BenPicture/ Ben. jpg, but only the file can be read and cannot be modified.

The embodiment of the present invention increases the security in the cross-source access process by specifying an authorization source for the file so that only the application of the authorization source can obtain the file.

In the embodiment of the second method for instructing the browser to obtain the file, the instruction for acquiring the file triggered by the second application receiving the different source of the first application in step 104 includes: receiving the user in the file selection interface, selecting The instructions of the file. The specific processing flow can be seen in Figure 3.

FIG. 3 is a flowchart of a method for instructing a browser to acquire a file by using the second method, the method includes:

S300. The browser receives a file save request initiated by the first application through the first file system application programming interface filesystem API provided by the browser.

S302. Save the file to be saved by the first application to the file system filesystem according to the file save request.

For the specific implementation of the steps S300-S302, reference may be made to the embodiment shown in FIG. 1, and details are not described herein again.

S304: The browser receives a file acquisition request initiated by the second application by using the file API, where the file acquisition request instructs the browser to obtain the file by using a manner selected by the user;

Specifically, the second application can initiate a file acquisition request by using <input type="file,,> in the file API provided by the browser. Wherein, < input type="fi le,,> indicates that the user input selects the content to be acquired. file.

S306. The browser opens the file selection interface according to the file acquisition request, and displays an optional file in the filesystem in the file selection interface.

After the browser receives <input type= "file" >, the file in filesystem is displayed in the file selection interface for the user to select.

It should be noted that in addition to the optional files in the fi lesys tem, the file selection interface is displayed. In addition, you can also display other system disks, such as C drive, D drive files.

S308. Receive an instruction that the user selects a file saved by the first application in the file selection interface. The user can select a file in the file selection interface by clicking and the like. When the user selects the file saved by the first application, the browser can receive the selected instruction triggered by the operation, and indicate by the path carrying the file in the instruction. The file the user wants to select.

S310. Obtain a path of the file, and obtain the file from the f i 1 e s y s t em according to the path of the file, and send the file to a second application.

In some filesystems that use large file storage methods, the files are only visible to the browser. The files that the user sees through the file selection interface are not in a single file format, so the user cannot select files through the file selection interface.

Therefore, in another embodiment of the present invention, the browser can present the files in the filesystem to the user selection in the form of virtual files. Specifically, the displaying the optional file in the filesystem in the file selection interface in the step 306 includes: the browser determining an optional file in the filesystem that can be obtained by the second application, and generating an associated virtual file for each optional file, Taking the path of the optional file as information associated with the virtual file, and presenting the generated virtual file in a file selection interface, so that the user selects a file associated with the virtual file through the virtual file. The browser attaches the path of the file to the virtual file when the virtual file is generated, to associate the virtual file with the corresponding optional file.

In the embodiment of the present invention, a virtual file is generated for each optional file and displayed to the user, so that the user selects a virtual file to be associated with a separate single file, thereby implementing the user in the filesystem of the large file storage mode. Select cross-source access for file mode.

It should be noted that in a system with low security requirements, an optional file that can be obtained by the second application in the filesystem may be all files in the filesystem.

Optionally, in order to increase security during cross-origin access, you can also control access to files in filesystem. The first application may be allowed to specify an authorization source, and other sources may acquire the file saved by the first application only in the authorization source specified by the first application. Filesystem The optional file obtained by the second application may only include files that are authorized to be obtained. Specifically, before S304, the method further includes: recording a creation source of the file, where the creation source is a source of the first application that saves the file; and receiving an authorization source of the file specified by the first application, where The authorization source is a source that is authorized to obtain the file; an authorization source of the file is recorded, and an authorization source of the file includes a source of the second application. For the manner in which the first application specifies the authorization source, refer to the embodiment shown in FIG. 2. The manner in which the browser records the creation source and the authorization source may also refer to Table 1 in the embodiment shown in FIG. 2, and details are not described herein again.

Correspondingly, the browser determines that the optional file that can be obtained by the second application in the filesystem comprises: a file that creates a source including the source of the second application, and a file whose source of authorization includes the source of the second application is determined as An optional file in the filesystem that can be obtained by the second application.

In order to improve the operability of the file selection interface, the embodiment of the present invention can also perform hierarchical presentation in the file selection interface. Specifically, before the optional file is displayed in the file selection interface, the method further includes: generating a filesystem virtual folder, and displaying the virtual thread virtual folder as a system disk in the file selection interface, and receiving the filesystem virtual The operation of presenting the optional file in the file selection interface is performed after the operation of the folder.

For example, the browser can display the filesystem virtual folder as a system disk together with the C disk, the D disk, and the like. When detecting the operation of the user clicking the filesystem virtual folder, the executable file that can be obtained by the second application in the filesystem is determined. And generate a corresponding virtual file, and the generated virtual file is displayed as a subfile in the fi 1 esyst em virtual folder.

In order to further improve the operability of the file selection interface, the embodiment of the present invention can not only display the filesystem virtual folder layer, but also display multiple layers such as creating a source layer and creating a source host layer. For example, when the display source layer is determined, the browser further includes: determining the creation source of the optional file, and respectively generating the virtual folder of each creation source. The displaying the generated virtual file in the file selection interface specifically includes: creating a virtual folder of the source as a subfolder in the filesystem virtual folder, and placing the virtual file of the optional file in the virtual of the corresponding creation source. In the folder, as a subfile of the creation source virtual folder. Need to say It is to be noted that, in this embodiment, the creation source corresponding to the file needs to be recorded in advance, and specifically, the creation source of the file may be recorded when the browser saves the file in step 302.

The solution of the embodiment of the present invention will be further described in conjunction with the specific application scenarios in FIG. 4 and FIG. 4 The application scenario is as follows: The user takes a photo on the photo website hUp: 〃丽 w. paizhao. com/ uses the camera application, wants to use the professional website for processing photos hup: //www. drawing, drawing application in com/ To post-process this photo. The first application is camera, the source is http: //www. paizhao.com/, the second application is drawing, and the source is http: //www. drawing.com/.

FIG. 4 is a flowchart of a method for instructing a browser to acquire a file in an application scenario. As shown in FIG. 4, the method includes:

S400, the camera application running in the browser uses a file save request initiated by the first filesystem API provided by the browser, and specifies an authorization source in the file save request.

Specifically, the browser runs the camera application, and uses the camera function of the camera application to realize the photographing. For example, the camera application can call the following API provided by the browser: <input type="f ile" accept=" image/*" capture=" Camera")^ instructs the browser to call the lower operating system interface and communicate with hardware (eg, camera) to implement the camera function.

When the user clicks on the save function, the camera application calls the following filesystem API provided by the browser: f s. getFi le ( "/ camera /Mike' s head, jpg" , {create: ture} , " *. drawing, com" Initiating a file save request to the browser, where "/camera/Mike's head, jpg" is the save path specified for the camera application, and as an identifier that uniquely identifies the file, "*. drawing, com" is the 4 authorized source , "*" is a wildcard that can represent one or more characters. Fs is the identifier of the camera application f i lesys tem.

S402. The browser saves the file to be saved by the camera application to the file system according to the file save request, and records the creation source and the authorized source of the file.

The camera application can first apply for the filesystem space in the fi lesys by reques tf i lesys, in order to save the file to be saved to its own filesystem. In this embodiment, the browser obtains a file in the camera's system based on "/camera/Mike's head, jpg". If there is no such file, the file is created in the camera's fi lesys, and the photo data is saved. Go to the file obtained.

S404-S406, the camera application sends a request to the browser to the drawing application, and sends the file save path to the drawing application through the browser.

Specifically, the user can click the "to draw application to edit" button displayed on the camera application page, that is, initiate a request directed to the drawing application, and carry the file path of the saved photo in the request. For example: GET http: //www. drawing. com/?fi lesys temRetr ieve=fi lesys temname: / earner a/Mike's head, where "www. drawing, com" is the host address of the drawing application, "fi lesys temRetr ieve "Instructs to get the file from fi lesystem, fi lesys tmename is the object name of fi lesys tem, and only specifies a fi lesys tem space.

"/camera/Mike's head" is the path to the file in the fleetsystem. The browser opens an if rame or tab or a new window based on the request, loads the page of the www. drawing, com website, and passes the path of the saved photo to the drawing application on the page.

This embodiment is described by taking an example from the camera application orientation to the drawing application. In another embodiment, instead of using the camera application orientation to the drawing application mode, the drawing application is opened by the user himself. After the browser runs the drawing application, the camera application sends the file path to the drawing application via the cross-document communication message postMessage, and instructs the drawing application to retrieve the file data from the user's local filesystem. For example: postMessage ( " f ilesystemRetrieve=f ilesystemname: /camera/Mike ' s head" , "hup: //www. drawing, com" ).

S408, the drawing application determines, according to the received file path, that the file is obtained from the filesystem, and then calls the filesystem API provided by the browser to obtain the file saved by the camera application, and uses the file path obtained from the camera application as the called API. parameter.

The drawing application calls the filesystem API to send a call instruction to the browser. For example: fi lesys temname. getFi le ( "/ camera /Mike' s head, jpg" ).

S410, the browser determines whether the request source is a file creation source or an authorization source. If the source or the authorization source is created, executing S412 to provide the file to the drawing application; if neither the creation source nor the authorization source, executing S414, returning Get the failure response.

The request source is the source corresponding to the application requesting to obtain the file. The browser finds the pre-recorded creation source and the 4 authorized source according to the file path "/camera /Mike' s head, jpg" in the file system space specified by fi lesys temname, and determines that the file is created with the source "http: //www . paizhao. com/" , the authorized source is drawing. com, '. The source of the drawing application requesting the file is "hup: //www. drawing.com〃", and therefore, step S412 is performed.

FIG. 5 is a flowchart of a method for instructing a browser to acquire a file in the application scenario. As shown in FIG. 5, the method includes:

S500, the camera application running in the browser sends a file save request initiated by the first filesystem API provided by the browser, and specifies an authorization source in the file save request.

For details, refer to step S400 in Figure 4, and details are not described herein.

S502. The browser saves the file to be saved by the camera application to the file system according to the file save request, and records the creation source and the authorized source of the file.

S504. The drawing application invokes a file API provided by the browser to initiate a file acquisition request. For example, when the user clicks the "Upload File" button in the drawing application, the drawing application requests the browser to provide a file that can be browsed by the user through <input type= "file" >, and determines the file to be processed according to the input of the application page. The input here is not only a keyboard typing input, but a generalized concept, which can be a user input method such as clicking a file.

S506. The browser opens the file selection interface according to the file obtaining request, and generates a filesystem virtual folder, and displays the virtual thread virtual folder as a system disk in the file selection interface. Figure 6 is a schematic diagram of a display interface of a filesystem virtual folder, wherein the "web source" folder is a filesystem virtual folder,

S508. The browser receives an operation of selecting a filesystem virtual folder in a file selection interface.

After the user clicks the filesystem virtual folder in the file selection interface, the browser receives the user's selection operation.

S510-516, the browser determines an optional file in the filesystem that can be obtained by the second application, and a creation source of the optional file, and generates a creation source folder and a virtual file associated with the optional file, and the virtual file of the source is created. The folder is a subfolder in the filesystem virtual folder, and the virtual file of the optional file is placed in the virtual folder of the corresponding creation source, and is displayed as a subfile of the creation source virtual folder.

The browser can determine the optional file that can be obtained by the second application and the creation source of the optional file according to the creation source and the authorization source of the pre-recorded file. Specifically, the browser can traverse each file in the filesyste to determine whether the source of the drawing application is in the creation source or the authorization source of the file, thereby determining the available file and the creation source of the file.

When generating the virtual folder of the creation source, a virtual folder is generated for the same creation source, as shown in FIG. 7, FIG. 7 is a schematic diagram of the display interface of the virtual folder for creating the source.

When the browser generates a virtual file for an optional file, it generates an associated virtual file for each optional file, as shown in Figure 8. Figure 8 is a schematic diagram of the virtual file display interface. The browser may first display the virtual folder of the creation source, and when receiving the operation of selecting the virtual folder of the source, the virtual file is generated and displayed.

S518. Receive an operation of selecting a virtual file corresponding to a file saved by the camera application. When the user selects a virtual file, the operation sends the associated information of the virtual file to the browser. S520: Provide a file corresponding to the virtual file selected by the user to the drawing application. The browser can obtain the corresponding file according to the associated information of the virtual file (ie, the file path). In the embodiment of the present invention, the application can obtain storage information of applications of different sources, for example, The file path overcomes the problem that the files saved by different source applications are invisible to each other in the file system filesystem based on the sandbox mechanism, and the cross-source file acquisition is realized.

FIG. 9 is a schematic diagram showing an exemplary logical structure of an apparatus for acquiring a file according to an embodiment of the present invention. The device is applied to a file system based on the sandbox sandbox mechanism. As shown in FIG. 9, the apparatus includes: an interface unit 901, a request processing unit 902, a saving unit 903, an event processing unit 904, an obtaining unit 905, and a providing unit 906.

The interface unit 901 is configured to provide a first file system application programming interface filesystem API. The first file system application programming interface filesystem API may include at least one filesystem API, such as a getFile API and a Write API.

a request processing unit 902, configured to receive a first application provided by the interface unit 901

― Filesystem API initiated file save request.

The request processing unit 902 can obtain the file entry through the getFile API, and write the data to be saved to the acquired file through the Wr i te API. For specific processing, reference may be made to step S100 of the embodiment shown in FIG. 1, and details are not described herein again.

It should be noted that, if the first application has not been allocated filesystem storage space when initiating the file save request, the first application may also invoke the reques tFi leSystem API in the filesystem API to instruct the browser when initiating the file save request. A file system storage space of a certain size is allocated for storing the file of the first application. The first application may initiate a request to allocate filesystem storage space by request processing unit 902.

The saving unit 903 is configured to save the file to be saved by the first application to the file system f i 1 e s y s t em according to the file saving request received by the request processing unit 902.

Specifically, the saving unit 903 finds the file specified by the "DOMString path" in the getFile in the filesystem, and writes the data to be saved by the first application into the file, and the file after the data is written is saved by the first application. file. If the file specified by "DOMString path" does not exist in the filesystem, create the file and write the data to be saved to the file. The event processing unit 904 is configured to receive an instruction for acquiring a file saved by the first application triggered by a second application that is different from the first application, where the instruction carries a path of the file.

An obtaining unit 905, configured to acquire a path of the file from an instruction received by the event processing unit 904, and obtain the file from the filesystem according to a path of the file; a providing unit 906, configured to: The file acquired by the obtaining unit 905 is provided to the second application.

For specific implementations of the above units, reference may be made to the description of the method embodiments.

In a specific implementation process, the event processing unit 904 can obtain an instruction of the file saved by the first application triggered by the second application received by the following two methods:

Manner 1: Receive an instruction of the second application to obtain the file by calling a second filesystem API. In this manner, the interface unit 901 is further configured to provide a second filesystem API; the event processing unit 904 receives the second application-triggered call instruction for acquiring the file through the second filesystem API provided by the interface unit 901.

Manner 2: The receiving user selects an instruction of the file saved by the first application in the file selection interface. In this manner, the interface unit 901 is further configured to provide a file API; the event processing unit 904 is further configured to receive a file acquisition request initiated by the second application through the file API provided by the interface unit 901, where the file acquisition request indicates that the user selects Way to get the file. The event processing unit 904 opens a file selection interface according to the file acquisition request, and displays an optional file in the filesystem in the file selection interface, so that the user selects the file saved by the first application in the file selection interface.

It should be noted that regardless of which of the above methods is used, it is triggered by the second application. In an embodiment of the present invention, the apparatus for acquiring a file may further include a forwarding unit 1001. As shown in FIG. 10, FIG. 10 is an exemplary embodiment of an apparatus for acquiring a file according to another embodiment of the present invention. Schematic diagram of the logical structure.

The forwarding unit 1001 is configured to receive a path of the file that is sent by the first application to the second application after saving the file, and forward the path of the file to the second application, so that the second The application initiates a call instruction to invoke the second filesystem API according to the path of the file. In a specific implementation, the path of the file may be carried in the cross-document communication message postMessage sent by the first application to the second application, or may be carried in the Hypertext Transfer Protocol (HTTP) message sent by the first application to the second application. For a detailed description, refer to step 204 in the method embodiment.

The interface unit 901 is also used to provide a second filesystem API.

The event processing unit 904 receives the second application-triggered call instruction for acquiring the file through the second filesystem API provided by the interface unit 901.

Optionally, in order to improve the security of the cross-source access, the request processing unit 902 is further configured to receive an authorization source of the file specified by the first application, where the authorization source is a source that is authorized to obtain the file. See the method embodiment section shown in Figure 2 for specific implementation.

The saving unit 903 is further configured to record a creation source of the file and an authorization source of the file, where the creation source is a source of the first application that saves the file, and the authorization source includes the second application. source. For specific recording methods, refer to Table 1 in the method embodiment.

The obtaining unit 905 specifically includes:

The obtaining subunit 1002 is configured to obtain a path of the file from an instruction received by the event processing unit 904;

The finding subunit 1003 is configured to search for the file in the filesystem according to the path obtained by the obtaining subunit 1002.

The authentication subunit 1004 is configured to: after the searching subunit 1003 finds the file, match the source of the second application with the creation source and the authorization source of the file, and determine the source of the second application as the source When the authorization source of the file is described, the notification providing unit 906 sends the file found by the searching module 1003 to the second application.

For a detailed implementation of the above functions, reference may be made to the detailed description of the embodiment of the method shown in FIG. 1, FIG. 2 and FIG.

The above embodiment sends the path of the file saved in the filesystem to the second application, so that the second application can obtain the first application by using the path. Files in filesystem for cross-source access. And by specifying an authorization source for the file, the application can be obtained only by the application of the authorization source, which increases the security in the process of cross-origin access.

In the embodiment of the present invention, the interface unit 901 is further configured to provide a file API. The event processing unit 904 may specifically include a receiving subunit 1101 and an interaction subunit. 1102. As shown in FIG. 11, FIG. 11 is a schematic diagram showing an exemplary logical structure of an apparatus for acquiring a file according to another embodiment of the present invention.

The receiving subunit 1101 is configured to receive a file acquiring request initiated by the file API provided by the second application by the interface unit 901, where the file obtaining request indicates that the file is obtained by using a mode selected by the user;

The interaction sub-unit 1102 is configured to open a file selection interface according to the file acquisition request received by the receiving sub-unit 1101, display an optional file in the filesystem in the file selection interface, and receive the user in the file selection interface, select the first An instruction to apply a saved file.

Optionally, in order to increase security during cross-origin access, you can also control access to files in filesystem. The first application may be allowed to specify an authorization source, and other sources may acquire the file saved by the first application only in the authorization source specified by the first application. Therefore, the request processing unit 902 is further configured to receive an authorization source of the file specified by the first application, where the authorization source is a source that is authorized to obtain the file. The specific implementation can be seen in the method embodiment section shown in Figure 2.

The saving unit 903 is further configured to record a creation source of the file and an authorization source of the file, where the creation source is a source of a first application that saves the file, and the authorization source includes the second application The source used. For specific recording methods, refer to Table 1 in the method embodiment.

Optionally, when the device is used to save the file f i 1 e s y s t em in a large file storage manner, the interaction subunit 1102 may specifically include:

The interface module 11021 is configured to open a file selection interface according to the file obtaining request received by the receiving subunit 1101;

a content module 11022, configured to determine an optional file in the filesystem that is obtainable by the second application;

The generating module 11023 is configured to generate an associated virtual file for each optional file determined by the content module 11022, and use the path of the optional file as information associated with the virtual file, and the presentation module 11024 is configured to generate The virtual file generated by the module 11023 is displayed in a file selection interface opened by the interface module 11021, so that the user selects a file associated with the virtual file through the virtual file;

The event module 11025 is configured to receive an instruction that the user selects a file saved by the first application in the file selection interface.

Optionally, in order to enhance the operability of the file selection interface, the generating module 11023 is further configured to generate a filesystem virtual folder;

The presentation module 11024 is further configured to display the filesystem virtual folder generated by the generating submodule 11023 as a system disk in the file selection interface;

The event module 11025 is further configured to receive an operation of the user selecting the filesystem virtual folder, and after receiving the operation, the presentation module 11024 performs an operation of displaying an optional file in the filesystem in the file selection interface.

Optionally, in order to further enhance the operability of the file selection interface, a multi-level presentation can also be implemented in the file selection interface, for example, a plurality of layers such as a source layer and a source host layer can be displayed. For example, the content creation module 11022 is further used to determine the optional file. Source of creation;

The generating module 11023 is further configured to separately generate a virtual folder of each creation source determined by the content module 11022;

The presentation module 11024 specifically includes:

a first presentation sub-module 110241, configured to display the filesystem virtual folder generated by the generating module 11023 as a system disk in the file selection interface;

a second presentation sub-module 110242, configured to display the virtual folder of the creation source generated by the generation module 11023 as a sub-folder in the virtual folder of the f i 1 e s y s t em;

a third presentation sub-module 110243, configured to place the virtual file of the optional file generated by the generating module 11023 in a virtual folder of a corresponding creation source, as a sub-file in the virtual folder of the creation source Show.

It should be noted that, in the embodiment for implementing the multi-level presentation, the creation source corresponding to the file needs to be recorded in advance, and the storage unit 903 can record the creation source of the file when the file is saved.

For a detailed implementation of the above functions, reference may be made to the detailed description of the embodiment of the method shown in FIG. 1, FIG. 3 and FIG. 5.

The device described in FIG. 9, FIG. 10 and FIG. 11 may be a device including a browser and including a hardware structure required to run the browser, and the device may include a computer, a tablet, and a personal digital assistant (PDA). ), mobile terminal, etc. Figure 12 is a hierarchical structure diagram of the apparatus. The device includes an application 1201, a browser 1202, an operating system 1203, and hardware 1204.

The application 1201 is an application running in the browser 1202, and uses an API opened by the browser 1202 to acquire the open service or device capability of the browser 1202, and provides various services for the user; the application may be web-based, and browsed. To run, it is the product of the browser/server (ie B/S) architecture, and each application has a corresponding URL.

The browser 1202 is configured to communicate with an operating system and obtain an API provided by an operating system. The ability to get the underlying hardware; and provide an environment for the application 1201 running in the browser 1202; operating system: including a hardware driver, communicating with the hardware, receiving and processing input signals generated by the hardware;

Hardware: Can include, for example, a processor, a memory, a communication interface, and the like.

13 is a schematic diagram of a hardware structure in the apparatus. As shown in FIG. 13, the apparatus may include a processor 1301, a memory 1302, a communication interface 1303, and a bus 1304. The processor 1301, the memory 1302, and the communication interface 1303 are communicably connected by a bus 1304.

The processor 1301 can use a general-purpose central processing unit (CPU), a processor, an application specific integrated circuit (ASIC), or one or more integrated circuits for executing related programs, The technical solution provided by the embodiment of the present invention is implemented, wherein the browser can be run in the processor 1301 to implement the functions described in the foregoing method embodiments and device embodiments.

The memory 1302 may be a read only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1302 can store an operating system and other applications. When the technical solution provided by the embodiment of the present invention is implemented by software or firmware, the program code for implementing the technical solution provided by the embodiment of the present invention, such as an application of a browser, is stored in the memory 1302, and is processed by the processor 1301. To execute.

The communication interface 1303 implements the device with other devices or communication networks using, for example, but not limited to, transceivers such as transceivers (such as, but not limited to, Ethernet, Radio Access Network (RAN), Wireless Local Area Network (Wireless Local). Communication between Area Network, WLAN, etc.).

Bus 1304 can include a path for communicating information between various components of the device, such as processor 1301, memory 1302, and communication interface 1303.

It should be noted that although the hardware shown in FIG. 13 only shows the processor 1301, the memory 1302, the communication interface 1303, and the bus 1304, in a specific implementation process, those skilled in the art It should be understood that the device also includes other components necessary to achieve normal operation. At the same time, those skilled in the art will appreciate that hardware devices that implement other functions may also be included, depending on the particular needs.

From the above description of the embodiments, it will be apparent to those skilled in the art that the present invention can be implemented in hardware, or firmware implementation, or a combination thereof. When implemented in software, the functions described above may be stored in or transmitted as one or more instructions or code on a computer readable medium. Computer readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one location to another. A storage medium may be any available media that can be accessed by a computer. By way of example and not limitation, computer readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage media or other magnetic storage device, or can be used for carrying or storing in the form of an instruction or data structure. The desired program code and any other medium that can be accessed by the computer. Also. Any connection may suitably be a computer readable medium. For example, if the software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable , fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwaves are included in the fixing of the associated media. As used in the present invention, a disc (Di sk ) and a disc (di sc ) include a compact disc (CD), a laser disc, a compact disc, a digital versatile disc (DVD), a floppy disc, and a Blu-ray disc, wherein the disc is usually magnetically copied, The disc uses a laser to optically replicate the data. Combinations of the above should also be included within the scope of the computer readable media.

The above is only a specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope of the present invention. It should be covered by the scope of the present invention. Therefore, the scope of the invention should be determined by the scope of the claims.

Claims

Rights request

1. A method of obtaining files, which is characterized in that it is applied to a file system based on the sandbox mechanism. The method includes:

The browser receives a file saving request initiated by the first application through the first file system application programming interface filesytem API provided by the browser;

According to the file saving request, save the file to be saved by the first application into the file system filesystern;

Receive an instruction to obtain the file triggered by a second application that is different from the first application, where the instruction carries the path of the file;

Obtain the path of the file, obtain the file from the filesytem according to the path of the file, and provide the file to the second application.

2. The method according to claim 1, further comprising:

Record the creation source of the file, which is the source of the first application that saves the file; receive the authorization source of the file specified by the first application, and the authorization source is authorized to obtain the file. The source of the file;

The authorization source of the file is recorded, and the authorization source includes the source of the second application.

3. The method according to claim 2, characterized in that: obtaining the file from the file system of the first application according to the path of the file, and providing the file to the second application. include:

Find the file in the fi lesyetem according to the path of the file;

After the file is found, the source of the second application is matched with the creation source and authorization source of the file. When it is determined that the source of the second application is the authorization source of the file, the source of the second application is matched with the creation source and authorization source of the file. The file is provided to the second application.

4. The method according to any one of claims 1 to 3, wherein the receiving an instruction to obtain the file triggered by a second application having a different source than the first application includes:

Receive a calling instruction for the second application to call the second filesystem API provided by the browser to obtain the file.

5. The method according to claim 4, further comprising:

Receive the path of the file sent by the first application to the second application after saving the file;

Forward the path of the file to the second application, so that the second application initiates the calling instruction according to the path of the file.

6. The method according to claim 5, characterized in that, the path of the file is carried in the cross-document communication message postMessage sent by the first application to the second application, or, is carried in the cross-document communication message postMessage sent by the first application to the second application. In a Hypertext Transfer Protocol HTTP message sent by the second application.

7. The method according to claim 2, further comprising:

The browser receives the file acquisition request initiated by the second application through the file API, and the file acquisition request instructs the browser to obtain the file in the method selected by the user;

The browser opens the file selection interface according to the file acquisition request, and displays the optional files in the filesystem in the file selection interface;

The receiving an instruction to obtain the file triggered by a second application that is different from the first application includes: receiving an instruction from the user to select the file in the file selection interface.

8. The method according to claim 7, wherein displaying the optional files in the filesystem in the file selection interface includes:

The browser determines optional files in the filesystem that can be obtained by the second application, for each The optional file generates an associated virtual file, uses the path of the optional file as the information associated with the virtual file, and displays the generated virtual file in the file selection interface so that the user can Virtual File to select the file associated with the virtual file.

9. The method according to claim 7 or 8, characterized in that, before displaying the optional files in filesystem in the file selection interface, it further includes: generating a filesystem virtual folder, and virtualizing the filesystem The folder is displayed in the file selection interface as a system disk, and the operation of displaying the optional files in the file system in the file selection interface is performed after receiving the user's operation of selecting the UI system virtual folder.

10. The method according to claim 9, wherein when the browser determines the optional files in the filesystem that can be obtained by the second application, it further includes: determining the creation source of the optional files, and Generate virtual folders for each creation source respectively;

Displaying the generated virtual file in the file selection interface specifically includes: using the virtual folder of the creation source as a subfolder in the filesystem virtual folder, and rooting the virtual folder of the optional file. The file is placed in the virtual folder of the corresponding creation source and displayed as a sub-file in the virtual folder of the creation source.

11. The method according to any one of claims 7-10, wherein the browser determines that the optional files in the filesystem that can be obtained by the second application specifically include:

A file whose creation source includes the source of the second application and a file whose authorization source includes the source of the second application are determined as optional files in the filesystem that can be obtained by the second application.

12. A device for obtaining files, characterized in that it is applied to a file system file system based on the sandbox mechanism, and the device includes:

The interface unit is used to provide a first file system application programming interface filesystem API; the request processing unit is used to receive a file saving request initiated by the first application through the first filesystem API provided by the interface unit;

A saving unit, configured to save the files to be saved by the first application into the file system fi 1 esystem according to the file saving request received by the request processing unit; An event processing unit, configured to receive an instruction to obtain a file saved by the first application triggered by a second application that is different from the first application, where the instruction carries the path of the file;

An acquisition unit, configured to obtain the path of the file from the instruction received by the event processing unit, and obtain the file from the file system according to the path of the file;

A providing unit, configured to provide the file obtained by the obtaining unit to the second application.

13. The device according to claim 12, wherein the request processing unit is further configured to receive an authorization source of the file specified by the first application, and the authorization source is authorized to obtain the file. The source of the file;

The saving unit is also used to record the creation source of the file and the authorization source of the file. The creation source is the source of the first application that saves the file; the authorization source includes the second application. source.

14. The device according to claim 13, characterized in that the acquisition unit specifically includes:

Obtain subunit, used to obtain the path of the file from the instruction received by the event processing unit;

A search subunit is used to search for the file in the f i lesys tem according to the path obtained by the acquisition subunit;

An authentication subunit, configured to match the source of the second application with the creation source and authorization source of the file after the search subunit finds the file, and determine the source of the second application. When it is the authorized source of the file, the providing unit is notified to send the file found by the search module to the second application.

15. The device according to any one of claims 12 to 14, characterized in that the interface unit is also used to provide a second file system API interface;

The event processing unit receives the calling instruction for obtaining the file triggered by the second application through the second filesystem API provided by the interface unit.

16. The device according to claim 15, further comprising: A forwarding unit configured to receive the path of the file sent by the first application to the second application after saving the file; and forward the path of the file to the second application so that the third application The second application initiates the calling instruction according to the path of the file.

17. The device according to claim 16, wherein the path of the file is carried in the cross-document communication message postMessage sent by the first application to the second application, or, is carried in the first application. In a Hypertext Transfer Protocol HTTP message sent by the application to the second application.

18. The device according to claim 13, characterized in that the interface unit is also used to provide file API;

The event processing unit specifically includes:

A receiving subunit, configured to receive a file acquisition request initiated by the second application through the file API provided by the interface unit, where the file acquisition request indicates that the file is acquired in a manner selected by the user;

The interactive subunit is configured to open a file selection interface according to the file acquisition request received by the receiving subunit, display the optional files in the filesytem in the file selection interface, and receive the user's request in the file selection interface, Instructions for selecting a file saved by the first application.

19. The device according to claim 18, characterized in that the interactive subunit specifically includes:

Interface module, used to open the file selection interface according to the file acquisition request received by the receiving subunit;

The content module is used to determine the optional files in the filesytem that can be obtained by the second application; the generation module is used to generate an associated virtual file for each optional file determined by the content module. The path to the file as information associated with said virtual file,

A presentation module, configured to present the virtual file generated by the generation module in the file selection interface opened by the interface module, so that the user can select the file associated with the virtual file through the virtual file;

An event module, configured to receive the user's selection of the first application in the file selection interface. Instructions for saving files.

20. The device according to claim 19 or 19, characterized in that the generation module is also used to generate a filesystem virtual folder;

The presentation module is also configured to present the filesystem virtual folder generated by the generation sub-module as a system disk in the file selection interface;

The event module is also configured to receive an operation of the user selecting the filesystem virtual folder, and after receiving the operation, instruct the presentation module to perform the process of presenting optional files in the filesystem in the file selection interface. operate.

21. The device according to claim 20, wherein the content module is also used to determine the creation source of the optional file;

The generation module is also configured to respectively generate virtual folders for each creation source determined by the content module;

The presentation module specifically includes:

The first display sub-module is used to display the filesystem virtual folder generated by the generation module as a system disk in the file selection interface;

The second display sub-module is used to display the virtual folder of the creation source generated by the generation module as a sub-folder in the filesystem virtual folder;

The third presentation sub-module is used to place the virtual file of the optional file generated by the generation module in the corresponding virtual folder of the creation source, and display it as a sub-file in the virtual folder of the creation source.

22. The device according to any one of claims 19 to 21, wherein the optional files in the filesystem that can be obtained by the second application include: a file whose creation source includes the source of the second application. , and the authorized source includes a file of the source of the second application.