Javascript 资源被解释为文档但使用 MIME 类型应用程序/zip 传输
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6587393/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Resource interpreted as Document but transferred with MIME type application/zip
提问by Ashley Williams
With Chrome 12.0.742.112, if I redirect with the following headers:
使用 Chrome 12.0.742.112，如果我使用以下标头重定向：
HTTP/1.1 302 Found
Location: http://0.0.0.0:3000/files/download.zip
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Ua-Compatible: IE=Edge
X-Runtime: 0.157964
Content-Length: 0
Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18)
Date: Tue, 05 Jul 2011 18:42:25 GMT
Connection: Keep-Alive
Which if followed returns the following header:
如果遵循，则返回以下标头：
HTTP/1.1 200 OK
Last-Modified: Tue, 05 Jul 2011 18:18:30 GMT
Content-Type: application/zip
Content-Length: 150014
Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-02-18)
Date: Tue, 05 Jul 2011 18:44:47 GMT
Connection: Keep-Alive
Chrome will not redirect, nor change the previous page, it'll just report the following warning in the console:
Chrome 不会重定向，也不会更改上一页，它只会在控制台中报告以下警告：
Resource interpreted as Document but transferred with MIME type application/zip.
资源被解释为文档但使用 MIME 类型应用程序/zip 传输。
The process works correctly in Firefox, and also works fine in Chrome if I open a new tab and go directly to http://0.0.0.0:3000/files/download.zip. Am I doing something wrong, or is this a bug/quirk of Chrome?
该过程在 Firefox 中正常工作，如果我打开一个新标签并直接转到http://0.0.0.0:3000/files/download.zip. 我做错了什么，还是这是 Chrome 的错误/怪癖？
采纳答案by Ashley Williams
I've fixed this…by simply opening a new tab.
我已经解决了这个问题……只需打开一个新标签即可。
Why it wasn't working I'm not entirely sure, but it could have something to do with how Chrome deals with multiple downloads on a page, perhaps it thought they were spam and just ignored them.
为什么它不起作用我不完全确定，但它可能与 Chrome 如何处理页面上的多次下载有关，也许它认为它们是垃圾邮件而只是忽略了它们。
回答by Roy Hyunjin Han
You can specify the HTML5 downloadattribute in your <a> tag.
您可以在 <a> 标签中指定 HTML5下载属性。
<a href="http://example.com/archive.zip" download>Export</a>
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-download
回答by Saeed Neamati
In your request header, you have sent Content-Type: text/htmlwhich means that you'd like to interpret the response as HTML. Now if even server send you PDF files, your browser tries to understand it as HTML. That's the problem. I'm searching to see what the reason could be. :)
在您的请求标头中，您已发送Content-Type: text/html，这意味着您希望将响应解释为 HTML。现在，即使服务器向您发送 PDF 文件，您的浏览器也会尝试将其理解为 HTML。那就是问题所在。我正在寻找可能是什么原因。:)
回答by Evan
I experienced this problem when serving up a PDF file (MIME type application/pdf) and solved it by setting the Content-Disposition header, e.g.:
我在提供 PDF 文件（MIME 类型应用程序/pdf）时遇到了这个问题，并通过设置 Content-Disposition 标头解决了这个问题，例如：
Content-Disposition: attachment; filename=foo.pdf
Hope that helps.
希望有帮助。
回答by Champignac
I could not find anywhere just an explanationof the message by itself. Here is my interpretation.
我找不到任何地方只是对消息本身的解释。这是我的解释。
As far as I understand, Chrome was expecting some material it could possibly display (a document), but it obtained something it could not display (or something it was told not to display).
据我了解，Chrome 期望它可能显示一些材料（文档），但它获得了无法显示的内容（或被告知不要显示的内容）。
This is both a question of how the document was declared at the HTML page level in href(see the downloadattribute in Roy's message) and how it is declared within the server's answer by the means of HTTP headers (in particular Content-Disposition). This is a question of contract, as opposed to hope and expectation.
这既是如何在 HTML 页面级别声明文档的问题href（请参阅downloadRoy 消息中的属性），也是如何通过 HTTP 标头（特别是Content-Disposition）在服务器的回答中声明文档的问题。这是一个契约问题，而不是希望和期望。
To continue on Evan's way, I've experienced that:
为了继续埃文的方式，我经历过：
Content-type: application/pdf
Content-disposition: attachment; filename=some.pdf
is just inconsistentwith:
是刚刚不一致有：
<a href='some.pdf'>
Chrome will cry Resource interpreted as document but transferred…
Chrome 会哭Resource 被解释为文档但已转移...
Actually, the attachmentdisposition just means this: the browser shall not interpret the link, but rather store it somewhere for other—hidden—purposes. Here above, either downloadis missing beside href, or Content-dispositionmust be removed from the headers. It depends on whether we want the browser to render the document or not.
实际上，附件配置只是意味着：浏览器不应解释链接，而是将其存储在某处以用于其他隐藏目的。在上面，要么download在 旁边丢失href，要么Content-disposition必须从标题中删除。这取决于我们是否希望浏览器呈现文档。
Hope this helps.
希望这可以帮助。
回答by JohnC
I encountered this same issue today with Chrome Version 30.0.1599.66 with my node.js / express.js application.
我今天在使用 node.js / express.js 应用程序的 Chrome 版本 30.0.1599.66 上遇到了同样的问题。
The headers arecorrect, express sets them properly automatically, it works in other browsers as indicated, putting html 5 'download' attribute does not resolve, what didresolve it is going into the chrome advanced settings and checking the box "Ask where to save each file before downloading".
标头是正确的，表达它们设置适当的自动，它工作在指示其他浏览器，把HTML 5“下载”属性不解决，什么没有解决它是进入铬高级设置和检查框“请问哪里保存下载前的每个文件”。
After that there was no "Resource interpreted as document...." error reported as in the title of this issue so it appears that ourserver code is correct, it's Chrome that is incorrectly reporting that error in the console when it's set to save files to a location automatically.
之后没有“资源被解释为文档......”错误报告如本问题的标题，所以看起来我们的服务器代码是正确的，当它设置为保存时，Chrome 在控制台中错误地报告了该错误文件自动移动到一个位置。
回答by Elliveny
I had a similar issue when performing a file download through Javascript. Adding the download attribute made no difference but adding target='_blank' did - I no longer get the 'Resource interpreted as Document...' console message.
通过 Javascript 执行文件下载时，我遇到了类似的问题。添加下载属性没有任何区别，但添加 target='_blank' 做了 - 我不再收到“资源被解释为文档...”控制台消息。
Here's my nicely simple code:
这是我非常简单的代码：
var link = document.createElement('a');
link.target = '_blank';
link.href = url;
document.body.appendChild(link); // Required for Firefox
link.click();
link.remove();
I haven't tried it with direct HTML but would expect it to work.
我还没有用直接的 HTML 尝试过，但希望它能工作。
Note I discovered that Firefox requires the link to be appended to the document whereas Chrome will work without it.
请注意，我发现 Firefox 需要将链接附加到文档中，而 Chrome 不需要它也能工作。
回答by Carmela
I encountered this when I assigned src="image_url" in an iframe. It seems that iframe interprets it as a document but it is not. That's why it displays a warning.
我在 iframe 中分配 src="image_url" 时遇到了这个问题。似乎 iframe 将其解释为文档，但事实并非如此。这就是它显示警告的原因。
回答by med
I solved the problem by adding target="_blank"to the link.
With this, chrome opens a new tab and loads the PDF without warning even in responsive mode.
我通过adding target="_blank"链接解决了这个问题。这样，即使在响应模式下，chrome 也会打开一个新选项卡并加载 PDF，而不会发出警告。
回答by user6096790
Just ran into this and none of the other information I could find helped: it was a stupid error: I was sending output to the browser before starting the file download. Surprisingly, I found no helpful errors found (like "headers already sent" etc.). Hopefully, this saves someone else some grief!
刚遇到这个问题，我找不到任何其他信息有帮助：这是一个愚蠢的错误：我在开始下载文件之前将输出发送到浏览器。令人惊讶的是，我没有发现任何有用的错误（例如“标题已经发送”等）。希望这可以为其他人省去一些悲伤！
