Java 从PDF复制粘贴在原始文件上是乱七八糟的，但在使用CutePDF打印PDF时已修复

有，是希腊文的。尝试从中复制和粘贴文本时会发生错误，导致轻微的乱码。我之所以说slight而不是total，是因为粘贴的输出在希腊语中没有意义，而是由有效的希腊字符组成。此外，问题的一个有趣方面是并非所有字符都映射错误。例如，如果您比较此原始文本条

ΕΞ. ΕΠΕΙΓΟΝ – ΑΜΕΣΗ ΕΦΑΡΜΟΓΗ
ΝΑ ΣΤΑΛΕΙ ΚΑΙ ΜΕ Ε-ΜΑIL

使用PDF中粘贴的内容：

ΔΞ. ΔΠΔΙΓΟΝ – ΑΜΔ΢Η ΔΦΑΡΜΟΓΗ
ΝΑ ΢ΣΑΛΔΙ ΚΑΙ ΜΔ Δ-ΜΑIL

您会注意到，一些字符粘贴正确，而其他字符则没有。还值得一提的是，错误的字符是反射性映射错误的，例如Ε变为Δ，反之亦然

当我使用Adobe打开PDF，并使用PDF writer（在本例中为CutePDF）打印时，复制和粘贴时的输出是正确的

鉴于上述情况，我的问题如下：

这种行为的根本原因是什么

对于随机导入的PDF文件，如何将解决方案集成到基于java的工作流中

编辑：一些打字错误

一些基本上下文：

在PDF中显示文本是通过从字体中选择字形来完成的。字形是一个或多个字符的视觉表示。字形选择是使用字符代码完成的。对于文本提取，您需要知道哪些字符与字符代码相对应

在这种情况下，这是通过使用ToUnicodeCMap实现的

在本文档中，文本片段的第一个字母E如下所示：

[0x01FC，…]TJ

ToUnicodeCMap包含以下条目：

4 beginbfrange
<01f9> <01fc> <0391>
...
endbfrange

4开始法兰
...
endbfrange

这意味着字符代码

0x01F9

，

0x01FA

，

0x01FB

和

0x01FC

分别映射到Unicode

U+0x391

，

U+0x392

，

U+0x393

和

U+0x394

是希腊增量Δ，在复制/粘贴时显示

使用字符代码

0x0204

绘制下一个字母。相关的ToUnicode条目是

，它将其正确映射到

---

所以，你会有点胡言乱语，因为只有一些Unicode映射是错误的。有时这是故意的，例如为了防止数据挖掘。我以前在财务报告中见过它。

你想做什么？我非常确定cutepdf使用的是UTF-8编码，而您所做的任何事情都可能是ASCII码。如果你想在windows中选择复制，你需要安装语言packI，我只是想最终解析它，但是保存一个正确的版本是另一个好处。设想一个基于java的解决方案，它提供PDF文件并解析输出，将其传递给下一个模块。应该处理utf-8这是一个编码问题。。。我猜你复制的应用程序与你粘贴到的应用程序有不同的编码有趣的部分是：（1）字体声称使用

/winansioncoding

，（2）文本存储为双字节码（与（1）结合起来让我抓狂），以及（3）我自己的PDF阅读工具，使用手头的规范编写，会产生与您和Adobe Acrobat本身完全相同的错误输出。我需要好好看看自己的源代码，才能回忆起这部分到底是如何工作的（在这种情况下，很糟糕）。CMap可以被替换吗？可以。使用PDF库提供对PDF对象的低级访问，只需遍历PDF结构、定位ToUnicode流并用新的流替换即可。挑战在于创建正确的ToUnicode地图。不能保证您可以构造一个通用的，可以在不同PDF文件中重用的文件。使用Adobe Reader打开并使用CutePDF打印（成功打印到文件，文本正常）2。使用Chrome打开并使用CutePDF打印（失败，打印到pdf基本上是图像）3。使用Java的CutepDF打印（创建与原始pdf完全相同的pdf）是不是Adobe Reader做了其他方法无法模仿的事情？您能否提供Open with Adobe Reader的输出并使用CutepDF打印？可能是固定或移除了ToUnicode。