解析 multipart/from-data 中的内容处置标头的文件名
根据 RFC,在 multipart/form-data content-disposition 标头中 filename 字段作为参数接收 HTTP 带引号的字符串 - 之间的字符串,其中 字符 '\' 可以转义任何其他 ASCII 字符。
问题是,网络浏览器不这样做。
IE6 发送:
Content-Disposition: form-data; name="file"; filename="z:\tmp\test.txt"
而不是预期
Content-Disposition: form-data; name="file"; filename="z:\\tmp\\test.txt"
根据规则应将其解析为 z:tmptest.txt
而不是 z:\tmp\test.txt
。
Firefox、Konqueror 和 Chrome 不会转义 " 字符,例如:
Content-Disposition: form-data; name="file"; filename=""test".txt"
而不是预期的
Content-Disposition: form-data; name="file"; filename="\"test\".txt"
那么...您建议如何处理这个问题?
有人有想法吗?
According to RFC, in multipart/form-data content-disposition header
filename field receives as parameter HTTP quoted string - string between quites where
character '\' can escape any other ascii character.
The problem is, web browsers don't do it.
IE6 sends:
Content-Disposition: form-data; name="file"; filename="z:\tmp\test.txt"
Instead of expected
Content-Disposition: form-data; name="file"; filename="z:\\tmp\\test.txt"
Which should be parsed as z:tmptest.txt
according to rules instead of z:\tmp\test.txt
.
Firefox, Konqueror and Chrome don't escape " characters for example:
Content-Disposition: form-data; name="file"; filename=""test".txt"
Instead of expected
Content-Disposition: form-data; name="file"; filename="\"test\".txt"
So... how would you suggest to deal with this issue?
Does Anybody have an idea?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
虽然是一个旧线程,但为可能感兴趣的人添加以下 java 解决方案。
Though an old thread, adding the below java solution for whoever might be interested.
您是否有理由需要解析该文件名?
至少有一点是一致的,即标头的
filename
部分以双引号结尾,因此您只需读取filename="
和filename="
之间的所有内容即可。 em>最终"
。然后,您可以将
\\
、\"
或\"
之外的任何反斜杠视为文字反斜杠,除非您认为特别有可能用户将上传带有选项卡的文件名。 :)Is there a reason that you need to parse this filename at all?
At least the one thing that's consistent is that the
filename
portion of the header ends with a double quote, so you just need to read in everything betweenfilename="
and the final"
.Then you can probably treat any backslash other than
\\
,\"
or\"
as a literal backslash, unless you think it's particularly likely that users will be uploading filenames with tabs in them. :)