你應該知道的是,CGPDFStringRef不是一個ASCII字符串或類似的東西都沒有。參看http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html ---它是「一系列字節無符號整數值,範圍爲0到255」,必須根據最新的PDF參考進行解釋。
PDF參考反過來會告訴你,字節的解釋取決於所使用的字體,而在歐洲語言的情況下,類似於ASCII的解釋是常見的,它們不是強制性的,而在亞洲語言的情況下字體子集嵌入非常普遍,解釋可能看起來是隨機的。
CGPDFStringCopyTextString會嘗試相應地解釋這些字節,但不一定要將其理解爲常規字符串。
編輯檢查樣本PDF Ron提供的顯示,在這個樣本的情況下,對象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數據的框架。雖然它還不完美(某些字體結構可能會讓它困惑),但這是一個很好的起點。
來源
2012-12-22 00:19:01
mkl
啊哈,現在更有意義了......我搜索了一些並閱讀文檔中應該有一個ToUnicode條目。有,但也許你可以幫我解決如何使用它? – Ron
不要緊,FastPDFKit甚至無法提取文本。不要以爲我會做到這一點... – Ron
如果您提供了一個樣本PDF來檢查... – mkl