PowerShell，itextsharp提取的文本不再具有可读性(脚本以前很好)

Question

我使用PowerShell脚本和itextsharp从记帐PDF中提取一些数据，以组织was服务器数据库上的重命名文件(带有提取的数据).

直到最近，一切都很顺利：

提取的文本不再具有可读性，我的符号如下

!9H#SH!#!T !a!ST^ET
8%’?E!8A8A,A ;B;0D3FD
U+.0’$=Q$;L?L\$’($4-R$2’$4+(.’R.-./+($D$
%M%G.T

​

我想这与会计软件更新后的一种新的编码方式有关。

下面这样一个简单的脚本正在工作

function convert-PDFtoText {
    param(
        [Parameter(Mandatory=$true)][string]$file
    )   
    Add-Type -Path "C:\PathTo\itextsharp.dll"
    $pdf = New-Object iTextSharp.text.pdf.pdfreader -ArgumentList $file
    for ($page = 1; $page -le $pdf.NumberOfPages; $page++){
        $text=[iTextSharp.text.pdf.parser.PdfTextExtractor]::GetTextFromPage($pdf,$page)
        Write-Output $text
    }   
    $pdf.Close()
}

$file = "C:\ADA3_FA20210274.pdf"

convert-PDFtoText $file

它不适用于那些新的PDF文件。

如果有人能告诉我如何处理这件事，我将不胜感激。

我使用了它的5.5.13.2

编辑：

这里有一个指向其中一个PDF :exemple.pdf的链接

Answer 1

总之

正如pdftotext.exe已经指出的，Unicode CMap中存在非法条目。更确切地说，格式字体的ToUnicode映射中的所有条目都是无效的。因此，如果文本提取器不能从文档中提取文本，那么它就不是一个bug。不过，有些解析器显然是以忽略错误的方式解析映射的。

细部

pdf首先是为PDF查看器制作的，因此pdf中的字体定义只需提供来自文本字符串参数中使用的代码的映射，这些代码显示对字形绘图定义的指令，例如嵌入在pdf中的ttf流中。特别是，他们不需要提供从这些代码到Unicode字符的映射。因此，PDF正确显示并不意味着可以从中提取文本。

PDF可以在所谓的ToUnicode映射中提供从这些代码到Unicode字符的映射。如果你的PDF，这样的地图提供，但他们都是破碎的。

这些文本格式的映射应该包含一个codespacerange节，该节定义代码的性质，特别是单个字节还是多个字节构成单个字形的代码。然后，在、bfchar、和bfrange节中，单个代码或代码范围分别映射到单个Unicode字符串或其范围。代码和Unicode字符串以角括号中的十六进制表示法表示。

在你的PDF中，这些地图被破坏了。例如，在字体为codespacerange 1的情况下，定义为

1 begincodespacerange
<00> <FF>
endcodespacerange

即从0x00到0xFF的单字节代码。这是正确的，字体是一个简单的字体，因此，只能有单字节码。但是..。

然后，该字体只使用bfchar节来映射这些代码：

66 beginbfchar
<0021> <0032#1>
<0022> <0036#1>
<0023> <0030#1>
<0024> <0020#1>
<0025> <0041#1>
<0026> <0076#1>
...
<005D> <0025#1>
<005E> <002C#1>
<005F> <004B#1>
<0060> <0062#1>
<0061> <00A0#1>
<0062> <0044#0>
endbfchar

这部分的条目都被打破了！

一方面，根据上面的codespacerange，我们只有单字节码，但这里只有双字节码<0021>、<0022>等的映射。由于代码范围也可能是混合长度，所以必须认真对待代码长度，因此所有这些双字节条目都不能用于文本提取，因为字体不使用任何双字节代码。

另一方面，这些映射的所有值都被破坏，因为它们包含非法的部分#1或#0。在这里，解析器可以立即忽略条目，因为它不清楚这意味着什么。

因此，许多文本提取器忽略这些映射，默认返回代码。在许多PDF中，代码实际上是一些常见的ASCII‘’ish编码，因此这种默认编码是有意义的。然而，在你的PDF中，字体编码不是，它们是不同的，非标准的，临时的编码。所以你只是胡说八道。

从PDF中提取想要的文本的PDF查看器忽略了上面的错误，在其他情况下，这些错误可能会导致他们在更严格的提取器提取合理信息的情况下提取胡言乱语。

因此，您应该告诉更新的会计软件的维护人员他们的PDF中的错误，并要求他们修复这个错误。