プログラマーから見たPDFファイル

1. バイナリデータを解析してコンテントストリームを探す

まずは、バイナリデータを解析し、PDFファイルを表示したときにページになるデータ構造を探し出します。 このデータ構造は「コンテントストリーム」と呼ばれ、PDFファイルのあちこちに分散して格納されています（先に触れたように、本稿ではPDFファイルからコンテントストリームを探し出す方法については割愛します）。

「テキストデータ」と紛らわしいですが、PDFの仕様などでは、あるページに表示される文字（つまり「絵としての文字」の並び）のことを単に「テキスト」と呼んでいます。 コンテントストリームからページ上に配置されるテキストを読み取り、それをテキストデータとして解釈しようというのが、以降の基本的な方針です。

なお、PDFファイル中のコンテントストリームは通常は圧縮されています。 これを適切なアルゴリズムで解凍するとプレーンテキスト形式のデータが得られます。 以降では、このプレーンテキスト形式にしたデータのこともまた「コンテントストリーム」と呼ぶことにします。

2. コンテントストリームを読む

コンテントストリームは、「PDFオペレーター」と呼ばれる命令と、その引数によって構成されています。 命令と引数で構成されることから想像できるように、コンテントストリームから必要な情報を適切に取り出すには、パーザーを書いてスタックマシンに相当する仕組みを実装する必要があります。

PDF表示アプリケーションでも、画面上に表示するページを組み立てるために、PDFオペレーターとその引数を解釈して「どのフォントのどの文字を画面のどこに配置すればいいか」などを認識するようになっています。 次項で説明するように、それと同じような仕組みがテキストデータを取り出すにも必要になるということです。

とはいえ、画像を配置するためのPDFオペレーターや色の管理をするためのPDFオペレーターは無視できるので、そのへんは楽ができます。 コンテントストリームからテキストデータを取り出すために最低限実装が必要になるPDFオペレーターは以下の4種類です。

• コンテントストリームにおけるテキストの存在を示すBTオペレーターとETオペレーター
• ページ上でのテキストの位置を決めるためのTmオペレーターやTdオペレーターなど
• フォント選択用のTfオペレーター
• テキスト描画用のTJオペレーターやTjオペレーターなど

3. テキスト描画用オペレーターの引数からテキストデータを手に入れる

プレーンテキスト形式にしたコンテントストリームをエディタなどで眺めていると、TJオペレーターやTjオペレーターの引数が「いかにもテキストデータっぽい情報」に見えます。

しかし、この引数をそのまま読んでもテキストデータとしては使えません。 「コンテントストリームからTJ/Tjオペレーターなどを正規表現で探して取り出せばテキストデータが得られるだろう」とはいかないのです。

なぜそれができないのでしょうか。主な理由は以下の3つです。

1. 引数がどういう書式およびエンコーディングで格納されているかが、PDF生成ツールの実装やフォントの種類によってまちまち
2. 引数から直接わかるのは、あるフォントから絵としての文字を描くための情報を探し出す方法であり、テキストデータとは限らない
3. コンテントストリーム内でのTJ/Tjオペレーターなどの位置関係だけでは、テキストデータとしての順序はわからない

引数から直接わかるのは、テキストデータとは限らない

2つめは、そうやって読み取った引数が一般にはテキストデータそのものではない、という問題です。 特に日本語フォントでは、この引数が「そのフォントの中で文字を探し出すための識別子」でしかない場合が多々あります。

テキストデータを得るには、それがどのUnicode文字に対応しているかを、PDFファイル内外の別の場所にある情報を参照して調べることになります。 多くの場合は「/ToUnicode CMap」と呼ばれる対応表がPDFファイル中に含まれているので、この情報を使って識別子からUnicode文字を変換します。

なお、エンコーディングや/ToUnicode CMapはコンテントストリームだけからはわかりません。 コンテントストリームには「その箇所で利用されているフォント」だけがTfオペレーターとして指示されています。 その指示をもとに、PDFファイル内の別の場所にある「リソース辞書」と呼ばれるデータ構造を見て、エンコーディングや/ToUnicode CMapを探り当てます。

フォントやエンコーディングによってはコンテントストリームからテキストデータが直接得られる場合もありますが、「そういう場合である」という事実を知るのにも、やはりTfオペレーター経由でリソース辞書を調べなければなりません。

1. MS Wordで生成したPDFファイルの例

最初の例は、Windows上のMS Wordで生成したPDFファイルのコンテントストリームと、そこからテキストデータを取り出す例です。 PDFファイルから最初のページのコンテントストリームを探し出すと以下のようなデータが含まれていました。

    BT
    /F1 11.04 Tf
    1 0 0 1 96.144 716.02 Tm
    /GS10 gs
    0 g
    /GS11 gs
    0 G
    [<01260177014A014E>11<0153012A013D>] TJ
    ET

すでに説明したように、テキストデータを取り出すには上記のようなコンテントストリームだけでなく、対応するフォントに関する情報も必要です。 上記の例の範囲では、2行目のTfオペレーターの引数を見ることで、/F1という名前で示されているフォントが使われていることが読み取れます。

そこで実際に/F1で示されているフォントの情報を調べると、以下のような情報が得られます。

    /Type: /Font
    /Subtype: /Type0
    /BaseFont: /BCDEEE+UDDigiKyokashoN-R
    /Encoding: /Identity-H
    /DescendantFonts: 6
    /ToUnicode: 23

上記からは、「このフォントはType0という種類で、そのエンコーディングは/Identity-Hであり、さらに/ToUnidode CMapがこのPDFファイル中のに存在して、その参照番号は23である」ことがわかります。

意訳すると、「TJオペレーターの引数（この場合は16進文字列で指定されている）をそのまま2バイト1文字として読み、それをPDFファイル中の23という番号で参照できる/ToUnidode CMapを使ってUnicode文字に変換すれば、テキストデータが得られる」ということです。

ちなみに、参照番号23にあるデータ構造の中身を調べてみると、次のような情報が見つかります。 これが/ToUnidode CMapの実際の姿の例です。

    /CIDInit /ProcSet findresource begin
    10 dict begin
    begincmap
    /CIDSystemInfo
    << /Registry (Adobe)
    /Ordering (UCS)
    /Supplement 0
    >> def
    /CMapName /Adobe-Identity-UCS def
    /CMapType 2 def
    1 begincodespacerange
    <0000> <FFFF>
    endcodespacerange
    7 beginbfchar
    <0126> <30A2>
    <012A> <30A6>
    <013D> <30B9>
    <014A> <30C6>
    <014E> <30CA>
    <0153> <30CF>
    <0177> <30F3>
    endbfchar
    endcmap
    CMapName currentdict /CMap defineresource pop
    end
    end

あとは得られたUnicodeの各文字を適切につなげるだけです。 この例の場合は、すべての文字が1つのTJオペレーターの引数になっているので、各文字を単純につなげて最終的なテキストデータとすればいいでしょう。

ただし、TJオペレーターの引数で途中に出てくる「11」は文字ではなく文字詰めに関する情報なので、少しだけ注意が必要になります。

2. wxhtmltopdfで生成したPDFファイルの例

次の例は、wxhtmltopdfというツールで生成したPDFファイルの例です。 やはり環境によって異なりますが、wxhtmltopdfは以下のようなコンテントストリームを生成するようです。

    BT
    /F6 16 Tf 1 0 0 -1 0 0 Tm
    8 -15 Td <0001> Tj
    12 0 Td <0002> Tj
    12 0 Td <0003> Tj
    12 0 Td <0004> Tj
    13 0 Td <0005> Tj
    14 0 Td <0006> Tj
    12 0 Td <0007> Tj
    ET

この場合も、まずフォントに関する情報を調べてエンコーディングなどを知る必要があります。 この範囲で使われる/F6というフォントの情報を調べてみると下記のようになっていました。

    /Type: /Font
    /Subtype: /Type0
    /BaseFont: /MSUIGothic??
    /Encoding: /Identity-H
    /DescendantFonts: 14
    /ToUnicode: 15

先のMS Wordの例と同じく、フォントの種類はType0でエンコーディングがIdentity-Hなので、Tjオペレーターの引数（16進文字列）をそのまま2バイトずつ読み、さらに/ToUnicode CMapを使って変換すればテキストデータが得られます。

先の例と異なるのは、テキストデータの配置を読み取るために各行のTdオペレーターの情報を使わなければならない点です。

3. Primo PDFで生成したPDFファイルの例

次は、Primo PDFというツールで生成したPDFファイルの例です。 筆者の環境で生成したPDFファイルからは下記のようなコンテントストリームが得られました。

    BT
    /R9 11.04 Tf
    0.999402 0 0 1 96.12 716.12 Tm
    [(\SOH&)-0.598104(\SOHw)-0.598104(\SOHJ)-0.598768(\SOHN)10.2773(\SOHS)-0.598768(\SOH*)-0.598768(\SOH=)1000]TJ
    /R12 11.04 Tf
    77.0861 0 Td
    (\SOH)Tj
    ET

先ほどまでの例では、TJ/Tjオペレーターの引数の書式が16進文字列でしたが、この例ではTJオペレーターの引数がリテラル文字列になっています（明らかに様子が違うのが見て取れると思います）。

とはいえ、この範囲で使われているフォント/R9の情報を調べると、下記のように/Type0フォントかつ/Identity-Hエンコーディングであることがわかるので、同じようにそのまま2バイトを1文字として読むだけです。

    /Subtype: /Type0
    /Type: /Font
    /BaseFont: /SUMHAC+UDデジタル教科書体N-R
    /Encoding: /Identity-H
    /DescendantFonts: 10
    /ToUnicode: 18

そのうえで、やはり/ToUnicode CMapを使ってUnicode文字に変換すれば、テキストデータが取り出せます。

4. dvipdfmxで生成したPDFファイルの例

最後に、/ToUnicode CMapがない場合の例を簡単に紹介だけします。

日本語LaTeX文書からPDFを生成するときにはdvipdfmxというツールが広く使われています。 このdvipdfmxでPDFを生成したところ、以下のようなコンテントストリームが得られました。

    BT /F1 9.2123 Tf 9.149 -53.005 Td[<039e03ef03c203c603cb03a203b5>]TJ ET

これまでの例と同様に、リソース辞書からフォント/F1の情報を調べてみると、以下のようになっていました。

    /Type: /Font
    /Subtype: /Type0
    /BaseFont: /JTRZSC+IPAexMincho
    /Encoding: /Identity-H
    /DescendantFonts: 4

エンコーディングは/Identity-Hであると読めますが、/ToUnicode CMapが見当たりません。 この例の場合には、フォントの種類がType0であることから、「さらに詳しい情報を/DescendantFontsというエントリーの情報をから調べればよい」ということが分かります。

そこで、/DescendantFontsのエントリーを調べてみると、以下のような/CIDSystemInfoという情報が判明します。

    /CIDSystemInfo:
    /Registry: Adobe
    /Ordering: Japan1
    /Supplement: 7.0

この例では、この/CIDSystemInfoによって示される「Adobe-Japan1-7」という情報が鍵となります。 Adobe-Japan1-7というのはAdobe社が定める日本語の文字集合の名称であり、その識別子（CIDと呼ばれます）からUnicodeへの対応も公開されているので、それに従ってコンテントストリームを読めばテキストデータが得られます。