【问题标题】:What is the Byte Order Mark preceding the magic number of this PDF?此 PDF 的幻数之前的字节顺序标记是什么?
【发布时间】:2020-10-22 08:11:47
【问题描述】:

我正在处理文件并使用幻数来识别文件类型的有效性。

我正在使用 Medsea mime-util JAR for Java 来调查幻数并确定 mime。这个库说明了它从左到右检查的两个不同的 PDF 序列:

  • 标准 PDF:%PDF-
  • 以 UTF-8 字节顺序标记 (BOM) 开头的 PDF:\xef\xbb\xbf%PDF-

如果 PDF 不以其中任何一个序列开头,则会被拒绝。

我收到了以下文件(见图片),它可以在 Acrobat 和其他查看器中有效打开;我不知道 %PDF- 之前的值的 Byte Order Mark (BOM) 是什么。

255044462D%PDF-

这是带有未识别 BOM 的 HEX 序列:

ACED0005757200025B42ACF317F8060854E0020000787000007CD4255044462D

这是一个有效的 BOM,如果是,我如何识别它?


更新

根据下面的答案,解决方案是检查上述序列的前 1024 个字符。我已经在 Medsea mime-util 库中解决了这个问题,方法是使用内联源代码详细信息的未记录功能更改 magic.mime 文件。

更改此条目:

0    string    %PDF-    application/pdf    ignore    pdf

如下:

0    string>1024    %PDF-    application/pdf    ignore    pdf

eu.medsea.mimeutil.detector.MagicMimeEntry.java 方法readBuffer(byte[]) for MagicMimeEntry.STRING_TYPE 的源代码中嵌入的注释中解释了此未记录的功能:

// The following is not documented in the Magic(5) documentation.
// This is an extension to the magic rules and is provided by this utility.
// It allows for better matching of some text based files such as XML files

随后的代码演示了从第 2 列的“类型”值解析 ># 部分,并使用 # 作为要搜索的缓冲区大小,从第 1 列的值指示的起始索引开始。

【问题讨论】:

  • @Kayaman,我将前面的字符添加为 HEX。
  • here,除了“标准PDF”之外的一切都是无效的。

标签: java pdf byte-order-mark magic-numbers


【解决方案1】:

阅读this answer 的相关主题:

根据 PDF 标准(ISO 32000-2,同样已经在 ISO 32000-1 中):

PDF 文件以 5 个字符“%PDF–”开头

(ISO 32000-2,第 7.5.2 节“文件头”)

特别是没有像 “UTF-8 编码的 PDF(前面带有 UTF-8 字节顺序标记)”这样的东西,已经表明 BOM 无效。

尽管如此,Adobe Reader 和其他 PDF 查看器以 PDF 格式打开带有一些前导任意垃圾字节的文件,而不会抱怨。发生这种情况是因为 Adob​​e Reader 明确地对规范松懈

Acrobat 查看器只要求标题出现在文件的前 1024 个字节内。

(Adobe PDF 参考第六版,附录 H.3“实施说明”,第 13 项)

和其他 PDF 查看器效仿。

因此,如果您想使用幻数来识别文件类型的有效性,如“根据规范有效”,您必须只接受以 5 个字符“%PDF”开头的文件 -”。另一方面,如果您想通过“在普通查看器中打开”来判断有效性,则必须接受在文件的前 1024 个字节中出现“%PDF-”的任何内容。 p>

更糟糕的是,

Acrobat 查看器也接受表单的标题

%!PS-Adobe-N.n PDF-M.m

(Adobe PDF 参考第六版,附录 H.3“实施说明”,第 14 项)

所以在这种情况下,您还必须在前 1024 个字节中接受这个序列...


我没有将您的问题作为引用答案的副本来结束,因为您似乎认为存在类似“UTF-8 编码的 PDF”之类的东西,某些 BOM 可能在前面有效“%PDF-” – 不,在这些标头字节前面不允许出现任何内容,无论是 UTF BOM 还是其他任何内容。

【讨论】:

  • "您似乎相信存在类似 UTF-8 编码的 PDF";这是相当虚伪的说法。我遇到过“狂野”的 PDF,它前面有确切的字符序列,它是基于 Java 的 Medsea MIME 解析库的一部分,但是我正在更改我的代码以考虑 1024 字节扫描和H.3 实现说明。
  • 是的。该文件是 PDF 并定义了自己的格式:看似文本但不是文本,它是二进制数据(基于 ASCII,但实际上是二进制数据)。嵌入字体的情况很复杂:有些是 Latin1(少数遗留字体),其余是基于 Unicode 的(没有人可以更改对此类字体的解释)。
  • 欢迎来到PDF 2.0...,其中允许此类“垃圾字节”:-/(参见 ISO/DIS 32000-2 - 7.5.2 文件头)
  • @JanSlabon 它们是不被允许的“PDF文件以5个字符“%PDF–”开始),注1 允许垃圾字节,它只是提示如何处理PDF,如果人们不想简单地处理这些字节(出于什么原因)碰巧有这样的前面的垃圾字节因为这个错误而拒绝他们。
  • “IIRC 这在 PDF Days 上也被宣传为“功能” - 任何人都很难将其宣传为功能,不是吗?
猜你喜欢
  • 1970-01-01
  • 2010-09-30
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-12-04
  • 2011-10-30
相关资源
最近更新 更多