使用 itextSharp 更改数字从 pdf 中提取文本
Extracting text from pdf using itextSharp changes digits
我有一个 pdf 文件，我在使用 itextsharp 从中提取文本时遇到问题 api。
一些数字被其他数字或反斜杠替换：“//”
pdf 文件最初来自 MS Word，并使用 "Save as pdf" 导出为 pdf，我必须使用 pdf 文件而不是文档。
当您尝试从文件中复制并粘贴一些数字时，您可以非常清楚地看到问题
例如 - 如果您尝试在底部复制并粘贴一个 6 位数字，您会看到它从 201333 变为 333222。
您还可以看到日期字符串的问题：11/4/2016 变成 // // 11110
当我在我的计算机上使用 adobe Pdf converter 打印机打印 pdf 文件时，它得到修复，但我需要自动修复它，例如使用 C#
谢谢
文件在此处共享：
https://www.dropbox.com/s/j6w9350oyit0od8/OnePageGili.pdf?dl=0
简而言之
iTextSharp 文本提取结果准确反映了 PDF 声明的相关字符的含义。因此，PDF 规范（依赖于这些信息）推荐的文本提取总是 return this.
嵌入的字体包含不同的信息。因此，不相信此信息的文本提取方法可能 return 更令人满意的结果。
更详细
首先你说
I have a pdf file which I have a problem extracting text from it - using an itextsharp api.
所以让它听起来像是一个特定于 iTextSharp 的问题。不过，稍后您会说
You can see the problem very clearly when you try to copy and paste some numbers from the file
如果您也可以看到复制和粘贴的问题，那是不是 iTextSharp 特定的问题，而是多个 PDF 的问题处理器，包括您复制和粘贴的查看器，或者这只是您拥有的 PDF 的问题。
事实证明，它是后者，你有一个关于其内容的 PDF。
例如，让我们看一下您指出的文本：
For example - if you try to copy and paste a 6 digit number in the bottom you can see that it changes from 201333 to 333222.
检查 PDF 页面内容流，您会发现这些指令生成的那六位数字：
/F3 11.04 Tf
...
[<00150013>-4<0014>8<00160016>-4<0016>] TJ
即字体 F3 被选中（使用 Identity-H 编码，因此每个字形由两个字节表示）并且绘制的字形从左到右：
0015
0013
0014
0016
0016
0016
PDF 中字体 F3 的 ToUnicode 映射现在声明：
1 beginbfrange
<0013> <0016> [<0033> <0033> <0033> <0032>]
endbfrange
即它说
- glyph 0013代表Unicode代码点0033，数字
3
- glyph 0014代表Unicode代码点0033，数字
3
- glyph 0015代表Unicode代码点0033，数字
3
- glyph 0016代表Unicode代码点0032，数字
2
因此根据ToUnicode映射，使用上述指令绘制的字形字符串表示333222。
PDF 规范将 ToUnicode 映射作为将字符代码映射到 Unicode 值的最高优先级方法。因此，根据规范工作的文本提取器将 return 333222 here.
我有一个 pdf 文件，我在使用 itextsharp 从中提取文本时遇到问题 api。
一些数字被其他数字或反斜杠替换：“//”
pdf 文件最初来自 MS Word，并使用 "Save as pdf" 导出为 pdf，我必须使用 pdf 文件而不是文档。
当您尝试从文件中复制并粘贴一些数字时，您可以非常清楚地看到问题 例如 - 如果您尝试在底部复制并粘贴一个 6 位数字，您会看到它从 201333 变为 333222。
您还可以看到日期字符串的问题：11/4/2016 变成 // // 11110
当我在我的计算机上使用 adobe Pdf converter 打印机打印 pdf 文件时，它得到修复，但我需要自动修复它，例如使用 C#
谢谢
文件在此处共享： https://www.dropbox.com/s/j6w9350oyit0od8/OnePageGili.pdf?dl=0
简而言之
iTextSharp 文本提取结果准确反映了 PDF 声明的相关字符的含义。因此，PDF 规范（依赖于这些信息）推荐的文本提取总是 return this.
嵌入的字体包含不同的信息。因此，不相信此信息的文本提取方法可能 return 更令人满意的结果。
更详细
首先你说
I have a pdf file which I have a problem extracting text from it - using an itextsharp api.
所以让它听起来像是一个特定于 iTextSharp 的问题。不过，稍后您会说
You can see the problem very clearly when you try to copy and paste some numbers from the file
如果您也可以看到复制和粘贴的问题，那是不是 iTextSharp 特定的问题，而是多个 PDF 的问题处理器，包括您复制和粘贴的查看器，或者这只是您拥有的 PDF 的问题。
事实证明，它是后者，你有一个关于其内容的 PDF。
例如，让我们看一下您指出的文本：
For example - if you try to copy and paste a 6 digit number in the bottom you can see that it changes from 201333 to 333222.
检查 PDF 页面内容流，您会发现这些指令生成的那六位数字：
/F3 11.04 Tf
...
[<00150013>-4<0014>8<00160016>-4<0016>] TJ
即字体 F3 被选中（使用 Identity-H 编码，因此每个字形由两个字节表示）并且绘制的字形从左到右：
0015
0013
0014
0016
0016
0016
PDF 中字体 F3 的 ToUnicode 映射现在声明：
1 beginbfrange
<0013> <0016> [<0033> <0033> <0033> <0032>]
endbfrange
即它说
- glyph 0013代表Unicode代码点0033，数字
3 - glyph 0014代表Unicode代码点0033，数字
3 - glyph 0015代表Unicode代码点0033，数字
3 - glyph 0016代表Unicode代码点0032，数字
2
因此根据ToUnicode映射，使用上述指令绘制的字形字符串表示333222。
PDF 规范将 ToUnicode 映射作为将字符代码映射到 Unicode 值的最高优先级方法。因此，根据规范工作的文本提取器将 return 333222 here.