帶有兩個預告片的PDF檔案？

如果我使用十六進制編輯器分析多個 PDF 檔案，我會發現它們都有兩個預告片。如果物件已更改或更新（https://blog.idrsolutions.com/multiple-trailers-in-a-pdf-file/），這是可能的，但在我的情況下，PDF 檔案沒有被編輯。有誰知道為什么所有分析的檔案都有兩個預告片？

這是一個包含大量文本和兩個影像的 PDF 檔案（此檔案中有兩個預告片，它們（幾乎）彼此相同：：

0001a30bh: 74 72 61 69 6C 65 72 0D 0A 3C 3C 2F 53 69 7A 65 ; TRAILER..<</Size
0001a31bh: 20 34 37 2F 52 6F 6F 74 20 31 20 30 20 52 2F 49 ;  47/Root 1 0 R/I
0001a32bh: 6E 66 6F 20 31 35 20 30 20 52 2F 49 44 5B 3C 45 ; nfo 15 0 R/ID[<E
0001a33bh: 42 33 46 46 33 41 31 45 33 37 33 43 36 34 45 39 ; B3FF3A1E373C64E9
0001a34bh: 31 30 45 33 46 42 43 34 45 37 38 39 31 33 43 3E ; 10E3FBC4E78913C>
0001a35bh: 3C 45 42 33 46 46 33 41 31 45 33 37 33 43 36 34 ; <EB3FF3A1E373C64
0001a36bh: 45 39 31 30 45 33 46 42 43 34 45 37 38 39 31 33 ; E910E3FBC4E78913
0001a37bh: 43 3E 5D 20 3E 3E 0D 0A 73 74 61 72 74 78 72 65 ; C>] >>..startxre
0001a38bh: 66 0D 0A 31 30 36 33 32 33 0D 0A 25 25 45 4F 46 ; f..106323..%%EOF
0001a39bh: 0D 0A 78 72 65 66 0D 0A 30 20 30 0D 0A 74 72 61 ; ..xref..0 0..TRA
0001a3abh: 69 6C 65 72 0D 0A 3C 3C 2F 53 69 7A 65 20 34 37 ; ILER..<</Size 47
0001a3bbh: 2F 52 6F 6F 74 20 31 20 30 20 52 2F 49 6E 66 6F ; /Root 1 0 R/Info
0001a3cbh: 20 31 35 20 30 20 52 2F 49 44 5B 3C 45 42 33 46 ;  15 0 R/ID[<EB3F
0001a3dbh: 46 33 41 31 45 33 37 33 43 36 34 45 39 31 30 45 ; F3A1E373C64E910E
0001a3ebh: 33 46 42 43 34 45 37 38 39 31 33 43 3E 3C 45 42 ; 3FBC4E78913C><EB
0001a3fbh: 33 46 46 33 41 31 45 33 37 33 43 36 34 45 39 31 ; 3FF3A1E373C64E91
0001a40bh: 30 45 33 46 42 43 34 45 37 38 39 31 33 43 3E 5D ; 0E3FBC4E78913C>]
0001a41bh: 20 2F 50 72 65 76 20 31 30 36 33 32 33 2F 58 52 ;  /Prev 106323/XR
0001a42bh: 65 66 53 74 6D 20 31 30 35 39 37 32 3E 3E 0D 0A ; efStm 105972>>..
0001a43bh: 73 74 61 72 74 78 72 65 66 0D 0A 31 30 37 34 32 ; startxref..10742
0001a44bh: 31 0D 0A 25 25 45 4F 46                         ; 1..%%EOF

這是一個僅包含一些隨機字符的 PDF 檔案：

000071cbh: 74 72 61 69 6C 65 72 0D 0A 3C 3C 2F 53 69 7A 65 ; TRAILER..<</Size
000071dbh: 20 32 33 2F 52 6F 6F 74 20 31 20 30 20 52 2F 49 ;  23/Root 1 0 R/I
000071ebh: 6E 66 6F 20 39 20 30 20 52 2F 49 44 5B 3C 39 46 ; nfo 9 0 R/ID[<9F
000071fbh: 46 31 32 45 31 43 30 41 35 36 44 42 34 38 41 33 ; F12E1C0A56DB48A3
0000720bh: 41 31 43 37 32 30 33 38 32 33 30 32 45 32 3E 3C ; A1C720382302E2><
0000721bh: 39 46 46 31 32 45 31 43 30 41 35 36 44 42 34 38 ; 9FF12E1C0A56DB48
0000722bh: 41 33 41 31 43 37 32 30 33 38 32 33 30 32 45 32 ; A3A1C720382302E2
0000723bh: 3E 5D 20 3E 3E 0D 0A 73 74 61 72 74 78 72 65 66 ; >] >>..startxref
0000724bh: 0D 0A 32 38 36 35 39 0D 0A 25 25 45 4F 46 0D 0A ; ..28659..%%EOF..
0000725bh: 78 72 65 66 0D 0A 30 20 30 0D 0A 74 72 61 69 6C ; xref..0 0..TRAIL
0000726bh: 65 72 0D 0A 3C 3C 2F 53 69 7A 65 20 32 33 2F 52 ; ER..<</Size 23/R
0000727bh: 6F 6F 74 20 31 20 30 20 52 2F 49 6E 66 6F 20 39 ; oot 1 0 R/Info 9
0000728bh: 20 30 20 52 2F 49 44 5B 3C 39 46 46 31 32 45 31 ;  0 R/ID[<9FF12E1
0000729bh: 43 30 41 35 36 44 42 34 38 41 33 41 31 43 37 32 ; C0A56DB48A3A1C72
000072abh: 30 33 38 32 33 30 32 45 32 3E 3C 39 46 46 31 32 ; 0382302E2><9FF12
000072bbh: 45 31 43 30 41 35 36 44 42 34 38 41 33 41 31 43 ; E1C0A56DB48A3A1C
000072cbh: 37 32 30 33 38 32 33 30 32 45 32 3E 5D 20 2F 50 ; 720382302E2>] /P
000072dbh: 72 65 76 20 32 38 36 35 39 2F 58 52 65 66 53 74 ; rev 28659/XRefSt
000072ebh: 6D 20 32 38 33 37 34 3E 3E 0D 0A 73 74 61 72 74 ; m 28374>>..start
000072fbh: 78 72 65 66 0D 0A 32 39 32 37 35 0D 0A 25 25 45 ; xref..29275..%%E
0000730bh: 4F 46                                           ; OF

                                                                                      

uj5u.com熱心網友回復：

這些檔案很可能是由 MS Word 創建的。您發布的摘錄看起來像是他們對混合參考 PDF 的解釋。

PDF 規范有兩種特殊的結構，其中使用它引入的機制來進行其他內容的增量更新：

• 線性化 PDF（參見 ISO 32000-2:2020 附錄 F）和
• 混合參考 PDF（參見 ISO 32000-2:2020 第 7.5.8.4 節）。

您的摘錄看起來像后一種 PDF。

一些背景：

在 PDF 1.5 中，Adobe 引入了在一個流中收集多個非流間接物件的選項，即所謂的“物件流”。這樣做的好處是可以壓縮流中的資料，否則無法壓縮這些物件。同時他們還引入了將交叉參考表資料放入流中的選項，即所謂的“交叉參考流”，也允許壓縮。

顯然，需要一種新的交叉參考條目型別來描述物件流中的間接物件，因此他們定義了這種型別的條目，但僅用于交叉參考流，而不用于舊的交叉參考表。

使用物件和交叉參考流存盤的 PDF 通常確實比存盤為具有交叉參考表的常規間接物件的相同 PDF 小得多。另一方面，不了解這些技術的 PDF 處理器根本無法打開這些 PDF。

因此，Adobe 提出了混合檔案的想法：包含 PDF 中的基本物件的檔案，需要以老式方式查看它，以及物件和交叉參考流中用于更新或可選功能的物件。交叉參考表的尾部包含一個指向交叉參考流的條目XRefStm 。

但是，由于某種原因，指定首先必須在交叉參考表中嘗試物件查找，并且只有在沒有找到相關物件編號的條目時，才搜索關聯的交叉參考流。

由于第一個交叉參考表需要涵蓋所用物件編號的完整范圍，因此這種查找策略意味著混合參考檔案需要第二個交叉參考表，其尾部可以指向將用于查找之前的交叉參考流最里面，第一個交叉參考表。

這就是我們在您的示例中看到的：

trailer
<</Size 47/Root 1 0 R/Info 15 0 R/ID[<EB3FF3A1E373C64E910E3FBC4E78913C><EB3FF3A1E373C64E910E3FBC4E78913C>] >>
startxref
106323
%%EOF
xref
0 0
trailer
<</Size 47/Root 1 0 R/Info 15 0 R/ID[<EB3FF3A1E373C64E910E3FBC4E78913C><EB3FF3A1E373C64E910E3FBC4E78913C>] /Prev 106323/XRefStm 105972>>
startxref
107421
%%EOF

實際上，大多數 PDF 制作者實作了混合參考檔案（如果他們這樣做的話），他們的印象是交叉參考流以及可能還有物件流應該在第一個預告片和第二個交叉參考表之間進行。但是沒有這個要求，MS Office 的 PDF 匯出選擇將所有流放在第一個交叉參考表之前。由于您的示例也是如此，我假設它們是由 MS Office 制作的。

標籤：文件pdf十六进制文件结构

上一篇：如何在影像繪制后創建pdfc#

下一篇：具有不同渲染類和合并的TCPDF