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

Question

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

谢谢。

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

Answer 1

究其原因，是箭是该文件实际上试图误导文本提取其按照第9.10.2准则提取文本映射字符代码Unicode值 PDF规范的ISO 32000-1，而不是混淆那些喜欢使用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 <</MCID 14 >>BDC 
BT
/T1_1 1 Tf
10 0 0 10 89.5488 750.2834 Tm
(2)Tj
/Span<</ActualText<FEFF0033>>> BDC 
(3)Tj
EMC 
(412109 )Tj
ET
EMC 

如您所见，'3'标记有ActualText条目，表明它确实<FEFF0033>是3（表示Unicode数字3的路很长）。

另一方面，字体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是该字符的Unicode十六进制值，<control>在Unicode 6.0字符表中被归类为“控制字符”。

<control>在旧版本的Unicode中，“ ”以前被称为“ CANCEL”。

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

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