有没有一种使用JavaScript利用浏览器原生的gzip解压缩的方法？

Question

后端服务器响应gzip文件，但没有发送“Content-Encoding: gzip header”头信息。我无法控制服务器，因此无法在服务器端处理此问题。现在我需要使用JavaScript在客户端解压缩gzip文件。我找到了这个很好的库，可以帮助我实现这一点：http://nodeca.github.io/pako/，但是我不想添加额外的库来解压缩文件。我觉得应该有一种方法可以使用浏览器的本机功能来解压缩。我正确吗？如果我错了，请有人解释为什么这个浏览器功能没有作为Javascript API暴露出来？是否有一种方法可以在JavaScript中解压缩文件而不添加额外的库？

- Yash Agarwal

---

据我所知，您无法通过JavaScript“强制”浏览器取消gzip页面，因为您无法控制浏览器呈现页面的方式。 - Technoh

我发起一个get ajax请求来获取文件。 - Yash Agarwal

这一切都很好，但如果服务器没有输出与内容编码匹配的标头，我认为您将不得不手动解压缩。 - Technoh

我认为这个问题确切地说是关于手动解压缩一个通过 AJAX 请求获取的资源，而不是整个页面。 - Mohamed Ali

Answer 1

压缩流 API 是一个新的网络标准，目前在 Chromium、Firefox、Safari 和 Deno 中可用。

一些使用压缩流 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'));

你还可以使用WASM实现。显然，WASM实现可以接近本地实现的90%性能（以及JS实现速度的约20倍）。

另请参阅：

• WICG标准文档：压缩流API

- joe

Answer 2

答案是错误的，应该被删除，但由于平台限制无法删除。请忽略这个答案，选择另一个答案。

---

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

不，不应该有，除非它是W3C标准，并且它不是。唯一一个关于gzip压缩的标准是HTTP标准。

我真的相信它不会成为标准，因为有成千上万种算法（用于压缩、加密等），你可能想要使用，而浏览器无法处理它们所有；为一个算法创建接口而不为另一个算法创建接口也是不公平的。

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

这就是为什么这不符合标准，也是为什么它很可能不会出现在那里。

您的特定情况是服务器端实现错误。在没有正确头部的情况下使用压缩输出确实不太好。要么不使用压缩，要么正确地使用。

是否有一种方法可以在JavaScript中解压缩文件而不添加额外的库？

实际上，除此之外还有一种可能的解决方案：创建一个浏览器扩展，在服务器响应中注入正确的头部，这样您就不需要库，但需要将扩展分发给用户。这可能甚至更糟糕，但仍然可能有效。

- smnbbrv

---

提供应用程序可用的GZIP支持的一个原因是为了其他协议，比如Web Sockets。 - acjay

肯定的，这可能会有帮助。我并不反对拥有压缩的想法，但它现在还不存在。然而，对于 WebSocket 有某种解决方案，https://dev59.com/r2gu5IYBdhLWcg3wByi1 - smnbbrv

除非符合W3C标准，否则不应该出现。这是对于W3C的成立和存在方式的误解。历史上（甚至最近），W3C并不会发明浏览器需要实现的标准。相反，它通常采用浏览器制造商能够说服其采用的标准，并希望其他人遵循新标准。因此，如果Google Chrome和Firefox或Safari和Edge或Edge和Chrome等决定使gzip API可用于js，则它将很快成为W3C标准 - 而不是相反。 - slebetman

该死，我在留言之前应该向下滚动一下。乔的回答很好地说明了这个标准化过程：Chrome实现了一个压缩标准，一些人开始成立工作组，很快w3c就会采纳它，然后5年后它将被广泛使用。我知道这不公平，因为你不可能知道乔会在你写完回答5年后写出他的答案，但即使是在2016年，这也是w3c标准的工作方式。 - slebetman

这个答案并不适用了。现在它基本上是一个错误的答案，不应该被标记为被接受的答案。 - Jorge Galvão

@JorgeGalvão 你说得完全正确。然而，我无法删除它，因为它已经被接受了，而且无法取消接受。 - smnbbrv