html5教程-利用 HTML5 File API 写的文件存哪了

发布时间:2018-12-18 发布网站:脚本宝典
脚本宝典收集整理的这篇文章主要介绍了html5教程-利用 HTML5 File API 写的文件存哪了脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
小宝典致力于为广大程序猿(媛)提供高品质的代码服务,请大家多多光顾小站,小宝典在此谢过。
HTML5中,加入了File API,允许程序进行类似于本地文件系统的操作。

 

但是在通过DEMO初学的时候,就会产生一个疑问,文件到底存哪了?

 

我们在DEMO程序中设置了文件的创建路径为“LOG.txt”,理论上它会创建在当前的文件目录,但是代码提示创建成功之后,会发现当前目录并没有一个叫log的txt文件。

 

后来想起了Javascript的“沙箱”,什么是沙箱?

 

当javascript运行的时候,有一个隐患,就是打开一个网页之后,javascript可能在计算机上执行一段有害的代码,例如批量删除word文件,或者将这些word的文件发送出去。为了止这种情况发生,javascript被设计为只能在沙箱中运行。沙箱指的是一个受保护的环境,在这个环境中不能访问计算机中的资。浏览器的安全策略定义了脚本能做什么,不能做什么。

 

再来看看官方文档中的一段。

 

Because this API may allow untrusted code to read and wrITe parts of a user's hard drive, there are a number of security and PRivacy issues that must be dealt with. Risks to the user include:

 

Denial of service by filling a local disk or using up IO bandwidth. This can be mitigated in part through quota limitations.

Theft or erasure of private data. This is mitigated by limiting the scoPE of access to the local fileSystem to a chroot-like, origin-specific sandbox.

Storing malicious executables or illegal data on a user's system. This is similar to the risk of any download, and similar security precautions apply, but is potentially worse in that:

It may involve multiple files.

The files may be in a part of the filesystem that's harder for the user to find than the standard downloads directory.

The malicious writes may happen long enough after granting of filesystem access that the user doesn't connect the two events.

This may be mitigated by restricting file creation/rename to non-executable extensions, virtualizing paths [leading to unguessable or non-executable filenames] and by making sure the execute bit is not set on any file created or modified via the API.

As with any other client-side storage, filesystem access allows for cookie-resurrection attacks. UAs will likely wish to present the option of clearing it when the user clears any other origin-specific storage, blocking access to it when cookies are blocked, etc. This is especially important if temporary storage space is permitted by default without explicit user permission.

 

 

这一段的大致意思是,为了确保浏览器所在的计算机安全,浏览器定义了一系列的安全措施,来降低脚本运行的风险,其中就包括沙箱。

 

当我们通过代码调用FILE API的时候,浏览器将在一个安全的环境中建立一个模拟的文件系统,所有的文件读写操作都是在这个安全的环境中进行的。

 

这些生成的文件无法通过javascript代码的控制跑到安全区外面,外面的文件也无法跑进来。

 

有了这些策略之后,程序在使用FILE API的时候就安全多了。

 

我们可以在下面目录找到我们所创建的文件:

 

C:/Users/{username}/AppData/Local/GOOGLE/Chrome/User Data/Default/File System/000/t/00

 

在这个目录中,文件的名字不是我们所指定的名字,而是浏览器生成八位数表示的。

 

第一个生成的文件名为00000000,无后缀名,可以用notepad++等编辑器打开。

 

第二个为00000001,以此类推。

在HTML5中,加入了File API,允许程序进行类似于本地文件系统的操作。

 

但是在通过DEMO初学的时候,就会产生一个疑问,文件到底存哪了?

 

我们在DEMO程序中设置了文件的创建路径为“log.txt”,理论上它会创建在当前的文件目录,但是代码提示创建成功之后,会发现当前目录并没有一个叫log的txt文件。

 

后来想起了Javascript的“沙箱”,什么是沙箱?

 

当javascript运行的时候,有一个隐患,就是打开一个网页之后,javascript可能在计算机上执行一段有害的代码,例如批量删除word文件,或者将这些word的文件发送出去。为了防止这种情况发生,javascript被设计为只能在沙箱中运行。沙箱指的是一个受保护的环境,在这个环境中不能访问计算机中的资源。浏览器的安全策略定义了脚本能做什么,不能做什么。

 

再来看看官方文档中的一段。

 

Because this API may allow untrusted code to read and write parts of a user's hard drive, there are a number of security and privacy issues that must be dealt with. Risks to the user include:

 

Denial of service by filling a local disk or using up IO bandwidth. This can be mitigated in part through quota limitations.

Theft or erasure of private data. This is mitigated by limiting the scope of access to the local filesystem to a chroot-like, origin-specific sandbox.

Storing malicious executables or illegal data on a user's system. This is similar to the risk of any download, and similar security precautions apply, but is potentially worse in that:

It may involve multiple files.

The files may be in a part of the filesystem that's harder for the user to find than the standard downloads directory.

The malicious writes may happen long enough after granting of filesystem access that the user doesn't connect the two events.

This may be mitigated by restricting file creation/rename to non-executable extensions, virtualizing paths [leading to unguessable or non-executable filenames] and by making sure the execute bit is not set on any file created or modified via the API.

As with any other client-side storage, filesystem access allows for cookie-resurrection attacks. UAs will likely wish to present the option of clearing it when the user clears any other origin-specific storage, blocking access to it when cookies are blocked, etc. This is especially important if temporary storage space is permitted by default without explicit user permission.

 

 

这一段的大致意思是,为了确保浏览器所在的计算机安全,浏览器定义了一系列的安全措施,来降低脚本运行的风险,其中就包括沙箱。

 

当我们通过代码调用FILE API的时候,浏览器将在一个安全的环境中建立一个模拟的文件系统,所有的文件读写操作都是在这个安全的环境中进行的。

 

这些生成的文件无法通过javascript代码的控制跑到安全区外面,外面的文件也无法跑进来。

 

有了这些策略之后,程序在使用FILE API的时候就安全多了。

 

我们可以在下面目录找到我们所创建的文件:

 

C:/Users/{username}/AppData/Local/Google/Chrome/User Data/Default/File System/000/t/00

 

在这个目录中,文件的名字不是我们所指定的名字,而是浏览器生成八位数表示的。

 

第一个生成的文件名为00000000,无后缀名,可以用notepad++等编辑器打开。

 

第二个为00000001,以此类推。

觉得可用,就经常来吧! 脚本宝典 欢迎评论哦! html5教程,巧夺天工,精雕玉琢。小宝典献丑了!

脚本宝典总结

以上是脚本宝典为你收集整理的html5教程-利用 HTML5 File API 写的文件存哪了全部内容,希望文章能够帮你解决html5教程-利用 HTML5 File API 写的文件存哪了所遇到的问题。

如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。