Android 浏览器/webview 错误?内容处置:附件;文件名=“xyz.txt”

发布于 2024-09-28 16:42:50 字数 809 浏览 5 评论 0原文

因此,Android 浏览器或 webview 对于这样的 URL 可以正常工作 - abc.com/xyz.txt

但是,如果您的 URL 看起来像这样 - abc.com/xyz.php 并且在标头中发送到浏览器的内容是 - Content-处置:附件; filename="xyz.txt",那么 Android 浏览器和 Web 视图似乎会变得非常混乱。

看起来它在手机上保存了正确的文件名,但内容却是之前查看过的网页。这在基于 PC 的浏览器以及 iPhone 和 Blackberry 上运行得非常好,这只是 Android 2.1 和 2.2 上的问题(尚未测试其他版本)。

有人有解决办法吗?将非常感激。我真的不想开始存储静态文件,而是想动态生成下载内容。手机上的日志没有透露任何线索。


这是服务器发送到浏览器的内容

===================== start content ====================================
HTTP/1.1 200 OK
Date: Thu, 21 Oct 2010 21:22:11 GMT
Server: Apache
Content-Disposition: attachment; filename="Wafty.txt"
Content-length: 30
Content-Type: text/plain; charset=ISO-8859-1

Hello this is a test of a file
========= There was no carriage return at the end of the above line ====

So an android browser or a webview works fine with urls like this - abc.com/xyz.txt

However, if your URL looks like this - abc.com/xyz.php and what's sent to the browser in the headers is - Content-Disposition: attachment; filename="xyz.txt", then the Android browsers and web view seems to get terribly confused.

It looks like it saves the correct file name on the phone, but the contents is filled with the webpage that was previously being viewed. This works perfectly well on PC based browsers and on an iPhone and Blackberry, it's only a problem on the Android 2.1 and 2.2 (haven't tested others).

Anyone have a solution? Will be very grateful. I really don't want to start storing static files and want to generate my download content on the fly. The log on the phone has revealed no clues.


Here's what's sent by the server to the browser

===================== start content ====================================
HTTP/1.1 200 OK
Date: Thu, 21 Oct 2010 21:22:11 GMT
Server: Apache
Content-Disposition: attachment; filename="Wafty.txt"
Content-length: 30
Content-Type: text/plain; charset=ISO-8859-1

Hello this is a test of a file
========= There was no carriage return at the end of the above line ====

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

绳情 2024-10-05 16:42:50

使用:

Content-Disposition: attachment;filename="xyz.txt"

请勿使用(注意额外空间):

Content-Disposition: attachment;  filename="xyz.txt"

Use:

Content-Disposition: attachment;filename="xyz.txt"

Do not use (mind extra space):

Content-Disposition: attachment;  filename="xyz.txt"
一抹苦笑 2024-10-05 16:42:50

我有和你类似的问题。这里的问题是 WebView 如何处理附件(真是令人头疼)。当 WebView 访问某个网页并在某个时刻返回附件时,它会说有点像“哦废话,我能用这个非 HTML 的东西做什么?...Ey you!DownloadListener!用这个 URL 做一些事情,说的是关于附件的一些废话”。因此,DownloadListener 接管了任务,问题就在这里:它再次请求相同的 URL 来下载附件,因此,为了在访问页面时下载附件,WebView 会执行 2 个请求:页面本身,然后是另一个下载附件的请求。附件,而不仅仅是下载。

这怎么会是一个问题呢?好吧,假设在 abc.com/xyz.php 中您有一些逻辑,例如:

<?php
   if(User::loggedIn()) {
       header("Content-Disposition: attachment...");
       //Some more logic for the download
   }
?>

DownloadListener 执行的第二个请求将向 abc.com/xyz.php 发出另一个请求,但这次它不会包含 cookie 或会话信息,因此不会进入“下载”逻辑。

一种可能的解决方案是重定向到临时副本或不包含任何逻辑的文件的真实路径,因此没有问题。当然,您还需要使用 WebView 定义下载侦听器,例如如下所示。

webView.setDownloadListener(new DownloadListener() {

    @Override
    public void onDownloadStart(String url, String userAgent, String contentDisposition, String mimeType, long contentLength) {

        final DownloadManager dm = (DownloadManager) getSystemService(Context.DOWNLOAD_SERVICE);
        Request request = new DownloadManager.Request(Uri.parse(url));
        request.setMimeType(mimeType);

        //Persist download notification in the status bar after the download completes (Android 3.0+)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
            request.allowScanningByMediaScanner();
            request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED);
        }

        dm.enqueue(request);
    }

});

I have a similar problem to yours. The issue here is how WebView handles attachments (a real pain in the ass). When the WebView visits a web page that at some point returns an attachment, it says kinda like "Oh crap, what can I do with this non-HTML thingy?... Ey you! DownloadListener! do something with this URL that is saying some nonsense about an attachment". So, the DownloadListener takes over and here is the problem: it requests again the same URL to download the attachment, so, for downloading an attachment when visiting a page, the WebView perfoms 2 requests: the page itself and then another one to download the attachment, instead of just downloading it.

And how is this a problem? Well, let's say that in your abc.com/xyz.php you have some logic like:

<?php
   if(User::loggedIn()) {
       header("Content-Disposition: attachment...");
       //Some more logic for the download
   }
?>

The second request performed by the DownloadListener will make another request to abc.com/xyz.php but this time it won't contain cookies or session information so it won't enter the "download" logic.

A possible solution would be to redirect to a temporal copy or the real path to the file that doesn't contains any logic so there is no problem. Of course, you also need to define your Download listener withing your WebView, something like this for example.

webView.setDownloadListener(new DownloadListener() {

    @Override
    public void onDownloadStart(String url, String userAgent, String contentDisposition, String mimeType, long contentLength) {

        final DownloadManager dm = (DownloadManager) getSystemService(Context.DOWNLOAD_SERVICE);
        Request request = new DownloadManager.Request(Uri.parse(url));
        request.setMimeType(mimeType);

        //Persist download notification in the status bar after the download completes (Android 3.0+)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
            request.allowScanningByMediaScanner();
            request.setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED);
        }

        dm.enqueue(request);
    }

});
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文