【问题标题】:Posting a canvas blob via AJAX: prevent/delete local cache通过 AJAX 发布画布 blob:防止/删除本地缓存
【发布时间】:2013-08-24 11:13:50
【问题描述】:

我正在使用这样的方法通过 AJAX 将画布图像上传到我的服务器:

myCanvas.toBlob( function( blob ) {
    var fdata = new FormData( );
    fdata.append( 'myFile', blob );
    $.ajax( {
        url: 'http://myScript.foo',
        type: 'POST',
        data: fdata,
        processData: false,
        contentType: false
    } );
}, 'image/jpeg', 0.9 );

(感谢https://stackoverflow.com/a/8244082/1180785

但根据 Mozilla,

toBlob […] 返回代表画布中包含的图像的Blob 对象;这个文件可以缓存在磁盘上,也可以由用户代理决定存储在内存中

(https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement)

对于我的程序来说,不保留图像非常重要(不是作为限制,而是出于隐私考虑)。所以我需要知道是否可以保证删除这个可能的缓存副本,以及何时删除。还有一个潜在的风险是取消删除程序找到它,所以我想知道我是否可以覆盖数据或以其他方式强制安全删除。

如果可以在不冒险使用本地缓存副本的情况下获得相同的结果,那就更好了。如果可能的话,加密也是一种选择。

我只关心现代浏览器,特别支持 getUserMedia,所以没有 IE(我有一个 Flash 后备,用于处理内存中所有内容的旧浏览器)。

【问题讨论】:

    标签: javascript jquery ajax html5-canvas


    【解决方案1】:

    如果隐私和安全很重要,您应该考虑从画布生成data-uri,而不是Blob 对象。

    由于 blob 可能会或可能不会临时存储(缓存)在磁盘上,因此文件将受到安全情况的影响(即您提到的 取消删除)。内存文件/字符串当然可用于内存扫描,但这与从画布获取图像进行传输时接近“安全”一样接近。

    data-uri通常*仅在内存中生成,通常包含 base64 编码图像(如果您的图像在那里非常大仍然存在被分页到磁盘的风险)。

    *) 依赖于实现,例如如果可用内存资源稀缺,移动浏览器更有可能使用临时文件 - 但是,没有记录这种可能的行为。

    要获得data-uri,请改用:

    canvas.toDataURL();
    

    您可以选择指定图像类型(默认为 PNG):

    canvas.toDataURL('image/jpeg'); //optional second parameter is quality [0.0, 1.0]
    

    另一种选择是直接从画布中提取像素并存储在(类型化的)数组中。然后可以按原样传输数据,也可以在发送数据之前使用压缩库压缩为例如 zip。

    但是,这种方法效率最低。

    【讨论】:

    • 这是一种可能性(需要在服务器上进行一些特殊设置,但这没有问题),但是否有更好的保证toDataURL 不会保存到磁盘(与toBlob 相比)?我的印象是它在内部创建了一个文件(不确定是虚拟的还是真实的),然后将字符串设置为该文件的表示形式。我也知道潜在的分页和内存扫描,但无论我如何设置,这都是不可避免的。
    • @Dave 通常文件将在内存中生成,除非它非常大并且没有足够的物理内存(浏览器可用)来生成它。我通常会说,因为这也将取决于实现 - 例如对于移动浏览器,临时磁盘可能更有可能。第三种选择是从画布中检索像素并将其存储为类型化数组并将其发送到服务器(存在用于 JS 的压缩库,但这种方法可能会导致效率问题)。
    • 好的,我认为使用自定义压缩库会有点矫枉过正(特别是因为它仍有可能存储在磁盘上)。很遗憾没有什么可以保证安全,但我认为现在我会选择toDataURL。至少这样,即使它确实存储到磁盘上,也需要有一些专业知识的人才能读取图像(采用 base-64 编码)。谢谢。
    【解决方案2】:

    很可能会删除 blob,

    1. 没有对它的引用(垃圾收集)
    2. 选项卡/窗口已关闭

    在这种情况下,“缓存”并不意味着在很长一段时间内,而是每次访问时都不会重新计算。

    长期缓存内容会浪费存储空间,因为画布是动态设计的。如果是静态内容,则应使用<img>

    我没有看过任何源代码,但这是一个合乎逻辑的结论。在 jQuery 停止引用 blob 之后(发送请求时),它应该被垃圾收集器拾取并丢弃。


    安全删除是非常低级别的,浏览器永远不会允许它。它基本上通过写入硬盘驱动器上的特定地址来工作,这可能会被错误计算并破坏数千个文件(在一个严重碎片化的分区中)。如果他们将其存储到磁盘上,则可以通过计算机取证来恢复。

    【讨论】:

    • 我同意你的猜测,但不幸的是,在处理人们的隐私时,“很可能”还不够强大。
    • 我明白了。我似乎在 Google 上找不到任何东西,因此可能需要查看 Chrome 和 Firefox 源代码。如果您无法理解(我无法理解),请尝试使用包含“blob”的提交询问开发人员。
    • 好吧,我可以在需要时浏览 FireFox 的源代码。我以前从未尝试过 Chrome。这可能很有趣! (我也相信 Opera 仍然是闭源的?)
    • 更新:FireFox 的文件处理代码是一个迷宫!我完全迷失在一个接一个的方法,一个接一个的班级。而且我发誓一定有一些我以前从未见过的预处理器魔法在发生,因为我发现使用的宏在任何地方都找不到定义!
    猜你喜欢
    • 1970-01-01
    • 2018-09-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-12-21
    • 1970-01-01
    • 2016-12-31
    • 1970-01-01
    相关资源
    最近更新 更多