Question

我有一个pdf文件，我从中提取文本时遇到问题 - 使用itextsharp api。

其中一些数字被其他数字或反斜杠替换：“//”

pdf文件最初来自MS Word并使用“另存为pdf”导出为pdf，我必须使用pdf文件而不是文档。

当您尝试从文件中复制并粘贴某些数字时，可以非常清楚地看到问题例如 - 如果您尝试复制并粘贴底部的6位数字，则可以看到它从201333更改为333222。

您还可以看到日期字符串的问题：11/4/2016变为// // 11110

当我在计算机上使用adobe Pdf转换器打印机打印pdf文件时，它会得到修复，但我需要自动修复它，例如使用C＃

由于

Answer 1

简而言之

iTextSharp文本提取结果正好反映了PDF声称有问题的字符的含义。因此，PDF规范（依赖于这些信息）建议的文本提取总是会返回此。

嵌入字体包含不同的信息。因此，不相信这些信息的文本提取方法可能会返回更令人满意的结果。

更详细

首先，你说

我有一个pdf文件，我从中提取文本时遇到问题 - 使用itextsharp api。

所以使它听起来像iTextSharp特定的问题。不过，稍后会说明

当您尝试复制并粘贴文件中的某些数字时，您可以非常清楚地看到问题

如果您还可以看到复制和粘贴问题，则不 特定于iTextSharp的问题，但问题是多个问题PDF处理器，包括您复制和粘贴的查看器，或者它只是您拥有的PDF的问题。

事实证明，它是后者，你有一个关于其内容的PDF。

例如，让我们看看你指出的文字：

例如 - 如果您尝试复制并粘贴底部的6位数字，则可以看到它从201333更改为333222.

检查PDF页面内容流，您将找到这些指令生成的六位数字：

/F3 11.04 Tf
...
[<00150013>-4<0014>8<00160016>-4<0016>] TJ

即。选择字体 F3 （使用 Identity-H 编码，因此每个字形由两个字节表示）并且绘制的字形是从左到右：

PDF中字体 F3 的 ToUnicode 映射声明：

1 beginbfrange
<0013> <0016> [<0033> <0033> <0033> <0032>]
endbfrange

即。它说

因此，根据 ToUnicode 地图，使用上述说明绘制的字形字符串代表333222。

PDF规范将 ToUnicode 映射作为将字符代码映射到Unicode值的最高优先级方法。因此，根据规范工作的文本提取器将在此处返回333222。