英文:
Java OutputStream produces wrong directory path and characters
问题
我正在使用 OutputStream 创建一个用于下载的 PDF 文件，代码如下：
byte[] infoFile = info.getBytes();
String infoName = info.getFileName();
String contentType = info.getContentType();
response.setContentType(contentType);
response.setHeader("Content-disposition", "attachment;filename=\"" + infoName + "\"");
response.setContentLength(infoFile.length);
// 到目前为止都没有问题，文件名是正确的
OutputStream out = response.getOutputStream();
out.write(infoFile);
// 在这里，一旦执行了上一行代码，就会生成一个带有错误字符的文件
// 例如：D:__Profiles__User__Downloads__infoFile.pdf
在这里生成的文件名称类似于 "D:__Profiles__User__Downloads__infoFile.pdf"，
而我期望的文件名是 "D:\Profiles\User\Downloads\infoFile.pdf"。
出了什么问题？
英文:
i'm using OutputStream to create a pdf file for download as follow:
byte[] infoFile = info.getBytes();
String infoName = info.getFileName();
String contentType = info.getContentType();
response.setContentType(contentType);
response.setHeader("Content-disposition", "attachment;filename=\"" + infoName + "\"");
response.setContentLength(infoFile.length);
// till now no problem, the file name is ok
OutputStream out = response.getOutputStream();
out.write(infoFile);
//here, as soon as the previous line is executed a file is generated with wrong characters
// ex. D:__Profiles__User__Downloads__infoFile.pdf
Here the file produced is something like "D:__Profiles__User__Downloads__infoFile.pdf"
while i expect the file "D:\Profiles\User\Downloads\infoFile.pdf"
What's wrong?
答案1
得分: 2
以下是翻译好的内容：
有什么问题吗？
你期望在内容分发头中的文件名应包含路径信息。
收件人不得能够写入除他们专门有权访问的位置以外的任何位置。为了说明这个问题，考虑能够覆盖众所周知的系统位置（比如“/etc/passwd”）的后果。实现这一目标的一种策略是永不相信文件名参数中的文件夹名信息，例如仅保留最后一个路径片段，并只考虑实际文件名（其中“路径片段”是字段值中由路径分隔符字符“\”和“/”分隔的组件）。
同样地，在Mozilla文档
文件名始终是可选的，且不得被应用程序盲目使用：应剥离路径信息，并进行转换以符合服务器文件系统规则。
基本上，你应该只指定infoFile.pdf。将文件保存在哪个目录取决于用户。
英文:
> What's wrong?
Your expectation that the filename in a Content-disposition header should have path information.
From RFC 6266 section 4.3
> Recipients MUST NOT be able to write into any location other than
> one to which they are specifically entitled. To illustrate the
> problem, consider the consequences of being able to overwrite
> well-known system locations (such as "/etc/passwd"). One strategy
> to achieve this is to never trust folder name information in the
> filename parameter, for instance by stripping all but the last
> path segment and only considering the actual filename (where 'path
> segments' are the components of the field value delimited by the
> path separator characters "" and "/").
And similarly in the Mozilla docs
> The filename is always optional and must not be used blindly by the application: path information should be stripped, and conversion to the server file system rules should be done.
Basically you should only be specifying infoFile.pdf. It's up to the user which directory that file is saved in.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论