OCRが必要なPDFページを判定

テキスト層フラグの意味とページ単位OCRが重要な理由

その場合、テキスト抽出APIを呼ぶ下流ツールは空文字列を受け取り、全文検索はそのページを飛ばし、アクセシビリティリーダーは有用な内容を読み上げず、ネイティブテキストを期待する保管パイプラインは静かに失敗します。本エンドポイントはPDF自体を開きません。応答は1始まりのページ番号としてneeds_ocr_pagesとsearchable_pagesを列挙し、さらにneeds_ocr_count、searchable_count、all_need_ocr、all_searchable、page_countで割ったocr_ratio、ページごとのhas_text_layerとneeds_ocrを持つpages配列、ログやUIバナー向けのsummaryを返します。この形により、バッチジョブはフラグ付きページだけをOCRし、検索可能なページを飛ばし、PDFバイトを再解析せずにカバレッジを報告できます。

入力契約、応答形状、空リストのエラー

各要素は真偽値であるべきですが、ソルバーは数値の0と1、およびtrue、false、yes、no、y、n、zero、oneといった一般的な文字列トークンも受け付けるため、CSVやフォームのエクスポートを前処理なしで貼り付けられます。特定ページの無効トークンは1始まりのページ番号を示して失敗するため、マップを作ったプローブを修正できます。列挙されたページだけを処理する準備ができたら、自前のOCRランナーや兄弟のPDF OCR製品と組み合わせてください。文書順のページごとの存在フラグの必須かつ空でない配列であるtext_layerを含むJSONボディをPOSTしてください。同じ配列にはpages、flags、has_textという別名も使えます。空配列、空白文字列、欠落フィールド、nullはinvalid_inputで失敗し、text_layerを名指しして少なくとも1つのページフラグが必要だと伝えます。これらの失敗は課金されません。成功時はフラグ長に等しいpage_count、falseごとのneeds_ocr_pages、trueごとのsearchable_pages、両カウント、全ページがOCR必要なときのall_need_ocr、不要なときのall_searchable、ランタイム間で安定したテストのため小数12桁に丸めたocr_ratio、詳細なpages配列、summaryを返します。例: true, false, true, false のフラグはpage_countが4、needs_ocr_pagesが2と4、searchable_pagesが1と3、needs_ocr_countが2、ocr_ratioが0.5、4ページ中2ページがOCR必要という要約になります。

OCR必要ページフラグAPIが役立つ場面

デジタル化デスクは、ネイティブなデジタル出力とフラットベッドスキャンが混ざったバインダを受け取ります。アクセシビリティ改修チームは、選択可能テキスト検査に落ちるページの決定的な一覧が必要で、文書全体ではなくページ単位のチケットを開けます。「テキスト層の有無をすでに測った事前チェックは、数百ページのファイルを開き直さずにOCRキュー用のページ番号作業リストを得るために本エンドポイントを呼べます。検索やe-discoveryの基盤は同じフラグで、文書が索引可能かOCR待ちかを判断し、ocr_ratioフィールドは各受入バッチのうち画像のみがどれだけ残っているかを追う品質ダッシュボードに供給されます。実装はparseのティアAのため、成功した呼び出しは公開の基本料金$0.002のみで、モデルトークンも外向きネットワークもなく、検証失敗は残高を消費しません。リクエストは小さく保ち、テストで順序付きページ一覧を固定すれば、真偽スキャンだけのために文書AIスタックを立てずに、PDF在庫とOCR支出の間に再現可能なゲートが得られます。