itext读取pdf 1s作为向上箭头ERROR

出于某种原因，itextsharp现在正在读取pdf，其中包含诸如4123之类的数字为4 * 23，其中*实际上是指向上方的箭头。 不知道为什么会这样。 请帮忙。

谢谢。

示例文件位于： https ： //dl.dropboxusercontent.com/u/116833/SAMPLE%20PDF.pdf

Answer 1

箭头的原因是该文件实际上试图误导文本提取器，该文本提取器根据第9.10.2节将字符代码映射到 PDF规范ISO 32000-1的 Unicode值的指导提取文本，同时不会混淆那些更喜欢标有的ActualText的文本 -内容序列条目：前一种方法是导致相信’3’是箭头而后者被告知’3’是三分。

最有可能这样做是为了防止自动文本提取，同时允许手动复制和粘贴，因为Adobe Reader确实更喜欢ActualText标记内容序列条目（因此，手动提取可以正常工作），而许多程序提取器更喜欢前一种方法。

就我阅读规范的相关部分而言，它不会优先于另一部分。

细节

比如看第一部分编号：

BT /T1_1 1 Tf 10 0 0 10 69.1456 750.2834 Tm (1 )Tj ET EMC /Span <>BDC BT /T1_1 1 Tf 10 0 0 10 89.5488 750.2834 Tm (2)Tj /Span<>> BDC (3)Tj EMC (412109 )Tj ET EMC 

如您所见，’3’标有一个ActualText条目，表明它确实是三个（ 指示Unicode数字三是很长的路径）。

另一方面，字体T1_1提供包含映射的ToUnicode流

 ... <30> <0030> <31> <0031> <32> <0032> <33> <0018> <34> <0034> <35> <0035> ... 

正如你所看到的那样，当其他数字（0x30为’0’，0x31为’1’，……，0x39为’9’）被相同地映射时，’3’，即0x33，被映射到Unicode代码点0x0018，和

U + 0018是字符的Unicodehex值，在Unicode 6.0字符表中被归类为“控制字符”。

“ ”之前在旧版本的Unicode中命名为“CANCEL”。

（参见http://www.marathon-studios.com/unicode/U0018/Control ）

在某些上下文中，此控制字符显示为向上箭头。