为什么Chrome有时会下载PDF而不是将其打开？ [重复]

#1 楼

基本上，发生这种情况是因为网站指示浏览器执行此操作。有时是因为网站开发者决定他们想要这种行为，例如在文件共享网站上常见。有时是因为这是他们使用的任何软件（例如论坛或博客软件）的默认选项。有时是因为站点开发人员不知道他们在做什么。


Content-Disposition

通常是因为站点在响应中发送了Content-Disposition标头。具体来说，它可以发送inline或attachment。

如果没有另外指定，则默认为inline，这意味着浏览器将在可能的情况下在浏览器窗口中打开文件。

attachment表示始终下载文件，从不尝试在浏览器中打开文件。


如果打开浏览器的开发人员工具，您将看到特定的链接发送以下信息响应头：

Content-Disposition: attachment; filename="Schubert-Sonata-21-B-flat.pdf"
Content-Type: application/pdf

这告诉浏览器始终下载（attachment）文件，并为其提供默认文件名Schubert-Sonata-21-B-flat.pdf，而不是从URL进行推断。此外，它确实告诉浏览器（正确）它是application/pdf文件-但由于它是attachment，因此浏览器仍默认为下载。


内联处理详细信息

当Content-Disposition内联（或未指定）时，浏览器将尝试在默认的嵌入式查看器中打开文件。仅当浏览器知道文件类型是什么，并且浏览器知道如何打开该文件类型时，此方法才起作用。

类型检测

服务器可以指定文件类型带有Content-Type标头。例如，最常见的内联类型是text/html，application/javascript和text/css，它们构成了现代网站的三个主要部分。您还可以具有更多深奥的类型，例如application/pdf。

另一种可能性是服务器已将Content-Type指定为application/octet-stream。这是最通用的类​​型，它告诉浏览器文件只是任意数据-这时浏览器唯一可以做的就是下载它（理论上，我们会做到这一点）。

当服务器未指定Content-Type时（有时甚至未指定），浏览器可以执行嗅探来尝试通过读取文件并查找模式来猜测类型。

类型处理

在接收到带有inline或未指定配置的文件后，浏览器需要在可能的情况下尝试在浏览器中打开它。为此，它将查看文件类型，如果识别出该文件类型，它将尝试将其打开。大多数浏览器会在简单的文本查看器中打开任何text/类型，尝试将text/html呈现为网页，并可能在突出显示语法的特殊查看器中打开application/json，等等。

application/octet-stream类型是经过特殊处理的。因为它应该是最通用的类​​型，表示任意字节流，所以不应该有任何处理程序可以应用于此“类型”的所有文件。例如，在Firefox中，这表现为无法为application/octet-stream设置默认处理程序。

一些网站还使用了非标准类型。我看过使用过application/force-download的情况-最终作为下载内容，因为浏览器无法识别或不知道与该类型有关的其他内容，但是却不享受application/octet-stream的特殊处理。


一些历史课程

要了解如何处理PDF，我们可以深入研究Web历史。过去，浏览器不知道什么是PDF。因此他们无法打开它。但是，我们已经看到，在内置PDF查看器出现之前很久就已经在浏览器中打开了PDF，这是如何工作的？

与过去使用有限的扩展程序/扩展程序相比，过去可以用更多的控制权扩展浏览器功能。那些通常被称为插件。在Internet Explorer中，它们是ActiveX控件。在Mozilla Firefox和更高版本的Google Chrome中，它们是NPAPI插件。这些插件能够执行任何其他程序可以做的所有事情，并且可以将自己注册为特定文件类型的处理程序，否则浏览器将无法识别它们。 （顺便说一句，后来发现这存在巨大的安全风险，并且逐渐放弃了对这些强大插件的支持...）

在插件时代，您将去安装Adobe Acrobat Reader，然后会安装一个ActiveX或NPAPI插件，该插件将注册application/pdf MIME类型，并告诉浏览器使用该插件内联打开这些类型。

当然，在由这些原因引起的许多安全性和性能问题之后插件，主要的浏览器供应商决定合并自己的PDF查看器，同时逐步淘汰对大多数插件的支持。我们仍然看到的唯一一个是Adobe Shockwave Flash，它可以处理application/x-shockwave-flash。

实际上仍然有一些剩余控件，例如在Firefox中，Preview in Firefox选项仍然存在：





这些日子也早于HTML5附带的许多媒体支持之前。不仅是PDF，您的浏览器也不知道如何处理MP4容器或H.264视频，也不知道如何播放MP3文件等。您将看到VLC等媒体播放器提供的插件甚至Windows Media Player，或者网站会嵌入Flash内置的媒体播放器。

评论

---

有时，当服务器设置Content-Type：application / octet-stream时，也会发生这种情况，但是现在这种情况已经不那么普遍了。

–迈克尔·汉普顿
17年12月17日在21:14

---

之所以使用值“ inline”和“ attachment”，是因为Content-Disposition最初是为MIME电子邮件指定的，这些值更合适:)

–霍布斯
17年12月18日在22:59

---

@hobbs：当一些更抽象的东西可以做时，几乎是可重用技术中特定领域术语的案例研究

–轨道轻赛
17年12月21日在11:18

---

#2 楼

我找到了一个解释。根据我发现的答案，如果MIME内容类型未设置为application/pdf，而是设置为“错误或通用MIME类型” application/octet-stream，那么Chrome似乎将下载PDF。

此外，“大多数Web服务器使用默认的application/octet-stream MIME类型发送未知类型的资源。出于安全原因，大多数浏览器不允许为此类资源设置自定义默认操作，从而迫使用户将其存储到磁盘上以进行使用。“

#3 楼

这是由于HTTP Content-Disposition标头指定该文件为附件。这指示浏览器下载文件，而不是直接打开文件。

有一个Chrome加载项可以替代此行为。下图来自Firefox开发人员工具：