0

私はついにある種のpdfスキャナーを動作させました。問題なくコールバック関数を読み込みますが、CGPDFScannerPopString からの結果を NSLog しようとすると、次のような結果が得られます。

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

ここに文字列が見つかりません...

それが何であるかについてのアイデアはありますか？これは私のコールバック関数です:

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

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

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

もうありがとう！

編集：PDFの例

4

1 に答える 1

2

CGPDFStringRef は ASCII 文字列などではないことに注意してください。参照。http://developer.apple.com/library/mac/documentation/graphicsimaging/Reference/CGPDFString/Reference/reference.html --- これは「一連のバイト — 0 から 255 の範囲の符号なし整数値」です。最新の PDF リファレンスに従って解釈されます。

PDF リファレンスは、バイトの解釈が使用されるフォントに依存することを示しています。ヨーロッパ言語の場合は ASCII のような解釈が一般的ですが、必須ではなく、フォント サブセットの埋め込みが必要なアジア言語の場合は、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

そのエンコーディングは、次の必要なグリフに 1 から始まる次の番号を割り当てることによって作成されたようです。これは明らかに非常に個人主義的なエンコーディングになります...

そうは言っても、フォント オブジェクトには /Encoding エントリと /ToUnicode エントリの両方が含まれています。したがって、メソッド CGPDFStringCopyTextString がここでフォントへの参照を与えられ、実際に試行された場合、これらのバイトを対応するテキストに正しく変換することが簡単にできます。まともなものが何も達成されないということは、バイトを解釈するフォントの情報が単にないことを示しているようです---試行しないとは思いません...

したがって、テキストを正確に抽出するには、コンテンツ ストリーム内のフォントの情報を使用して、CGPDFStringRef 内のバイトを自分で解釈する必要があります。これを最初からやりたくない場合は、iOS で PDF からデータを抽出するためのフレームワークであるPDFKittenに興味があるかもしれません。まだ完全ではありませんが (一部のフォント構造ではうまくいかない場合があります)、良い出発点となります。

于 2012-12-22T00:19:01.163 に答える