【问题标题】:Is there a way to use browser's native gzip decompression using Javascript?有没有办法使用 Javascript 使用浏览器的原生 gzip 解压?
【发布时间】:2016-03-23 17:40:57
【问题描述】:

后端服务器响应一个 gzip 文件,但没有 Content-Encoding: gzip header。而且我无法控制服务器,因此无法处理服务器端的问题。

我现在需要的是使用javascript解压缩gzip文件客户端。

我找到了这个可以帮助我做到这一点的优秀库:http://nodeca.github.io/pako/

但我不想添加额外的库只是为了解压缩文件。我觉得应该有一种方法可以使用浏览器的本机功能来解压缩。我对么?如果我错了,有人可以解释为什么这个浏览器功能没有作为 javascript API 公开吗?有没有办法在 javascript 中解压缩文件而不添加额外的库?

【问题讨论】:

  • 据我所知,您无法强制浏览器使用 javascript 解压缩页面,因为您无法控制浏览器呈现页面的方式。跨度>
  • 我发出了一个 get ajax 请求来获取文件
  • 这一切都很好,但如果服务器没有输出与内容编码匹配的标头,我相信您将不得不手动解压缩。
  • 我认为问题完全在于手动解压缩,通过 ajax 请求获取的资源不是整个页面

标签: javascript gzip


【解决方案1】:

Compression Streams API 是一种新的网络标准,目前在 Chrome (since v80)、Edge 和 Deno 中可用。其他浏览器最终会添加它,但同时最好的选择是WASM implementationApparently WASM 实现可以达到原生实现的 90% 的性能(大约是 JS 实现的 20 倍)。

Compression Streams API 的一些示例用法:

async function decompressBlob(blob) {
  let ds = new DecompressionStream("gzip");
  let decompressedStream = blob.stream().pipeThrough(ds);
  return await new Response(decompressedStream).blob();
}

对于压缩:

const compressedReadableStream = inputReadableStream.pipeThrough(new CompressionStream('gzip'));

更多信息:

【讨论】:

    【解决方案2】:

    我觉得应该有一种方法可以使用浏览器的原生功能来解压缩。如果我错了,有人可以解释为什么这个浏览器功能没有作为 javascript API 公开吗?

    不,不应该有,除非它符合 w3c 标准,而事实并非如此。唯一说明 gzip 压缩的标准是 an HTTP standard

    我真的相信它不会成为标准,因为您可能想要使用数以千计的算法(用于压缩、加密等),而浏览器无法全部处理;为一种算法创建接口而不为另一种算法创建接口也是不公平

    HTTP 协议是一种例外。这里的压缩是为了让数百万人的生活更轻松。 HTTP 是 Web 性能的瓶颈,所以只要压缩可用,我无法想象在其他地方需要在 JavaScript 中使用压缩的任何情况。我知道的唯一情况是压缩 localStorage / indexedDB 中的项目,但即使存在 gzip 也无法工作,因为它不会产生 UTF-16 输出。

    这就是为什么这不在标准中,这就是为什么它很可能不会出现在那里。

    您的特殊情况是服务器端实现错误。使用没有适当标题的压缩输出真的很臭。要么不使用压缩,要么做对。

    有没有办法在 javascript 中解压缩文件而不添加额外的库?

    实际上除此之外还有一个可能的解决方案:创建一个浏览器扩展,在服务器响应中注入适当的标头,您不需要库,但需要将扩展​​分发给用户。可能会更糟,但仍然可以工作。

    【讨论】:

    • 提供应用程序可用的 GZIP 支持的一个原因是其他协议,例如 Web Sockets。
    • 当然,这可能会有所帮助。我不反对进行压缩的想法,但它不存在。但是有一些网络套接字的解决方案,stackoverflow.com/questions/11646680/…
    • there shouldn't be, unless it is in w3c standard - 这是对 w3c 如何开始或继续存在的误解。从历史上看(甚至最近),w3c 并没有发明标准供浏览器实现。相反,它通常采用浏览器制造商可以说服它采用的标准,并希望其他人坚持新标准。因此,如果 Google Chrome 和 Firefox 或 Safari 和 Edge 或 Edge 和 Chrome 等决定让 gzip API 可用于 js,它很快成为 w3c 标准——而不是相反
    • 见鬼,我应该在留下评论之前向下滚动。 Joe 的回答很好地说明了这个标准化过程:Chrome 实现了一个压缩标准,一群人成立了一个工作组,很快 w3c 将采用它,然后 5 年后它将被广泛使用。我知道这不公平,因为你不知道乔会在你写完答案 5 年后写下答案,但即使早在 2016 年,这就是 w3c 标准的工作方式
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-02-03
    • 2013-05-24
    • 1970-01-01
    • 2010-12-05
    • 2015-11-17
    • 2015-02-13
    相关资源
    最近更新 更多