从 file:// URI 绘制图像后 Canvas getImageData() - 需要针对所有浏览器的解决方法
我是 Construct 2 的开发人员，这是一款适用于 Windows 的 HTML5 游戏编辑器。它位于 http://www.scirra.com。
最近，我一直在尝试添加一项功能，通过在画布上转换图像来修改图像。这非常简单 - 将图像绘制到画布上并调用 getImageData() 来获取像素。
当用户在我们的应用程序中单击“预览”时，所有文件都将转储到磁盘上的临时文件中，并启动浏览器来显示它。上传到服务器不是预览的选项 - 有些游戏有兆字节大。
然而，大多数浏览器会阻止您使用 getImageData() 来获取从磁盘加载的任何图像的像素。我尝试将所有必要的图像文件放入子目录中，正如 MDN 在其 文件描述中建议的那样： // 访问策略。那也不行！
Chrome 的 --allow-file-access-from-files 标志修复了这个问题。但是，我需要支持所有主要浏览器。至少对于 Internet Explorer 和 Firefox 是否有类似的解决方法？我对 Internet Explorer 一无所知，我真的希望有一些东西不需要手动转到 Firefox 中的 about:config，否则我们将被淹没在询问“为什么它在 Firefox 中不起作用？！”的支持请求中。
另外，为什么这个安全策略是必要的？！？这看起来有点夸张，使得像我们这样的应用程序真的很难编写。
任何帮助表示赞赏。
I'm developer of Construct 2, a HTML5 game editor for Windows. It's at http://www.scirra.com.
Recently I've been trying to add a feature that will modify an image by transforming it on a canvas. It's pretty straightforward - draw an Image to the canvas and call getImageData() to get the pixels.
When the user clicks 'preview' in our application, all the files are dumped to a temp file on disk and a browser launched to show it. Uploading to a server is not an option for previewing - some games are megabytes big.
However most browsers block you using getImageData() to get the pixels of any image loaded from disk at all. I've tried putting all the necessary image files in subdirectories as MDN suggests in its description of file:// access policies. That doesn't work either!
Chrome's --allow-file-access-from-files flag fixes it. However, I need to support all major browsers. Is there a similar workaround for at least Internet Explorer and Firefox? I have no idea about Internet Explorer, and I really wish there's something which doesn't involve manually going to about:config in Firefox, otherwise we will be deluged in support requests asking "why doesn't it work in Firefox?!".
Also, why on earth is this security policy necessary?!? It seems way over the top and makes applications like ours really difficult to write.
Any help appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你的名字在 HN 听起来很熟悉。
尽管这让很多人感到不安，但现在规范中已经明确规定了这一点。
http://和file://是不同的源，任何试图将一个源放在另一个源上的行为都会弄脏源。正如您所指出的，文件 uri 本身有自己的一套规则，这使得事情变得更加棘手。在起源不同的画布上绘制一些东西？太糟糕了，从今以后，origin-clean 标志是错误的，这将不允许你做各种事情。
这些内容的完整列表位于规范 这里。
但我相信你现在已经知道这一切了。你想绕过它。
我建议 ins 不要试图强行控制浏览器，而是捆绑某种轻量级 Web 服务，以便所有内容都来自同一来源。将来引起的头痛会少很多。
您可能需要类似 Python SimpleHTTPServer。但这个决定实际上取决于您此时已经包含在产品中的内容。
Your name sounds familiar from HN.
This is pretty laid out in stone in the spec by now, though this upsets an awful lot of people.
http://andfile://are different origins, and anything that tries to put one on the other will dirty the origin. As you noted file uri's themselves have their own set of rules that make things even trickier.Drawing something to a canvas whose origin is not the same? Too bad, the origin-clean flag henceforth is false, which then disallows you from doing various things.
A complete list of those things is located in the spec here.
But I'm sure you know all this by now. You want to get around it.
I'd suggest ins instead of trying to strong-arm the browsers around it, you bundle in some kind of lightweight web service so that things are all appearing from the same origin. It will cause a lot fewer headaches in the future.
You'll probably want something like the Python SimpleHTTPServer. But that decision really depends on what you've already got included in your product already at this point.