正确处理下载文件时HTTP头的编码问题（Content-Disposition

最新推荐文章于 2024-06-19 16:28:04 发布

liutong123987

最新推荐文章于 2024-06-19 16:28:04 发布

阅读量1.5k

点赞数

分类专栏： js

本文链接：https://blog.csdn.net/liutong123987/article/details/79306736

版权

本文详细探讨了如何正确处理HTTP头Content-Disposition中的非ASCII字符编码问题，以实现跨浏览器的文件下载功能。通过遵循RFC 5987和RFC 6266标准，使用filename*字段结合UTF-8编码，可以确保文件名在不同浏览器中保持一致且无乱码。同时，文章指出IE6的特殊性，需要确保文件名包含英文扩展名以实现兼容性。

摘要由CSDN通过智能技术生成

最近在做项目时遇到了一个 case ：需要实现一个强制下载功能（即强制弹出下载对话框），并且文件名必须保持和用户之前上传时相同（可能包含非 ASCII 字符）。

前一个需求很容易实现：使用 HTTP Header 的 Content-Disposition: attachment 即可，还可以配合 Content-Type: application/octet-stream来确保万无一失。而后一个需求就比较蛋疼了，牵扯到 Header 的编码问题（文件名是作为 filename 参数放在 Content-Disposition 里面的）。众所周知， HTTP Header 中的 Content-Type 可以指定内容的编码，可 Header 本身的编码又该如何制定？甚至， Header 究竟是否允许非 ASCII 编码呢？

如果放任编码问题不管，那么恭喜你，你一定会遇到在某个系统及浏览器下下载文件时文件名乱码的情况。如果你尝试搜索解决，那么再一次恭喜你，你会找到一堆自相矛盾的解决方案（我可以负责任地告诉你，其中的99%都是不符合标准的 trick 罢了）。让我们来看看到底应该如何优雅完美地解决这个问题吧！

为了探索这个问题，我走了不少弯路。从自己尝试，到 Google 、百度（分别尝试过中英文搜索），再到阅读 Discuz 等经典项目的源码，众说纷纭、莫衷一是。最后我才想到回归 RFC ，从标准文档中找办法，果然有所收获。由于探究过程实在太曲折，我就先把标准做法写下来。