Chrome和Firefox不会在iframe中显示大多数PDF文档 [英] Chrome and Firefox are not displaying most PDF documents in an iframe

查看:1634
本文介绍了Chrome和Firefox不会在iframe中显示大多数PDF文档的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在运行Windows 7,64位。我最近更新了我的操作系统来安装最新的更新。从那以后,大多数PDF文档都停止在我的程序中渲染。我的程序希望在单独的iFrame中显示PDF文档。我通过获取PDF文档的URL并设置 window.frames ['docview']。location = url; 来做到这一点。在大多数情况下,iframe视图保持空白如果之前显示的内容清除)。如果我采用相同的URL并在新的标签页或窗口中打开它,它会呈现罚款。

在我的iframe中呈现失败时,我看到以下消息Chrome控制台:

 资源解释为Document,但是以MIME类型application / pdf传输。 

Firefox在其错误控制台或FireBug控制台中不提供任何类型的消息。 / p>

我无法控制PDF文件的来源,所以我无法更改它们的标题信息。

奇怪,有些文件的加载是正确的。



查看Chrome中的网络请求,对于无法加载的文档,我会看到(例如):


$ b

 请求URL:http://es.csiro.au/pubs/paradis_mdm03.pdf 
请求方法:GET
状态码:200 OK

请求头文件
Accept:text / html,application / xhtml + xml,application / xml; q = 0.9,* / *; q = 0.8
Accept-字符集:ISO-8859-1,utf-8; q = 0.7,*; q = 0.3
接受编码:gzip,deflate,sdch
接受语言:en-US,en; q = 0.8
连接:keep-alive
主机:es.csiro.au
参考:http://query.fxpal.net:8080 / querium / ui / query?searcherId = 2& compact =真安培; SIDX =秩&安培; topicId = 2及queryId = 1&安培; lastEventId = 1490893682130103&安培;高亮= undefined
用户代理:Mozilla / 5.0(Windows NT 6.1; WOW64)AppleWebKit / 535.1(KHTML,像Gecko)Chrome / 13.0.782.220 Safari / 535.1

响应标题
接受范围:字节
连接:保持活动
Content-Length:71764
Content-Type:application / pdf
日期:2011年9月6日星期二04:59:26 GMT
ETag:1f48c8-11854-43e4ee482ef40
Keep-Alive:timeout = 15,max = 100
上次修改时间:Wed,07 Nov 2007 04:07:49 GMT
服务器:Apache / 2.0.55(Ubuntu)PHP / 5.1.2 mod_ssl / 2.0.55 OpenSSL / 0.9.8a

从单独的选项卡打开渲染),我得到以下内容:

 请求URL:http://es.csiro.au/pubs/paradis_mdm03.pdf 
请求方法:GET
状态码:304未修改

请求标题
接受:text / html,application / xhtml + xml,application / xml; q = 0.9,* / *; q = 0.8
Accept-Charset:ISO-8859-1,utf-8; q = 0.7,*; q = 0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en; q = 0.8
Cache-Control:max-age = 0
连接:keep-aliv e
主机:es.csiro.au
If-Modified-Since:星期三,07十一月2007 04:07:49 GMT
If-None-Match:1f48c8-11854-43e4ee482ef40
范围:bytes = 0-71763
User-Agent:Mozilla / 5.0(Windows NT 6.1; WOW64)AppleWebKit / 535.1(KHTML,如Gecko)Chrome / 13.0.782.220 Safari / 535.1

响应头文件
连接:保持活动
日期:2011年9月6日:07:15 GMT
ETag:1f48c8-11854-43e4ee482ef40
Keep-Alive:timeout = 15,max = 100
服务器:Apache / 2.0.55(Ubuntu)PHP / 5.1 .2 mod_ssl / 2.0.55 OpenSSL / 0.9.8a

有一点很奇怪,但也许服务器是聪明的或有一些有趣的与缓存交互。谁知道。



任何帮助将不胜感激。



基因



编辑:2011年9月6日



当我删除标记时,

 < meta http-equiv =content-typecontent =text / html; charset = UTF-8>来自< head> 元素的

我的HTML页面,许多(但不是全部)的PDF开始正确渲染。这是标题中另一个元标记的明显副本:

 < meta http-equiv =Content-Typecontent =text / html; charset = UTF-8/> 

这是否有助于揭示潜在问题?不要将iframe的 src 属性设置为PDF,而是将其设置为包装HTML文件,其中包含一个简单的div:

 <!DOCTYPE html> 
< html style =height:100%;>
< head>
< / head>
< body style =height:100%;>
< div id =divContentsstyle =height:100%;>< / div>
< / body>
< / html>

在javascript中, div 的内容是设置为对象元素。不幸的是,在IE浏览器,Firefox和Chrome浏览器上都需要稍微不同的版本才能可靠地工作:
$ b

(我简化了divContents元素的检索,浏览器检测)

  var embed ='< object type =application / pdfwidth =100 %height =100%'; 
if(msie){
embed + ='>< param name =srcvalue ='+ pdf +'/>';
}
else if(chrome){
embed + ='src ='+ pdf +'>';
}
else {
embed + ='data ='+ pdf +'>';
}
嵌入+ ='< / object>';
$(#divContents)。html(embed);

UPDATED

<我终于找到了Chrome中失败的真正原因:它是 Accept-Ranges:bytes 字段,没有它,当<$ c $使用c> data 属性。


  • 所以如果你的服务器能够支持 Accept-Ranges 字段,你应该确保它返回给客户端。在这种情况下,您可以使用 pdfobject 库在框架或div中显示PDF。

  • 如果不是,您可以使用上面的代码在框架或div中显示PDF。

    I am running Windows 7, 64 bit. I have recently updated my OS to install the latest updates. Since then, most PDF documents have stopped rendering in my program. My program wants to display PDF documents in a separate iFrame. I do this by getting the URL of the PDF document and setting window.frames['docview'].location = url; In most cases, the iframe view remains blank (or clears if something was shown there previously). If I take that same URL and open it in a new tab or window, it renders fine.

    When it fails to render in my iframe, I see the following message in the Chrome console:

    Resource interpreted as Document but transferred with MIME type application/pdf.
    

    Firefox does not offer a message of any kind in its error console, or on the FireBug console.

    I have no control over the source of the PDF files, so I cannot change their header information.

    Oddly, some files do load correctly.

    Looking at the network requests in Chrome, for a document that fails to load I see (for example):

    Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
    Request Method:GET
    Status Code:200 OK
    
    Request Headers
    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
    Accept-Encoding:gzip,deflate,sdch
    Accept-Language:en-US,en;q=0.8
    Connection:keep-alive
    Host:es.csiro.au
    Referer:http://querium.fxpal.net:8080/querium/ui/query?searcherId=2&compact=true&sidx=rank&topicId=2&queryId=1&lastEventId=1490893682130103&highlight=undefined
    User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
    
    Response Headers
    Accept-Ranges:bytes
    Connection:Keep-Alive
    Content-Length:71764
    Content-Type:application/pdf
    Date:Tue, 06 Sep 2011 04:59:26 GMT
    ETag:"1f48c8-11854-43e4ee482ef40"
    Keep-Alive:timeout=15, max=100
    Last-Modified:Wed, 07 Nov 2007 04:07:49 GMT
    Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
    

    When opened from a separate tab (where the document does render), I get the following:

    Request URL:http://es.csiro.au/pubs/paradis_mdm03.pdf
    Request Method:GET
    Status Code:304 Not Modified
    
    Request Headers
    Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
    Accept-Encoding:gzip,deflate,sdch
    Accept-Language:en-US,en;q=0.8
    Cache-Control:max-age=0
    Connection:keep-alive
    Host:es.csiro.au
    If-Modified-Since:Wed, 07 Nov 2007 04:07:49 GMT
    If-None-Match:"1f48c8-11854-43e4ee482ef40"
    Range:bytes=0-71763
    User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
    
    Response Headers
    Connection:Keep-Alive
    Date:Tue, 06 Sep 2011 05:07:15 GMT
    ETag:"1f48c8-11854-43e4ee482ef40"
    Keep-Alive:timeout=15, max=100
    Server:Apache/2.0.55 (Ubuntu) PHP/5.1.2 mod_ssl/2.0.55 OpenSSL/0.9.8a
    

    One odd things is the difference in status, but maybe the server is being smart or there is some funny interaction with the cache. Who knows.

    Any help would be greatly appreciated.

    Gene

    EDITED: 9/6/2011

    When I removed the tag

     <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    

    from the <head> element of my HTML page, many (but not all) of the PDFs started rendering properly. This was an apparent duplicate of another meta tag in the header:

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    

    Does this help shed any light on the potential problem?

    解决方案

    Instead of setting the src attribute of the iframe to the PDF, set it to a wrapper HTML-file, which contains a simple div:

    <!DOCTYPE html>
    <html style="height:100%;">
    <head>
    </head>
    <body style="height:100%;">
        <div id="divContents" style="height:100%;"></div>
    </body>
    </html>
    

    In javascript the contents of the div is set to an object element. Unfortunately slightly different versions are needed to work reliable on all browsers (tested on IE, Firefox and Chrome):

    (I simplified the retrieval of the divContents element and the browser detection)

    var embed = '<object type="application/pdf" width="100%" height="100%"';
    if (msie) {
        embed += '><param name="src" value="' + pdf + '"/>';
    }
    else if (chrome) {
        embed += ' src="' + pdf + '">';
    }
    else {
        embed += ' data="' + pdf + '">';
    }
    embed += '</object>';
    $("#divContents").html(embed);
    

    UPDATED

    I've finally found the actual cause of the failure in Chrome: It's the Accept-Ranges:bytes field, without it Chrome will not work when the data attribute is used.

    • So if your server is capable of supporting the Accept-Ranges field, you should make sure it is returned to the client. In that case you can use the pdfobject library to display the PDF in a frame or div.
    • If not, you can use the code above to display the PDF in a frame or div.

    这篇关于Chrome和Firefox不会在iframe中显示大多数PDF文档的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆