CGPDFScannerPopString返回奇怪的结果
我终于得到某种pdf扫描仪了。 它读入回调函数没有问题，但是当我尝试NSLog结果来自CGPDFScannerPopString时，我得到如下结果：
ˆ ˛˝ # ˜˜˜ #˜' ˜˜˜ "˜ '˜˜ " ' ˜˜ 这里找不到任何字符串……
有什么想法可以吗？ 这是我的回调函数：
static void op_Tj (CGPDFScannerRef s, void *info) { CGPDFStringRef string; if (!CGPDFScannerPopString(s, &string)) return; NSLog(@"string: %@", (__bridge NSString *)CGPDFStringCopyTextString(string)); }
谢谢！
编辑： 示例PDF
您应该知道CGPDFStringRef不是ASCII字符串或类似的东西。 参看 http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html —它是一系列字节无符号整数值，范围为0到255“根据最新的PDF参考解释。
反过来，PDF参考将告诉您字节的解释取决于使用的字体，而类似ASCII的解释在欧洲语言的情况下很常见，它们不是强制性的，而在亚洲语言中，字体子集嵌入是很常见，解释可能看起来随机。
CGPDFStringCopyTextString尝试相应地解释这些字节，但不必将合理的解释作为常规字符串。
EDIT检查样本PDF Ron提供的信息显示，在此样本的情况下，对象3 0中的字体编码（在文档的大多数页面上占主导地位）不是标准编码，而是：
<>
查看第一个文档页面的顶部
COVER / HLF_CWEB_58408485 / 58408485 / 26DEC12 10.30.22Z BRIEFING INCLUDES FOLLOWING FLIGHTS: 26DEC12 OR0337 EHAM0630 MUVR1710 PHOYE VSM+2/8 179 NEXT FLIGHTS OF AIRCRAFT: 26DEC12 OR0338 MUVR1830 MMUN1940 PHOYE VSM+2/8 213 26DEC12 OR0338 MMUN2105 EHAM0655 PHOYE GPT+2/7 263 27DEC12 OR0365 EHAM0900 TNCB1930 PHOYE BAH+1/8 272 27DEC12 OR0366 TNCB2030 TNCC2110 PHOYE BAH+1/8 250 27DEC12 OR0366 TNCC2250 EHAM0835 PHOYE ASD+1/8 199
这个编码似乎是通过从下一个数字开始处理下一个所需的字形来创建的。 这显然导致了高度个性化的编码……
也就是说，字体对象确实包括/ Encoding条目和/ ToUnicode条目。 因此，如果方法CGPDFStringCopyTextString在这里给出了对字体的引用并且真的尝试过，那么很容易就能够将这些字节正确地转换为相应的文本。 它没有实现任何体面，似乎表明它根本没有用于解释字节的字体信息—我不认为它不会尝试…
因此，为了准确提取文本，您必须使用内容流中字体的信息自行解释CGPDFStringRef中的字节。 如果您不想从头开始这样做，您可能会对PDFKitten感兴趣， 这是一个从iOS中的PDF中提取数据的框架。 虽然它还不完美（某些字体结构可能令人困惑），但这是一个很好的起点。