我正在努力改进ApprovalTests框架中的pdf scrubber并查看使用PdfSharp生成的简单pdf我看到它的内容如下.
有谁知道底部的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
一些评论从@Millie的回答中添加到图片中:
如果对PDF的某些方面有疑问,首先要看的是ISO 32000-1规范.
它将ID条目指定为:
ID数组(如果存在加密条目,则为必需;否则为可选; PDF 1.1)
一个由两个字节串组成的数组,构成文件的文件标识符(参见14.4,"文件标识符").如果有一个加密条目,那么这个数组和两个字节串应该是直接对象,并且应该是未加密的.
注1:由于ID条目未加密,因此可以检查ID密钥以确保在不解密文件的情况下访问正确的文件.字符串是直接对象而不是加密的限制可确保这是可能的.
注2:尽管此条目是可选的,但它的缺失可能会阻止文件在依赖于唯一标识文件的某些工作流中运行.
注3:ID字符串的值用作加密算法的输入.如果这些字符串是间接的,或者如果ID数组是间接的,则这些字符串在写入时将被加密.这将导致读者的循环条件:必须解密ID字符串,以便使用它们来解密字符串,包括ID字符串本身.上述限制可防止此循环条件.
(表15 - 文件预告片典中的条目)
上面的注2实质上是建议添加这个可选值,即使它没有使用本文档中其他地方应用的SHALL/SHOULD/MAY规范语言约定.
建议在引用的第14.4节中更明确:
ID条目是可选的,但应该使用.
至于应该在这些规范代表建议,建议被定义为一些不得不做的,除非有充分的理由不,这意味着一个PDF作家有创建该条目,除非它可以反驳的要求(我很难想到的反对使用的论据).这应该回答米莉回答的问题
任何想法为什么PdfSharp和phantomjs创造它？
特别是它不 只是好的做法是假设在另一个上面的注释.
关于ID数组的内容,规范在第14.4节继续:
该条目的值应为两个字节字符串的数组.第一个字节字符串应该是基于文件最初创建时的内容的永久标识符,并且在文件逐步更新时不应更改.第二个字节字符串应该是基于文件上次更新时的内容的更改标识符.首次写入文件时,两个标识符应设置为相同的值.如果解析文件引用时两个标识符都匹配,则很可能找到了正确且未更改的文件.如果只有第一个标识符匹配,则找到正确文件的不同版本.
为了帮助确保文件标识符的唯一性,应通过消息摘要算法计算它们...
文件标识符的计算不需要是可再现的; 重要的是标识符可能是唯一的.
文件标识符(预告片字典中的/ ID条目).这是一个任意字节串
所述的值ID条目是不 字符串而是两个字符串的数组.并且字符串值不是 任意的,而是建议通过散列获得的唯一值.因此,特别是它们不能被重复用于不同的文件,如果它们只是任意的话就可以.
只有在要加密文件时,才需要创建PDF文件的程序来创建文件标识符.
即使不加密,该程序也必须有充分的理由不创建文件标识符,因为它是规范中的建议.缺乏这样的理由,因此,节目被 需要来创建该文件标识符.
总而言之,任何PDF消费者总是必须准备好找到没有文件标识符的PDF ......毕竟可能有理由不创建它.