下载八位字节流然后编码为pdf；无法解决行尾问题
Downloaded octet-stream then encoding as pdf; can't get line endings worked out
我为此使用的工具：
Chrome
Notepad++
Sublime Text 3
Fiddler
WinMerge
Adobe Acrobat Reader X
剧情简介
一个pdf我下载了两次，一次通过Chrome作为实验对照；再次通过 Fiddler 的原始 /GET 请求 returns 我是一个八位字节流。至此，我可以将八位位组流保存为 pdf，并且可以获得正确的页数以及一些页眉和页码，但加载的正文内容很少。当我在 Adobe Reader X 中打开我的文件时，出现错误
Cannot extract the embedded font 'LFIDTH+ArialMT'. Some characters may not display or print correctly
我无法理解为什么它可以从 'true' pdf 中提取，但不能从我保存的 pdf 中提取。
详情
至于我手动拉取的文件，我已经提供了
Accept: application/pdf, application/x-pdf, application/x-gzpdf, application/x-bzpdf
服务器发回给我一个 aplication/octet-stream 附件处理。
回顾一下：
- 有效 Foo.pdf 坐在我的硬盘上
- 具有同一文件的八位字节流版本的 HTTP 响应，采用 UTF-8 编码（我假设）
这是我所知道的：
我从服务器中提取响应的消息正文并将其放到文件中。然后我 运行 将它与 pdf 的内容进行 WinMerge 比较，并且每行在行尾不匹配。我将 Unix 的 EOL 和 diff sh运行k 重新编码为 160k 中的 ~1k 行。仔细检查不匹配表明有效的 pdf 在某些地方保留了看起来像 NUL 00 字符的内容，而我的八位字节流包含文字空格。此外，"true" pdf 正在通过 WinMerge 报告 EOL: LF 1252 Mixed。我的 "raw" pdf 报告 1252 Unix 当我将 'true' pdf 同质化为 1252 Unix 时，我遇到了与 'raw' 中解释的相同的问题。
我能做些什么来理顺这个乱七八糟的八位字节流吗？
Note that the pdf that was downloaded through Chrome is historic. I have it on my machine, but I downloaded it "sometime in the past" and the request headers used when processing that /GET are no longer available. Attempting to download through the browser "now" results in an error, but an explicit GET request against the resource through Fiddler is returning the pdf as an octet-stream.
现在好了....
在 Fiddler 会话中，
右键单击带有 application/octet-stream 正文的 HTTP 响应 |保存 |回复 |响应正文
如果已在响应中设置 Content-Disposition: attachment;filename，文件保存对话框将预先填充 filename
当你知道它在那里后很容易。
我为此使用的工具：
Chrome
Notepad++
Sublime Text 3
Fiddler
WinMerge
Adobe Acrobat Reader X
剧情简介
一个pdf我下载了两次，一次通过Chrome作为实验对照；再次通过 Fiddler 的原始 /GET 请求 returns 我是一个八位字节流。至此，我可以将八位位组流保存为 pdf，并且可以获得正确的页数以及一些页眉和页码，但加载的正文内容很少。当我在 Adobe Reader X 中打开我的文件时，出现错误
Cannot extract the embedded font 'LFIDTH+ArialMT'. Some characters may not display or print correctly
我无法理解为什么它可以从 'true' pdf 中提取，但不能从我保存的 pdf 中提取。
详情
至于我手动拉取的文件，我已经提供了
Accept: application/pdf, application/x-pdf, application/x-gzpdf, application/x-bzpdf
服务器发回给我一个 aplication/octet-stream 附件处理。
回顾一下：
- 有效 Foo.pdf 坐在我的硬盘上
- 具有同一文件的八位字节流版本的 HTTP 响应，采用 UTF-8 编码（我假设）
这是我所知道的：
我从服务器中提取响应的消息正文并将其放到文件中。然后我 运行 将它与 pdf 的内容进行 WinMerge 比较，并且每行在行尾不匹配。我将 Unix 的 EOL 和 diff sh运行k 重新编码为 160k 中的 ~1k 行。仔细检查不匹配表明有效的 pdf 在某些地方保留了看起来像 NUL 00 字符的内容，而我的八位字节流包含文字空格。此外，"true" pdf 正在通过 WinMerge 报告 EOL: LF 1252 Mixed。我的 "raw" pdf 报告 1252 Unix 当我将 'true' pdf 同质化为 1252 Unix 时，我遇到了与 'raw' 中解释的相同的问题。
我能做些什么来理顺这个乱七八糟的八位字节流吗？
Note that the pdf that was downloaded through Chrome is historic. I have it on my machine, but I downloaded it "sometime in the past" and the request headers used when processing that
/GETare no longer available. Attempting to download through the browser "now" results in an error, but an explicit GET request against the resource through Fiddler is returning the pdf as an octet-stream.
现在好了....
在 Fiddler 会话中，
右键单击带有 application/octet-stream 正文的 HTTP 响应 |保存 |回复 |响应正文
如果已在响应中设置 Content-Disposition: attachment;filename，文件保存对话框将预先填充 filename
当你知道它在那里后很容易。