我正在研究用于PDF(文本提取)的解析器。

当需要对页面进行平面解码(通过zlib压缩)时，我的代码能够解压缩内容流，然后输出(流对象)，如下所示：

我对字符串数组(TJ的操作数)感兴趣。

此数组中似乎包含多个十六进制编码的字符串，但是相应的十六进制值没有意义。而是出现了像010203这样的序列...有点lz77压缩。

在开始这样一个雄心勃勃的项目之前，您应该使自己熟悉完整的官方PDF-1.7规范。请注意：这是756页的文档，它引用了约90个其他文档，对于PDF来说，它也被称为"规范"。

您将学到，为了将PDF源代码反向转换为文本内容，必须反向应用字体使用的编码。可以使用5种规范定义的标准编码：

最重要的是，还可以有一个CustomEncoding(当嵌入字体是子集时不起作用，它不包含字体定义的所有字形，而仅包含文档所需的那些字形)。如果PDF内定义了/ToUnicode表，则只能反转CustomEncode-d文本。只有这样，您才可以将编码的字符反向映射到字符名称。

您还将学到，不仅有一个，而且有四个可用于显示文本字符串的运算符：

此外，有三种不同的方式来表示文本字符串。这里以字符串" string"为例：

文本提取器的问题如下：

使用可打印的ASCII字符(上面的1.)和八进制字符代码(上面的2.)可以混合使用。以下所有内容也是字符串" string"的"合法"表示形式(列表不完整！)：

使用十六进制编码的字符代码(上面的3.)也不是一件容易的事，因为以下所有表示形式都是等效的：

有关PDF规范允许的更多怪异(或Adobe观看者可以容忍的怪异)，另请参见例如：

我本人最近创建了一系列手工编码的PDF文件，这些文件演示了丢失，不正确，已操纵或正确的/ToUnicode表如何影响任何PDF到文本反转的结果： 为什么文本提取不适用于所有PDF (该资料库以手工编码的PDF形式包含更多研究材料，突出显示了PDF语法的其他部分和运算符。)

最后，查看OP提供的一小段PDF源代码：

BT和ET表示显示段

的文本的开头和结尾

56.8 721.3 Td将当前点定位到坐标"水平为56.8点，垂直为721.3点"。

12 Tf将字体大小设置为12点。

/F1将要使用的字体设置为PDF文档中其他位置定义的字体。该字体还在某处设置了字体编码(可能还有一个/ToUnicode表)。当在文本字符串中看到特定的字符代码时，字体编码将确定应绘制哪种字形形状。

[22-102-221]TJ

最后一部分可以分为以下几个部分：

单个字形定位：单个字形定位的工作方式如下：

字符代码的含义：要知道第一个，第二个，第三个，...最后一个字符代码的含义，您必须在PDF的/ToUnicode表中查找这些字符。如果它没有嵌入这样的表，那么运气不好！

检查文本的易提取性：要检查您的PDF是否很容易进行文本提取，可以使用命令行工具pdffonts。这是示例输出：

在上述示例情况下，子集字体SSKFGJ+ArialMT使用自定义编码，但PDF对此字体没有/ToUnicode，如标题为uni的列所示。因此，要提取使用该字体显示的文本并不容易(提取需要手动进行反向工程-但您也可以仅"阅读" PDF页面)。

Abhishek，

这不是一个简单的问题，不幸的是，它表明您尚未阅读PDF规范。您应该这样做。

您可以在此处下载Acrobat SDK： http://www.adobe.com/devnet/acrobat/sdk/eula.html

其中一部分是PDF规范，这是一个非常繁重的文档，解释了PDF的来龙去脉(包括对问题的回答)。

简而言之-而不是代替阅读文档-您正在寻找的是/ F2 12 Tf命令设置的字体编码中的字符值，该命令设置随后写入文本时使用的特定字体。