我们已经在我们的应用程序中通过activex控件阅读和编写粘滞便笺/注释/注释多年。我们最近使用Unicode支持升级到Delphi2009。以下是造成问题的原因。
当我们打电话时
CAcroPDAnnot.GetContents
结果似乎很奇怪，我们丢失了我们的Unicode字符。它不像保存为ansi字符串，通常会导致返回?????相反，我们得到一个字符串，如
，ES，“ú,É•-z×，ð,Ð，¢，½,ç
对于一串日文字符。
但是，如果我通过pdf本身的菜单将pdf中的注释保存到数据文件中，则会将其写入文件，如
0kL0Oeå0k~¨ª0'0r0D0_0‰
后者可以导出并重新导入到acrobat pdf中，并将重新创建正确的unicode字符。但是，一旦我在我的代码中调用CAcroPDAnnot.GetContents，它就会以其他方式返回。
由于
答案 0 :(得分：2)
，ES，“ú,É•-z×，ð,Ð，¢，½,ç
那是字符串：
に行く日に风邪をひいたら
在CP-932又名Shift-JIS编码中，这是日本一种可怕但仍然很受欢迎的编码。
您目前正在将其解释为CP-1252（Windows西欧）。如果您的PDF阅读组件不会自动为您转换，您需要找到一种方法来检测文档的编码并手动转换。
我不知道Delphi为读取编码提供了什么，但您是否已从Windows控制面板中获得了安装在Shift-JIS中的编码 - ＆gt;区域选项 - ＆gt; “为东亚语言安装文件”选项？如果没有，这可能解释了为什么它可能无法自动转换。
答案 1 :(得分：1)
您并没有完全向我们提供大量信息。
我认为你在谈论“Acrobat.CAcroPDAnnot”类的方法GetContents。您使用的是哪个版本的Acrobat？您是否可以在开始使用Delphi 2009进行编程时切换版本（或运行更新）？
然后：你是如何实例化对象的？如果使用从DLL生成的* _TLB.pas文件，您确定它仍然匹配它吗？ （尝试重新生成它，如果不确定的话）。
第三：你怎么称呼这个方法？您将结果分配给什么类型的变量？如果你能提供一个注释样本（最好包括非ASCII字符），那么可能也会有所帮助;并为该注释：
（*最好是（ansi / wide）字符串的HEX字节代码;但是从Ctrl-F7检查器输出应该这样做）
然后也许有人可以提供更有意义的答案。
答案 2 :(得分：0)
好的，Delphi 2009和早期版本之间的主要区别之一是默认字符串类型是unicode字符串。这意味着如果您使用与先前版本相同的ActiveX组件，则将unicode字符串传递给ascii字符串，这通常不是一个好主意。
这个问题有几个解决方案：