解码 PDF 文档中的 FlateDecoded 文本部分

Question

使用peepdf我正在分析两个简单的 pdf 文件。这两个文件都包含一行文本（“ZYXWVUTSRQQRSTUVWXYZ”）并且是在 Mac OS X 上创建的。

第一个文件是用 TextEdit 创建的。只有三个流，看第一个（用peepdf自动解码）可以清楚地显示文本。

PPDF> stream 4

q Q q 72 707.272 468 12.72803 re W n /Cs1 cs 0 sc q 0.9790795 0 0 -0.9790795 72 720
cm BT 0.0001 Tc 11 0 0 -11 5 10 Tm /TT1 1 Tf (ZYXWVUTSRQQRSTUVWXYZ) Tj ET
Q Q

第二个文件是用 MS Word 创建的。有四个流，但无法找到解码的文本。查看 Word 文档中的相应流不会显示解码的字符串：

PPDF> stream 4

q Q q 18 40 576 734 re W n /Cs1 cs 0 0 0 sc q 0.24 0 0 0.24 90 708.72 cm BT
-0.0004 Tc 50 0 0 50 0 0 Tm /TT2 1 Tf [ (!") -1 (#) -1 ($) -1 (%&'\() -1 (\))
-1 (*) -1 (*) -1 (\)) -1 (\() -1 ('&%$) -1 (#) -1 (") -1 (!) ] TJ ET Q q 0.24 0 0 0.24 239.168 708.72
cm BT 50 0 0 50 0 0 Tm /TT2 1 Tf (+) Tj ET Q Q

我不清楚字符串在文件中的哪个位置或此流中的信息意味着什么。任何见解？

Answer 1

我不清楚字符串在文件中的位置

一般来说，您不会在内容流中看到明文，因为那里使用的编码不需要标准编码，没有 ASCII 之类的。

[ (!") -1 (#) -1 ($) -1 (%&'\() -1 (\)) -1 (*) -1 (*) -1 (\)) -1 (\() -1 ('&%$) -1 (#) -1 (") -1 (!) ] TJ

此操作在其数组操作数中包含您ZYXWVUTSRQQRSTUVWXYZ对某些字符对进行一些字距调整。

它看起来像是使用从 33 (= 0x21 = '!') 开始的字节的临时编码。'！用于需要的第一个字形，Z， '"' 用于第二个需要Y， '#' 用于第三个X等。您的测试字符串不仅以这些字符开头，还以它们结尾，等等上面的阵列，(!") -1 (#)... (#) -1 (") -1 (!)。

检查所用字体的定义 ( TT2 )。它可能（也可能不）包含帮助您解码此编码的信息。

或者这个流中的信息是什么意思。任何见解？

要了解 PDF 内容流的内容，您应该阅读 PDF 规范ISO 32000-1的相关部分，尤其是第 8 章图形和第 9章文本。

由于您的问题集中在文本内容的识别上，例如阅读 9.10.2 Mapping Character Codes to Unicode Values 部分：

符合标准的阅读器可以使用这些方法，按照给定的优先级，将字符代码映射到 Unicode 值。带标签的 PDF 文档尤其应提供以下方法中的至少一种（参见 14.8.2.4.2，“带标签的 PDF 中的 Unicode 映射”）：

• 如果字体字典包含ToUnicode CMap（请参阅 9.10.3，“ToUnicode CMap”），则使用该 CMap 将字符代码转换为 Unicode。

• 如果字体是使用预定义编码MacRomanEncoding、MacExpertEncoding或WinAnsiEncoding之一的简单字体，或者其编码的Differences数组仅包含取自 Adob​​e 标准拉丁字符集的字符名称和 Symbol 中的命名字符集字体（见附件 D）：

  a) 根据表 D.1 和字体的差异数组将字符代码映射到字符名称。

  b) 在Adobe Glyph List（见参考书目）中查找字符名称以获取相应的 Unicode 值。

• 如果字体是使用表 118 中列出的预定义 CMap 之一（Identity–H 和 Identity–V 除外）或其后代 CIDFont 使用 Adob​​e-GB1、Adobe-CNS1、Adobe-Japan1 或 Adob​​e-Korea1 的复合字体人物收集：

  a) 根据字体的 CMap 将字符代码映射到字符标识符 (CID)。

  b) 从其CIDSystemInfo字典中获取字体的 CMap（例如，Adobe 和 Japan1）使用的字符集合的注册表和排序。

  c) 通过以registry–ordering –UCS2格式（例如，Adobe–Japan1–UCS2）连接在步骤(b) 中获得的registry 和ordering 来构造第二个CMap 名称。

  d) 使用步骤 (c) 中构造的名称获取 CMap（可从 ASN 网站获得；参见参考书目）。

  e) 根据步骤(d)中得到的CMap映射步骤(a)中得到的CID，产生一个Unicode值。

注意 Type 0 字体的后代 CIDFonts 使用 Adob​​e-GB1、Adobe-CNS1、Adobe-Japan1 或 Adob​​e-Korea1 字符集（如 CIDSystemInfo 字典中指定的）应具有对应于符合标准的 PDF 版本的补充编号读者。有关与给定 PDF 版本相对应的字符集列表，请参见表 3。（可以使用这些字符集的其他补充，但如果补充的编号比支持的 PDF 版本对应的编号大，则只有后一个补充中的 CID 被认为是标准 CID。）

如果这些方法无法生成 Unicode 值，则无法确定字符代码代表什么，在这种情况下，符合要求的读者可以选择他们选择的字符代码。

编辑： 关于评论

其中一个对象提供了一些字体信息。它是“JJOWGO+Cambria”并将对象 16 引用为“字体文件”，这也是不可读的。我会查看手册。在网上找不到关于“JJOWGO”的任何信息。

您不会找到任何特定的内容，JJOWGO因为它很可能是一个随机键序列，前缀为Cambria以指示并非所有该字体都被嵌入，而只是一个子集。参见 部分9.6.4字体子的ISO 32000-1：

PDF 文档可能包含 Type 1 和 TrueType 字体的子集。描述字体子集的字体和字体描述符与普通字体略有不同。这些差异允许符合要求的阅读器识别字体子集并合并包含相同字体的不同子集的文档。（有关字体描述符的更多信息，请参阅 9.8，“字体描述符”。）

对于字体子集，字体的 PostScript 名称（字体的BaseFont条目和字体描述符的FontName条目的值）应以标签开头，后跟加号 (+)。标签应由正好六个大写字母组成；字母的选择是任意的，但同一PDF文件中的不同子集应具有不同的标签。

示例 EOODIA+Poetica 是 Poetica®（一种 Type 1 字体）子集的名称。

 <<
 /FontBBox [ -1475 -2463 2867 3117 ]
 /StemV 0
 /FontFile2 16 0 R
 /Descent -222
 /XHeight 467
 /Flags 4
 /Ascent 950
 /FontName /JJOWGO+Cambria
 /Type /FontDescriptor
 /ItalicAngle 0
 /AvgWidth 615
 /MaxWidth 2919
 /CapHeight 667
 >>

此字体描述符不包含明显的编码信息。查看实际的字体字典并查找ToUnicode条目，参见。上文第 9.10.2 节的引述。