1

非ASCII文字が返されることに問題があります。問題がどのレベルにあるかはわかりません。それは、実際の PDF エンコーディング、CAM::PDF (FlateDecode) によって使用されるデコーディング、または CAM::PDF 自体である可能性があります。以下は、PDF の作成に使用されるコマンド (Tm、Tj など) をすべて含む文字列を返します。

use CAM::PDF;

my $filename = "sample.pdf"; 
my $cam_obj = CAM::PDF->new($filename) or die "$CAM::PDF::errstr\n";
my $tree = $cam_obj->getPageContentTree(1);
my $page_string = $tree->toString();
print $page_string;

ここからsample.pdfをダウンロードできます

Tj で返されるテキストには、多くの場合、ASCII 以外の文字が 1 つ含まれています。PDF では、実際の文字はほとんどの場合、一重引用符または二重引用符です。

これを再現しているときに、返された文字は PDF 内では一貫しているが、PDF によって異なることがわかりました。また、PDF が特定のフォント ファイルを使用していることにも気付きました。現在、フォント ファイルを調べて、同じ文字をさまざまなバイナリ値にマップできるかどうかを確認しています。

:編集: Windows-1252 について。私の PDF は、アポストロフィの代わりに「Õ」を返します。Õ 文字は、Windows-1252 および UTF-8 では 16 進数の 0xD5 です。文字が Windows-1252 でエンコードされているという考えである場合、それは 16 進数の 0x91 または 0x92 である必要がありますが、そうではありません。これが、以下がキャラクターに何もしない理由です:

use Encode qw(decode encode);
my $page_string = 'Õ';
my $characters = decode 'Windows-1252', $page_string;
my $octets = encode 'UTF-8', $characters;
open STS, ">TEST.txt";
print STS $octets . "\n";
4

3 に答える 3

1

私はCAM-PDFの作者です。PDF は準拠していません。PDF 1.7仕様のセクション3.2.3「文字列オブジェクト」から:

「リテラル文字列内では、バックスラッシュ (\) は、改行文字、印刷されない ASCII 文字、バランスの取れていない括弧、またはバックスラッシュ文字自体を文字列に含めるなど、さまざまな目的でエスケープ文字として使用されます。[...] \ddd エスケープ シーケンスは、印刷可能な ASCII 文字セット以外の文字を表す方法を提供します。"

非 ASCII 文字が大量にある場合は、16 進文字列表記を使用して表すことができます。

編集:a_noteの代替回答を考えると、仕様の私の解釈が間違っている可能性があります。私はこれを再検討する必要があります.確かに、仕様はこの分野でより明確になる可能性があります.

于 2012-05-11T22:46:26.340 に答える
1

乱入して申し訳ありませんが、敬意を表して、ファイルは準拠しています。セクション 3.2.3 ではさらに次のように述べています。

[\ddd] 表記は、ASCII 文字のみを使用して 7 ビット ASCII 文字セット以外の文字を指定する方法を提供します。ただし、任意の 8 ビット値が文字列に表示される場合があります。

于 2012-05-16T23:14:13.577 に答える
0

「受信」 - どこで?予想の代わりに「Õ」が表示されるのは何ですか? そして、正確に何をしていますか?Windows コマンド プロンプトは、windows-1252 ではなく、DOS コード ページを使用することをご存知ですか? (おっと、また新しいスレッド...おそらくここに登録する必要があります:-))

于 2012-05-18T17:29:48.687 に答える