Вы должны знать, что CGPDFStringRef не является строкой ASCII или чем-то подобным. См. http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html --- это «серия байтов — целочисленные значения без знака в диапазоне от 0 до 255», которые должны интерпретироваться в соответствии с последними Ссылка в формате PDF.
Ссылка в формате PDF, в свою очередь, скажет вам, что интерпретация байтов зависит от используемого шрифта, и хотя интерпретации, подобные ASCII, распространены в случае европейских языков, они не являются обязательными, а в случае азиатских языков, где встраивание подмножества шрифтов является очень распространено, интерпретация может выглядеть случайной.
CGPDFStringCopyTextString пытается соответствующим образом интерпретировать эти байты, но не обязательно иметь разумную интерпретацию как обычную строку.
РЕДАКТИРОВАНИЕ Проверка образца 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, платформа для извлечения данные из PDF-файлов в iOS. Хотя он еще не совершенен (некоторые структуры шрифтов могут сбивать его с толку), это хорошая отправная точка.
person
mkl
schedule
22.12.2012
