非標準の文字エンコーディングでPDFを検索

一部のPDFファイルでは、テキストをコピーするときにゴミが生成されます（「mojibake」）。これにより、それらを検索することができなくなります（検索するものはすべてゴミと一致しません）。

簡単な回避策はありますか？

例：

1. TEAC TVマニュアルEU2816STF（WindowsとMacの両方のAdobe Readerで上記の問題が発生しますが、Macのプレビューでは正常に動作します）
2. Leadtek Winfast PVR2マニュアル（FTPリンク。Macのプレビューでも問題があります）
3. Swann TVチューナーカードマニュアル（FTPリンク。Macのプレビューでも問題があります）
4. Phonediscライセンス契約（現在廃止されているDTMSから）
5. マッコーリーIFP四半期ファンドレビュー
6. BAN-TACSスモールビジネスブックレット（アーカイブ版）
7. Easterfest 2004チラシ（アーカイブからも）

Windows用のAdobe Reader（最新バージョン）を使用しています-おそらく別のビューアーが役立つでしょうか？Windows用の無料のソリューションを探しています。オープンソースはさらに良いでしょう。

編集：Multivalent Extract Textツールのドキュメントには、次のような問題が発生する理由の概要が記載されています。

• テキストにUnicodeマッピングがない場合があります。PDF Type 3フォントには含まれないことが多く、TeX DVIにはUnicodeに相当する文字がない文字があります。
• Unicodeエンコーディングにはバグがある場合があります。Open Officeは、一部の文字を同じUnicodeにマップします。その結果、見かけの文字が削除されて二重になります。

これらの場合の究極の解決策は、フォント内の各グリフをOCRして、実際にどの文字であるかを把握することだと思います。グリフの正確な形状が利用できるため、これはノイズの多いスキャンされたドキュメントをOCRするよりも簡単であることに注意してください（「ベクター」画像なので無限の解像度で）。

Foxit Reader、おそらく？

Mac OS X 10.6.2でSafari 4.0.4にリンクしたPDFを確認しましたが、いくつかのEngrishがありますが、PDFは画面上の「ゴミ」なしで完璧にレンダリングされます。おそらく、Unicodeの問題（Mac OSよりもWindowsの方が一般的です）がありますか？

これを回避する最も簡単な方法は、PDF読み取りプラグインが組み込まれた最新バージョンのGoogle Chromeでファイルを開くことです。その後、Chromeの検索機能を使用してテキストを検索できます。コピーアンドペーストは正しく機能します。

以下のためのテレビマニュアル例：同じMac上のAdobe Reader 8.1.2で問題が、ありませんコピーまたはテキストを検索するためにMacのプレビューを使用して問題。また、Gmailアカウントに送信し、[表示]、[プレーンHTML]の順に選択すると、テキストが表示されます。しかし、Adobe Readerはそれが好きではありません。

そのドキュメントプロパティには、フォントの「エンコード：カスタム」が表示されます。別のドキュメントには「エンコード：Ansi」や「ローマ」などが記載されており、MacのプレビューでもAdobe Readerでも問題はありません。

ただし、LeadtekとSwannの両方の例では、MacのプレビューとGmailでも問題が発生し、両方とも「エンコード：Identity-H」と表示されます。Phonediscのテストは、「：カスタムエンコーディング」で、あまりにも失敗します。

混乱を招き、一貫性はありませんが、Adobeのフォーラムで、「エンコード：カスタム」（エンファシスマイニング）を示すさらに別の例について次の説明を見つけました。

PDFの内部を見ると、ドキュメントのページに表示される文字/グリフの意味を導き出すための使用可能なエンコード情報が（PDFにも埋め込みフォントデータにも）存在しないことがわかりました。

実際にはフォントはすべて埋め込まれていますが、すべてのエンコーディング情報が削除されています。これは、PDF仕様に構文的に完全に準拠しているが、PDFの作成プロセス中にそのテキストの意味に関する重要な情報が破棄されているPDFの典型的な例です。私が知る限り、エンコード情報を復元することは非常に困難です。

これは、「エンコード：カスタム」であっても、Adobe Readerが失敗したときにMacのプレビュー（および明らかに Infixも）がいくつかの例を処理できる理由を説明していません。正確なフォントがコンピューター自体に存在する場合、プレビューに問題はないのでしょうか？または、エンコーディングを推測しているだけかもしれませんが、これはたまたますべてのドキュメントではなく一部のドキュメントで機能しますか？

これの原因が何であれ：Google DocsまたはGmailを通過できない場合、おそらく最も簡単な（しかし決して簡単ではない）回避策は、実際にTIFFとして保存してからOCRを実行することです。Evernoteのようなサービスは、オンザフライで実行する場合があります（画像に対してOCRを実行します。PDFに対してOCRを実行することはできません）。

ファイル1のダウンロードは失敗し、ファイル2は高速でオープンソースのpdfビューアであるxpdfで開くことができました。フォームを処理できないと思いますが、純粋なテキストとグラフィックの場合は、起動時間が速いため好まれます。

残念ながらそれは仕方がありません。PDFドキュメントには実際には文字が含まれていませんが、文字の形状が含まれています。つまり、他のPDF読み取りアプリケーションのように、Adobe Readerを画面に文字を読んで描画する代わりに、ファイルにエンコードされたベクターグラフィックスを単純に描画します。

ただし、一部のPDFリーダーには、テキスト認識を使用して形状を分析し、テキストを復元できるソフトウェアが付属しています。印刷されたテキストの紙をスキャンし、ABBYY FineReaderなどのソフトウェアを使用してテキストに戻す場合と同じように機能しますが、ベクター描画の品質は無限に高いため、通常はスキャンしたドキュメントよりもはるかに優れています。

一部のドキュメントは、Adobe Readerをだましてテキストに変換されないように保護できます。たとえば、文字は視覚的には同じように見えるが、テキスト認識ソフトウェアはテキストを認識できないような方法で、いくつかの重なり合った形状で描画できます。あなたの文書はそのような保護の一例です。

1つの方法は、ドキュメントを画像に印刷し、テキスト認識ソフトウェアに認識させることです。画像の解像度を高くすると、品質が向上します。ただし、この方法はあまり便利ではありません。