您应该知道 CGPDFStringRef 根本不是 ASCII 字符串或类似的东西。参照。http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html ---它是一个“字节系列 - 0到255范围内的无符号整数值”根据最新的 PDF 参考进行解释。
PDF 参考反过来会告诉您,字节的解释取决于所使用的字体,虽然类似 ASCII 的解释在欧洲语言中很常见,但它们不是强制性的,在亚洲语言的情况下,字体子集嵌入是很常见,解释可能看起来很随意。
CGPDFStringCopyTextString 尝试相应地解释这些字节,但不必将其解释为常规字符串。
编辑对 Ron 提供的样本 PDF 的检查表明,在这个样本的情况下,对象 3 0 中的字体编码(在文档的大多数页面上占主导地位)不是标准编码,而是:
<</Type/Encoding
/Differences[0/.notdef/C/O/V/E/R/space/slash/H/L/F/underscore/W/B/five/eight/four
/zero/two/six/D/one/period/three/Z/I/N/G/U/S/T/colon/seven/A/M/P/Y
/plus/nine/X/hyphen/i/s/p/a/t/c/h/n/f/o/K/greater/equal/l/m/y/J/Q
/parenleft/parenright/comma/dollar/ampersand/d/r/v/b/e/u/w/k/g/x/bar
/quotesingle/asterisk/q/question/percent]
>>
查看第一个文档页面的顶部
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 中提取数据的框架。虽然它还不是完美的(一些字体结构可能会让它感到困惑),但它是一个很好的起点。