Question

我有一个我需要从中下载文件的设备。在某些情况下，该文件的content-encoding可能不正确。特别是，它可能具有“gzip”的内容编码，当它没有被压缩或以任何方式压缩时。

因此，当文件被gzip压缩时，使用基本的ajax GET获取内容很简单：

$.ajax({
    url: 'http://' + IP + '/test.txt',
    type: 'GET'
})
.done(function(data) {
    alert(data);
});

但是，正如您所料，当内容编码错误时，这会失败。

要清楚，我只是在浏览器中导航到给定网址时，我不想寻找绕过ERR_CONTENT_DECODING_FAILED的解决方案。我希望能够将一个csv加载到javascript中的字符串中以便进一步解析。

我可以获取文件，并强制它跳过尝试解码，或覆盖响应的内容编码，或者其他一些？

Answer 1

根据WHATWG＆＃39; XHR spec，使用来自WHATWG Fetch Standard的 fetch 操作，这是根本无法通过客户端JavaScript实现的。 }。

客户端脚本只能读取浏览器环境提供的响应对象。 Fetch Standard定义了浏览器环境必须如何在 fetch 操作的步骤2中构建响应对象的 body 属性（特别注意子步骤2到4）： / p>

每当传输一个或多个字节时，让 bytes 成为传输的字节并运行这些子字节：



使用字节＆＃39>增加回复的正文。长度。



让编码成为在回复标题列表中解析Content-Encoding的结果。



将 bytes 设置为处理编码和字节的内容编码的结果。



将 bytes 推送到回复的正文。

处理内容编码的操作是：

要处理内容编码给定编码和字节，请运行以下子步骤：



如果不支持编码，请返回 bytes 。



返回使用给定编码解码字节的结果，如HTTP中所述。

从这个定义中，我们可以看到响应对象永远不会在其 body 属性中公开编码字节。在将字节添加到正文之前，必须先对它们进行解码。客户端脚本从不可以访问规范调用的内容＆＃34;传输的字节＆＃34; （即通过线路发送的实际编码字节）。

解码仅由Content-Encoding标头确定。客户端JavaScript无法操纵响应对象的响应头，因此Content-Encoding必须是服务器最初发送的任何内容。

您的服务器正在做什么是错误的。您唯一的选择是：

修复服务器的行为。
通过代理运行HTTP响应，该代理在Content-Encoding响应标头到达您的客户端之前修复它。

Answer 2

在基于浏览器的现代环境中，由于HttpRequest的Same-Origin策略，您无法更改Accept-Encoding：

Link to Google's explanation

对于你的脑死亡设备，最好的解决方法是获取内容并忽略不正确的编码的服务器端代理，然后使用一组理智的标头返回结果。

如何忽略内容编码

2 个答案: