java - 使用 iText 解析 PDF 文档后反转希伯来语或数字

Question

我正在使用 iText5 来解析主要用希伯来语编写的 pdf。
为了提取文本，我使用 PdfTextExtractor.getTextFromPage。我没有找到更改库中编码的方法，并且文本显示为乱码。

我尝试像这样修复编码:
new String(pdfPage.getBytes(Charset1), Charset2)。
我使用 Charset.availableCharsets() 浏览了所有可能的字符集，其中很少有给我希伯来语而不是乱码，但相反。

现在我想我可以逐行反转文本，但希伯来语是从右到左，数字和英语是从左到右。因此，如果我反转该行，它会修复希伯来语，但会破坏数字/英语。

示例:

PdfTextExtractor.getTextFromPage 返回 87.55 úåáééçúä ééåëéð ë"äñ

new String(text.getBytes(Charset.forName("ISO-8859-1")), Charset.forName("windows-1255")) 返回 87.55 ”

如果我反转这个，那么我会得到סה"כ נйכוй התחבות 55.78​ ​

该数字应该是 87.55 而不是 55.78

我发现的唯一解决方案是将其拆分为希伯来语和其余部分(英语/数字)，并仅反转希伯来语部分，然后将其合并回来。

有没有更简单的解决方案？我觉得我在编码/RTL 方面遗漏了一些东西

Answer 1

I cant share the document I'm working on because it contains PII. But after searching Goole for pdf with gibberish, I found this document - the last paragraph of the document has exactly the same problem I have in my documents.

我只能分析给定的数据，因此在这种情况下只能分析链接的政府文件

提取为

ìëéî ìù "íééç éøåùéë" øôñá ,äéãôåìòôäá íéáø úåðåéòø ãåò àåöîì ïúéð 􀂛
.ãåòå úéëåðéçä äééæëøîá ,567 'îò ,ïîöìæ éìéðå ì÷ðøô äéæø ,ïîæåø

在这种情况下，输出乱码的原因很简单:PDF声称这个乱码确实是那里的文本!

因此，问题不在于文本提取器，无论是 iText PdfTextExtractor、Adobe Reader 复制和粘贴还是其中任何一个。相反，问题在于文档的内容存在谎言

更详细

本段使用的字体TT1有一个ToUnicode条目，具有以下映射:

28 beginbfchar
<0003> <0020>
<0005> <0022>
<000a> <0027>
<000f> <002C>
<0011> <002E>
<001d> <003A>
<0069> <00E1>
<006a> <00E0>
<006b> <00E2>
<006c> <00E4>
<006d> <00E3>
<006e> <00E5>
<006f> <00E7>
<0070> <00E9>
<0071> <00E8>
<0074> <00ED>
<0075> <00EC>
<0078> <00F1>
<0079> <00F3>
<007a> <00F2>
<007b> <00F4>
<007c> <00F6>
<007e> <00FA>
<007f> <00F9>
<0096> <00E6>
<0097> <00F8>
<00ab> <00F7>
<00d5> <00F0>
endbfchar
3 beginbfrange
<0018> <001a> <0035>
<0072> <0073> <00EA>
<0076> <0077> <00EE>
endbfrange 

即所有代码都映射到 U+0020 和 U+00F9 之间的 Unicode 值，这是一个 Unicode 范围，其中显然不存在屏幕截图中看到的希伯来字符。更准确地说:除了空格、一些标点符号和数字(正确提取的)之外，这些值都在 U+00E0 和 U+00F9 之间的范围内，这是带有重音符号的拉丁字母及其类似位置的区域。

您提到在某些情况下您可以通过应用检索希伯来语文本

new String(text.getBytes(Charset.forName("ISO-8859-1")), Charset.forName("windows-1255"))

因此，PDF 创建工具可能已将 Windows-1255 代码页的映射放入 ToUnicode 映射中。这显然是错误的，ToUnicode 映射必须包含到 Unicode 的映射。

<小时/>

话虽如此，即使 ToUnicode 映射是正确的，您仍然必须与反向希伯来语输出作斗争。这确实是 iText 5.x 文本提取的限制，它没有对 RTL 语言的特殊支持。因此，您必须自己更改结果字符串中字符的顺序。

在 this answer您将找到此类重新排序方法的示例。它适用于阿拉伯语脚本，采用 C# 语言，但它清楚地显示了如何继续。