从节点服务器随机stream式传输pdf文件只是在浏览器上显示二进制数据

我有一个节点的应用程序(特别是帆应用程序)是服务的PDF文件。 我的代码服务文件看起来像这样。

request.get(pdfUrl).pipe(res) 

而当我查看PDF的url,它呈现PDF罚款。 但有时,它只是呈现在浏览器上的PDF二进制数据如下所示。

 %PDF-1.4 1 0 obj << /Title (  ) /Creator (  wkhtmltopdf 

我无法弄清楚为什么不能正确地随机提供pdf。 这是铬的东西? 还是我错过了什么?

离开这里希望它有助于某人 – 我有过类似的问题多次,它的两件事之一:

  1. 你正在使用一个HTTPS传递的HTTP连接(这是websocket的典型例子,除了wss之外,你必须指定:443
  2. request的编码参数是服务明文而不是对象。 这通过将encoding设置为null来完成,如下所示: request({url: myUrl, encoding: null})
  3. 标题中的内容types – 明确指出这一点,因为它很明显/其他人已经足够覆盖了这个:)

由于(2),我很确定你正面临着这个问题。 看看https://github.com/request/request

编码 – 编码用于setEncoding响应数据。 如果为null,则正文返回为Buffer。 其他任何东西(包括未定义的默认值)都将作为编码parameter passing给toString()(这意味着默认情况下是有效的)。 (注意:如果你期望二进制数据,你应该设置encoding:null。)


由于上述build议不适合你,所以希望从下面取证:

  • 文件是否在特定大小上失败? 这是一个缓冲区的问题在一定程度上?
  • 文件中某个字符的存在是否会导致这种情况,因为它会破坏您的一些脚本?
  • 元数据部分和文件结尾在失败和成功的文件中是否相同? 如何对媒体文件进行注册,以及如何将其截断为底,可以极大地影响其解释的方式

您可能需要在节点响应中包含内容types头application/pdf ,以告知收件人他们正在接收的是PDF。 一些浏览器足够聪明,可以从数据stream中确定内容types,但是你不能认为情况总是如此。

当Chrome下载PDF文本时,我会检查文件的最后一个。 PDF文件最后包含强制xref表。 所以每个有效的PDF文件应该以下面的顺序结束: %EOF 。 如果不是,那么请求被中断或出错。

您还需要HTTP标头:

 Content-Disposition:inline; filename=sample.pdf; 

 Content-Length: 200 

你有没有试图保存你得到的二进制文件,并通过PDF阅读器手动打开它? 它可能是腐败的。

我会build议尝试这两个:

Content-Type: application/pdf Content-Disposition: attachment; filename="somefilename.pdf" Content-Disposition: attachment; filename="somefilename.pdf"

(或以其他方式控制Mimetypes: https : //www.npmjs.com/package/mime-types )