0. 概述
文件下载是web应用中很常见的场景，在浏览器中下载文件, 最基本的方式就是——在页面内隐藏iframe, 然后将文件下载地址加载到iframe中, 从而触发浏览器的下载行为。 此外, html5引入a标签的download属性, 也是一种下载方式。
下载下面针对下载地址的Response Header、浏览器兼容性, 以及一些特殊case, 做一些说明。
1. 怎样的文件url才能触发浏览器的下载行为?
能触发浏览器下载的url有两类:
response header中指定了Content-Disposition为attachment，它表示让浏览器把响应体作为附件下载到本地 (一般Content-Disposition还会指定filename, 下载的文件默认就是filename指定的名字)
response header中指定了Content-Type 为 application/octet-stream(无类型) 或者 application/zip(下载zip包时)以及其它几个不常见类型 (其中还有浏览器差异)，其中 application/octet-stream表示http response为二进制流(没指定明确的type), 需要下载到本地, 由系统决定或者用户手动指定打开方式。
关于application/octet-stream的情况, 补充几点
这种response, 由于没有明确的type, 如果作为文件下载的话, 下载下来的文件将没有文件名和拓展名(文件名直接取的url path的最后一坨)
如果不作为文件下载, 比如已知response body是一张图片, 可以通过img标签来显示图片
下载下来的内容, 只是缺少文件拓展名而已, 文件内容是完整的, 如果知道它实际的拓展名, 手动改了就能通过系统默认的程序打开, 不改拓展名的话也能通过指定应用程序的方式打开
关于response header的Content-Type, 补充几点
首先要明确, Content-Type只是HTTP协议的部分, 不影响response body自身
Content-Type影响的是response的接收方(一般是浏览器), 对于浏览器而言, 它影响的是浏览器对响应体的处理方式. 比如指定为application/zip, 浏览器就会用pdf阅读器打开.
Content-Type之于浏览器, 就好比文件扩展名之于操作系统, 影响的默认行为, 如果你指定了打开方式, 那么Content-Type就不起作用了. 比如, 你在服务端对图片地址设置Content-Type为application/zip，但你在浏览器使用img标签(相当于指定了打开方式)去加载, 照样能正常加载图片。
为什么上面说的「Content-Type」还有「文件拓展名」对于文件自身没有影响?
这里涉及到「文件格式协议」/「文件头」等内容, 待补充...