pdf文件中的ID字段是什么？

Question

我正在处理improving the pdf scrubber in the ApprovalTests framework 并查看simple pdf generated with PdfSharp 我看到它的内容如下。

有人知道底部的 ID 字段是什么吗？

%PDF-1.4
%ÓôÌá
1 0 obj
<<
/CreationDate(D:20131119194420-06'00')
/Creator(PDFsharp 1.32.3057-g \(www.pdfsharp.net\))
/Producer(PDFsharp 1.32.3057-g \(www.pdfsharp.net\))
>>
endobj
2 0 obj
<<
/Type/Catalog
/Pages 3 0 R
>>
endobj
3 0 obj
<<
/Type/Pages
/Count 1
/Kids[4 0 R]
>>
endobj
4 0 obj
<<
/Type/Page
/MediaBox[0 0 612 792]
/Parent 3 0 R
/Contents 5 0 R
/Resources
<<
/ProcSet [/PDF/Text/ImageB/ImageC/ImageI]
/ExtGState
<<
/GS0 6 0 R
>>
/Font
<<
/F0 8 0 R
>>
>>
/Group
<<
/CS/DeviceRGB
/S/Transparency
/I false
/K false
>>
>>
endobj
5 0 obj
<<
/Length 99
/Filter/FlateDecode
>>
stream
xœŠI
€@ïyE¼)¸ÄŒ^—«ðŽ
2"êÍ×)ènšº ER¢¿ÊŠq>t¡¼pA-t#áö@ÒªÄú¯À†ã¢R7#ç(ý~qîq:og½
endstream
endobj
6 0 obj
<<
/Type/ExtGState
/ca 1
>>
endobj
7 0 obj
<<
/Type/FontDescriptor
/Ascent 1005
/CapHeight 727
/Descent -210
/Flags 32
/FontBBox[-550 -303 1707 1072]
/ItalicAngle 0
/StemV 0
/XHeight 548
/FontName/Verdana,Bold
>>
endobj
8 0 obj
<<
/Type/Font
/Subtype/TrueType
/BaseFont/Verdana,Bold
/Encoding/WinAnsiEncoding
/FontDescriptor 7 0 R
/FirstChar 0
/LastChar 255
/Widths[1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 341 402 587 867 710 1271 862 332 543 543 710 867 361 479 361 689 710 710 710 710 710 710 710 710 710 710 402 402 867 867 867 616 963 776 761 723 830 683 650 811 837 545 555 770 637 947 846 850 732 850 782 710 681 812 763 1128 763 736 691 543 689 543 867 710 710 667 699 588 699 664 422 699 712 341 402 670 341 1058 712 686 699 699 497 593 455 712 649 979 668 650 596 710 543 710 867 1000 710 1000 332 710 587 1048 710 710 710 1777 710 543 1135 1000 691 1000 1000 332 332 587 587 710 710 1000 710 963 593 543 1067 1000 596 736 341 402 710 710 710 710 543 710 710 963 597 849 867 479 963 710 587 867 597 597 710 721 710 361 710 597 597 849 1181 1181 1181 616 776 776 776 776 776 776 1093 723 683 683 683 683 545 545 545 545 830 846 850 850 850 850 850 867 850 812 812 812 812 736 734 712 667 667 667 667 667 667 1018 588 664 664 664 664 341 341 341 341 679 712 686 686 686 686 686 867 686 712 712 712 712 650 699 650]
>>
endobj
xref
0 9
0000000000 65535 f 
0000000015 00000 n 
0000000180 00000 n 
0000000228 00000 n 
0000000283 00000 n 
0000000538 00000 n 
0000000707 00000 n 
0000000750 00000 n 
0000000935 00000 n
trailer
<<
/ID[<48189AA5E6D2394D8EF6E7842493B4A9><48189AA5E6D2394D8EF6E7842493B4A9>]
/Info 1 0 R
/Root 2 0 R
/Size 9
>>
startxref
2167
%%EOF

Answer 1

@Millie 的回答中添加到图片中的一些评论：

当对 PDF 的某些方面有疑问时，首先要看的是规范 ISO 32000-1。

它将ID条目指定为：

ID 数组（如果存在 Encrypt 条目则为必需；否则为可选；PDF 1.1）

由两个字节字符串组成的数组，构成文件的文件标识符（参见 14.4，“文件标识符”）。如果有 Encrypt 条目，则此数组和两个字节串应为直接对象且应未加密。

注意 1 由于 ID 条目未加密，因此可以检查 ID 密钥以确保在不解密文件的情况下访问正确的文件。字符串是直接对象而不是加密的限制确保这是可能的。

注意 2 虽然此条目是可选的，但它的缺失可能会阻止文件在某些​​依赖于唯一标识文件的工作流中运行。

注意 3 ID 字符串的值用作加密算法的输入。如果这些字符串是间接的，或者如果 ID 数组是间接的，则这些字符串在写入时将被加密。这将导致读取器出现循环条件：必须解密 ID 字符串才能使用它们来解密字符串，包括 ID 字符串本身。前面的限制阻止了这种循环条件。

（表 15 – 文件尾字典中的条目）

注 2 实质上是建议添加此可选值，即使它不是使用本文档其他地方应用的 SHALL/SHOULD/MAY 规范语言约定来制定的。

参考的第 14.4 节中的建议更加明确：

ID 条目是可选的，但应该使用。

由于这些规范中的应该表示推荐，推荐被定义为除非有充分的理由不这样做，否则必须做的事情，这意味着 PDF 编写者必须创建此条目，除非它可以反对该要求（我几乎想不出反对该要求的论据）。这应该回答针对米莉的回答提出的问题

知道为什么 PdfSharp 和 phantomjs 都会创建它吗？

尤其是不 只是被认为是好的做法，正如上面另一条评论中所假设的那样。

关于 ID 数组的内容，规范在第 14.4 节继续：

该条目的值应该是一个由两个字节字符串组成的数组。第一个字节字符串应是基于文件最初创建时的内容的永久标识符，并且在文件增量更新时不应更改。第二个字节字符串应是基于文件最后更新时的内容的变化标识符。首次写入文件时，应将两个标识符设置为相同的值。如果在解析文件引用时两个标识符匹配，则很可能已找到正确且未更改的文件。如果只有第一个标识符匹配，则已找到正确文件的不同版本。

为了帮助确保文件标识符的唯一性，它们应该通过消息摘要算法来计算...

文件标识符的计算不需要是可重现的；重要的是标识符可能是唯一的。

因此，first article Millie quoted from 在声明时并不完全正确

文件标识符（预告片字典中的 /ID 条目）。这是一个任意的字节串

ID 条目的值不是 字符串，而是两个字符串的数组。并且字符串值不是 任意，而是建议通过散列获得的唯一值。因此，它们尤其不得被重新用于不同的文档，如果它们只是任意的，那是可以的。

other article quoted from这个说法也不完全正确

如果要对文件进行加密，则仅需要生成 PDF 文件的程序来创建文件标识符。

即使不加密，该程序也必须有充分的理由不创建文件标识符，因为这是规范中的建议。因此，缺少这些原因， 需要一个程序来创建文件标识符。

话虽如此，任何 PDF 用户都必须准备好找到没有文件标识符的 PDF...毕竟可能有理由不创建它。

Answer 2

According to this article:

4. Append the file identifier (the /ID entry from the trailer
   dictionary).  This is an arbitrary string of bytes; Adobe
   recommends that it be generated by MD5 hashing various pieces
   of information about the document.

那是在谈论 PDF 的加密。 According to this article，只有加密时需要ID：

a program that makes PDF files is only required to create the file 
identifier if the file is to be encrypted.

This SO link also has some good info. 它声明 ID 只需要合理唯一，并提供特定的 ISO 编号以查找更多信息。

Answer 3

在PDF/A "Archival" standard (ISO 19005) 中，预告片 ID 似乎是强制，因此这可能是某些 PDF 生成器的考虑因素。