이상한 결과를 반환하는 CGPDFScannerPopString

나는 마침내 일종의 pdf 스캐너를 갖게되었습니다. 그것은 문제없이 콜백 함수로 읽지 만 내가 NSLog에 CGPDFScannerPopString의 결과를하려고 할 때이 같은 결과를 얻을 :이상한 결과를 반환하는 CGPDFScannerPopString

ˆ ˛˝  # ˜˜˜  #˜' ˜˜˜  "˜ '˜˜  " ' ˜˜

여기에서 찾을 수가 없습니다 문자열 ...

어떤 아이디어 그게 뭐야? 이것은 내 콜백 함수입니다.

static void op_Tj (CGPDFScannerRef s, void *info) 
{ 
    CGPDFStringRef string; 

    if (!CGPDFScannerPopString(s, &string)) 
     return; 

    NSLog(@"string: %@", (__bridge NSString *)CGPDFStringCopyTextString(string)); 
}

감사합니다!

편집 : Example PDF

출처

2012-12-21 Ron

당신은 CGPDFStringRef는 ASCII 문자열이나 모든 유사한 일이 아니라는 것을 알고 있어야합니다. Cf. http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html --- 최신 PDF 참조에 따라 해석되어야하는 "0 ~ 255 범위의 바이트 부호없는 정수 값 계열"입니다.

PDF 참조는 바이트의 해석이 사용 된 글꼴에 따라 다르며 유럽어의 경우 ASCII와 같은 해석이 일반적이지만, 필수는 아니며 아시아 언어의 경우에는 글꼴 하위 집합 임베딩은 매우 일반적이며, 해석이 무작위로 보일 수 있습니다.

CGPDFStringCopyTextString은 해당 바이트를 그에 따라 해석하려고하지만 일반 문자열로는 의미있는 해석이 필요하지 않습니다.

EDIT 샘플의 검사 제공된 PDF Ron은 실제로이 샘플의 경우 실제로 문서의 대부분 페이지에서 우세한 글꼴 3 인코딩이 표준 인코딩이 아니라 다음과 같은 사실을 보여줍니다.

<</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의 바이트를 직접 해석해야합니다. 처음부터 그렇게하고 싶지 않다면, iOS의 PDF에서 데이터를 추출하기위한 프레임 워크 인 PDFKitten에 관심이있을 것입니다. 아직 완벽하지는 않지만 (일부 글꼴 구조로 인해 어려움을 겪을 수 있음) 좋은 출발점입니다.

출처

2012-12-22 00:19:01 mkl

아하, 지금은 좀 더 의미가 있습니다 ... 나는 약간을 조사하고 문서에 ToUnicode 항목이 있어야한다는 것을 읽었습니다. 어쩌면 당신이 이것을 사용하는 방법을 도와 줄 수 있습니까? – Ron

신경 쓰지 마라. FastPDFKit은 텍스트를 추출 할 수조차 없다. 내가 그때 할 수있을 것이라고 생각하지 마라. – Ron

검열을 위해 샘플 PDF를 제공했다면 ... – mkl

이상한 결과를 반환하는 CGPDFScannerPopString

답변

관련 문제