【问题标题】:"Aw, Snap" when data uri is too large当数据 uri 太大时,“Aw, Snap”
【发布时间】:2013-05-26 17:37:13
【问题描述】:

我正在编写一个 chrome 扩展,它执行以下操作:

  1. 使用XMLHttpRequest将文件从网站下载到内存
  2. 将附加数据添加到文件中,然后将结果base64编码到变量total_encoded_data
  3. 使用<a href=data:application/octet-stream;charset=utf-8;base64,' + total_encoded_data+' download='file.bin'>Click to Download</a> 向用户提供数据。使用 jQuery 将 total_encoded_data 添加到 href 的位置。

我通过手动二进制搜索发现,如果total_encoded_data 的大小大于 2097100 个字符,那么当我单击链接时,我会收到一条 Aw, Snap 消息。如果尺寸较小,那么我可以按预期下载。

除了测试文件大小,我还使用atoi来保证base64编码是有效的,并且运行无误。

Aw, Snap 消息不会在 chrome://crashes 中生成任何崩溃报告,也不会在 chrome_debug.log 中生成任何意外输出

在提供 base64 编码字符串长度大于 2097100 的数据 uri 时,如何避免 Aw、Snap 消息?

【问题讨论】:

    标签: javascript google-chrome-extension data-uri


    【解决方案1】:

    这是一个known chromium bug。推荐的解决方法是使用blob URL。另见Creating a Blob from a base64 string in JavaScript

    【讨论】:

    • 3.5 年后...仍未修复。该死的,Chrome。
    • 差不多 7 年后...用 blob url 技巧解决了同样的老问题!
    • 如果有人想知道,最大大小是基于 2MB 字节... 2 * 1024 * 1024 字节。
    • 老实说,伙计们,这太荒谬了,快到 2018 年了,但仍然存在……我知道我为什么抛弃了苹果……不幸的是,我有很多使用 iPhone 的客户举起拳头: )
    • 2020,我们还在等待!
    猜你喜欢
    • 2019-01-09
    • 2015-07-30
    • 1970-01-01
    • 1970-01-01
    • 2016-04-26
    • 1970-01-01
    • 2011-08-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多