Gecko/WebKit 中的多次上传:允许在上传之前从列表中删除

发布于 2024-09-06 18:10:56 字数 575 浏览 3 评论 0原文

我正在尝试在元素上使用新的 multiple="multiple" 属性。到目前为止,最新的 Gecko 和 WebKit 浏览器都支持这一点。我正在 Firefox 3.6 和 Chrome 5.0 上进行测试。

我可以很好地使用它,并显示文件列表(我使用 作为指导)。然而,令人沮丧的是,用户似乎无法在添加文件后从该列表中删除文件。唯一的方法是单击“浏览...”按钮并选择一组新文件。

这是因为 元素提供的 FileList 对象是只读的,如规范中所述(无法链接 - 请参阅 W3C 网站上的 FileAPI TR)。

当然有解决方法,例如保留“已删除”项目的列表,无论如何上传所有内容,然后忽略“已删除”项目。这有点脏,如果“删除”大量文件,上传速度可能会慢得令人无法接受。

有谁知道任何其他解决方法,或者有更好的想法如何处理这个问题?目的是能够使用“多个”属性,并允许用户在上传之前从列表中删除文件。

I'm trying to use the new multiple="multiple" attribute allowable on elements. So far this is supported by recent Gecko and WebKit browsers. I'm testing on Firefox 3.6 and Chrome 5.0.

I'm able to use it fine, and display the list of files (I used this as guidance). Rather frustratingly, however, it seems like it's impossible for the user to remove files from this list after they've been added. The only way is to click the "Browse..." button and choose a new set of files.

This is because the FileList object provided by the <input> element is readonly, as mentioned in the spec (can't link - see the FileAPI TR over at the W3C's website).

There are of course workaround, like keeping a list of the "removed" items, uploading everything anyway and then ignoring the "removed" items. This is a bit dirty and could make uploading unacceptably slow if lots of files are "removed".

Does anyone know of any other workarounds, or have any better ideas how to deal with this? The aim is to be able to use the "multiple" attribute, and allow users to remove files from the list prior to uploading.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

路弥 2024-09-13 18:10:56

我从 File API 的编辑 Arun Ranganathan 那里得到了答案:

程序员(使用文件 API
以编程方式操纵用户的
文件选择)不能违反
用户的决定。所以 API 不
允许程序员添加一个
文件到用户的选择或
从用户的选择中删除文件。如果我们允许这样的话,这
将是一个巨大的安全漏洞。坏的
网站可能会做得非常糟糕
事情或至少非常烦人
事物。这就是为什么当前
范式不允许任何
与底层文件的交互
未经用户批准的系统
至少通过文件对话框
(当前产生输入
类型=“文件”)。

我同意文件列表应该反映用户最初在文件选择器中选择的内容,并且能够将内容添加到文件列表将是一个巨大的安全漏洞。我不认为删除某些东西会导致如此巨大的安全问题,但我可以看到它如何被用于不那么积极的目的。

I got an answer from Arun Ranganathan, the editor of the File API:

The programmer (using the File API to
programmatically manipulate user's
file selection) cannot contravene a
user's decision. So the API does NOT
allow the programmer to either add a
file
to the user's selections or
delete a file from the user's selection. If we allowed this, this
would be a gaping security hole. Bad
Web Sites might be able to do Very Bad
Things or at least Very Annoying
Things. This is why the current
paradigm does NOT allow any
interaction with the underlying file
system that is NOT user approved at
least via the File dialog box
(currently spawned with input
type="file").

I agree that the FileList should reflect what the user initially selected in the file picker and that being able to add things to the FileList would be a huge security hole. I can't see that being able to remove things would cause such huge security issues, but I can see how it could be used for less than positive purposes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文