从虚拟 URL 获取文件名?
我有一个类似“http://www.ti.com/lit/gpn/TPS767D318-Q1”的 URL 这是最终在浏览器上路由到“http://www.ti.com/lit/ds/symlink/tps767d318-q1.pdf”的路径(呈现 pdf 文件)。我正在控制台应用程序中处理此 URL,以便获取您在我提供的第二个 URL 中看到的“pdf”文件名。
我检查了 httpresponse 对象中的 UriResponse.Absoluteuri 属性,它显示“http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=TPS767D318-Q1&fileType=pdf” 看起来这是一个嵌套的虚拟路径。有人可以帮助我找到最终 URL 以提取 pdf 文件名吗?我在响应对象中没有找到它。我还检查了响应标头,但也没有任何内容。
任何帮助将不胜感激...谢谢
I have a URL like "http://www.ti.com/lit/gpn/TPS767D318-Q1"
which is a path eventually being routed to "http://www.ti.com/lit/ds/symlink/tps767d318-q1.pdf" on the browser(rendering a pdf file). I am processing this URL in a Console application in order to fetch the "pdf" filename that you see in the second URL i provided.
I checked the UriResponse.Absoluteuri property in the httpresponse object and it says "http://focus.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=TPS767D318-Q1&fileType=pdf"
looks like this is a nested virtual path. Can anybody help on where i can get to the end URL to extract the pdf file name? i did not find it anywhere in the response object. I also checked in the Response headers and nothing there either.
Any help will be appreciated...Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
不确定 ASP,但在协议级别,初始请求可能会导致另一端的应用程序/服务器发出重定向,因此您可以查看初始 HTTP 响应并检查它是否是重定向代码,301、302如果是这样,您可以跟随 302 直到到达 200,这就是您可以用来检查文件名的最终 URL。
Not sure about ASP, but at the protocol level the initial request may cause a Redirect to be issued by the application/server on the other end, so you can look at the initial HTTP response and check if it's a redirect code, 301, 302 etc. If so, you can follow the 302s until you hit a 200, and that's the final URL you can use to check the filename.
查看
Content-Disposition
标头,它可能类似于:Content-Disposition: Attachment;文件名=tps767d318-q1.pdf
。这是从数据库、网络共享等获取和“下载”文件的 Web 服务的常用技术。Look at the
Content-Disposition
header, it might look something like:Content-Disposition: attachment; filename=tps767d318-q1.pdf
. This is a common technique for webservices that fetch and "download" files from database, network shares, etc.事实证明,我的问题中的 URL 实际上返回 HTML 内容并执行“元标记”重定向。所以我必须执行以下操作:
我从返回的 HTML 内容的元标记中获取最终 URL,并再次调用我的下载例程。
It turns out that the URL in my question is actually returning HTML content and doing a "meta tag" redirect. So I had to do the following:
I'm getting the final URL out of the meta tags from the returned HTML content, and calling my download routine again.