我的应用程序生成PDF供用户使用.在"内容处置" HTTP标头设置为提到这里.这被设置为"inline; filename = foo.pdf",这对于Acrobat来说应该足以在保存pdf时将"foo.pdf"作为文件名.
但是,单击嵌入浏览器的Acrobat中的"保存"按钮后,要保存的默认名称不是该文件名,而是带有斜杠的URL更改为下划线.巨大而丑陋.有没有办法在Adobe中影响这个默认文件名?
URL中有一个查询字符串,这是不可协商的.这可能很重要,但在URL的末尾添加"&foo =/title.pdf"不会影响默认文件名.
更新2:我试过了两个
content-disposition inline; filename=foo.pdf Content-Type application/pdf; filename=foo.pdf
和
content-disposition inline; filename=foo.pdf Content-Type application/pdf; name=foo.pdf
(通过Firebug验证)可悲的是,都没有奏效.
一个示例网址是
/bar/sessions/958d8a22-0/views/1493881172/export?format=application/pdf&no-attachment=true
转换为默认的Acrobat保存为文件名
http___localhost_bar_sessions_958d8a22-0_views_1493881172_export_format=application_pdf&no-attachment=true.pdf
更新3:Julian Reschke为这种情况带来了实际的洞察力和严谨性.请提出他的回答.这似乎在FF(https://bugzilla.mozilla.org/show_bug.cgi?id=433613)和IE中被打破,但在Opera,Safari和Chrome中工作.http://greenbytes.de/tech/tc2231/#inlwithasciifilenamepdf
在ContentType中也设置文件名.这应该可以解决问题.
context.Response.ContentType = "application/pdf; name=" + fileName; // the usual stuff context.Response.AddHeader("content-disposition", "inline; filename=" + fileName);
设置content-disposition标头后,还要添加content-length标头,然后使用binarywrite来传输PDF.
context.Response.AddHeader("Content-Length", fileBytes.Length.ToString()); context.Response.BinaryWrite(fileBytes);
部分问题是相关的 RFC 2183并没有真正说明如何处理"内联"和文件名的处置类型.
另外,据我所知,实际使用type = inline文件名的唯一UA是Firefox(参见测试用例).
最后,插件API实际上使这些信息可用并不明显(也许熟悉API的人可以详细说明).
话虽这么说,我已经向Adobe人发送了一个指向这个问题的指针; 也许合适的人会看看.
相关:请参阅draft-reschke-rfc2183-in-http中的尝试澄清HTTP中的Content-Disposition - 这是早期的工作正在进行中,反馈意见.
更新:我添加了一个测试用例,这似乎表明Acrobat reader插件不使用响应头(在Firefox中),尽管插件API提供了对它们的访问.
和你一样,我试过让它发挥作用.最后我放弃了这个想法,只是选择了解决方法.
我正在使用ASP.NET MVC Framework,因此我修改了该控制器/操作的路由,以确保提供的PDF文件是URI的位置部分的最后一部分(在查询字符串之前),并传递所有内容在查询字符串中的else.
例如:
旧URI:
HTTP://服务器/应用程序/报告/ showpdf参数1 =富&参数2 =酒吧和文件名= myreport.pdf
新URI:
HTTP://server/app/report/showpdf/myreport.pdf参数1 =富&参数2 =酒吧
生成的标题看起来与您所描述的完全相同(内容类型是application/pdf,处理是内联的,文件名是标题的无用部分).Acrobat在浏览器窗口中显示它(不保存为对话框),如果用户单击Acrobat Save按钮,则自动填充的文件名是报告文件名.
一些注意事项:
为了使文件名看起来像样,它们不应该有任何转义字符(即没有空格等)......这有点限制.在这种情况下,我的文件名是自动生成的,之前有空格,在生成的保存对话框文件名中显示为'%20'.我刚刚用下划线替换了空格,结果很明显.
这不是最好的解决方案,但确实有效.这也意味着您必须拥有可用的文件名才能使其成为原始URI的一部分,这可能会破坏您的程序的工作流程.如果在生成PDF的服务器端调用期间当前正在从数据库生成或检索它,则可能需要将生成文件名的代码移动到javascript作为表单提交的一部分,或者如果它来自数据库,则将其设置为快速ajax调用以在构建导致内联PDF的URL时获取文件名.
如果您从表单上的用户输入中获取文件名,那么应验证该文件名不包含转义字符,这会使用户烦恼.
希望有所帮助.
尝试在任何其他参数之前将文件名放在URL的末尾.这对我有用. http://www.setasign.de/support/tips-and-tricks/filename-in-browser-plugin/