結論
PDFで見えている文字と、コピーや抽出で得る文字は一致しない場合があります。 自作の比較では、見た目が同じ「TOTAL 1200」でも、文字の対応表を変えた1件からは「T0TAL 1200」と取り出されました。2文字目が英字Oから数字0に変わっています。
PDFテキスト抽出取り出した文字と元の表示を照合する登録なしで使えます開く
これはPDF内部の文字の対応を変えた架空の試験です。受け取った業務PDFを改変したものでも、他人の資料の保護を外したものでもありません。見た目を確認しただけでは、文字データの一致を確かめ終えられないことを示す例です。
自作3条件で、表示と抽出を別々に比べた
同じ英数字1行を描くPDFを3条件作成しました。2026年9月30日、Windows・Chromium 153・pdf.js 3.11.174を使用しています。各1ページ、400×200pt、標準フォントHelvetica、24ptの作例です。
条件を変えたのは、PDFの文字コードをUnicodeの文字へ対応させるToUnicodeという情報です。n=3のうち、無し・文字と一致・英字Oだけ数字0へ対応の3種類を比べました。表示する文字の描画命令と配置は同じです。
| 対応表の条件 | 描画したページの見た目 | 取り出した文字 |
|---|---|---|
| ToUnicodeを追加しない | TOTAL 1200 | TOTAL 1200 |
| 全て一致する対応表を付ける | TOTAL 1200 | TOTAL 1200 |
| Oだけ0へ対応させる | TOTAL 1200 | T0TAL 1200 |
3件を800×400pxの画像に描画し、元の条件との差を独立した画像読取り処理で調べました。各320,000画素のうち、違う画素は0でした。見た目が似ているという目視だけでなく、この条件では表示画像が一致したという測定です。
一方、pdf.jsの文字抽出は3行目だけ異なり、別のpypdfによる抽出でも同じ違いを確認しました。pypdfは行末に改行を付けましたが、文字列のOと0の差は両方で一致しています。画像が同じでも、抽出する文字は変わりました。
なお、1行目では対応表を追加しなくても正しく抽出できました。「ToUnicodeが無いPDFは必ず文字化けする」という結論にはなりません。 フォントや符号化など、ほかの情報から読める場合もあるためです。
一次資料で確認した文字情報の扱い
文字抽出の対応付けは、コピー先のフォントを変える話とは別です。Enfocusの製品マニュアルは、ToUnicodeの対応が使われる例として、PDFから他のアプリへコピーする場面を挙げています。
“override the default text extraction behavior”
出典：Enfocus「Check presence of ToUnicode map in font」、What it does。 https://cdn.enfocus.com/manuals/Extra/Actions/17/en-us/common/act/concept/co_check_presence_of_Tounicode_map.html（2026-09-30 到達）
既定の文字抽出の動作を上書きする、という説明です。この説明と、自作例で対応表を変えた結果が対応しています。PDF/Aへの適合を今回判定したという意味ではありません。
“fonts, encodings, typical character distances”
出典：pypdf「Extract Text from a PDF」、Can we just always use OCR?。 https://pypdf.readthedocs.io/en/stable/user/extract-text.html（2026-09-30 到達）
同資料は、文字抽出が画像だけでなく、フォント・符号化・文字間隔などの情報を使えると説明しています。目で見えるページの画像だけを読んでいる処理ではないことが、この比較を理解する手掛かりになります。
“pypdf is not OCR software.”
出典：同資料、OCR vs. Text Extraction。 https://pypdf.readthedocs.io/en/stable/user/extract-text.html（2026-09-30 到達）
文字情報を取り出す処理と、画像から文字を認識する処理は別です。今回の試験は画像認識を使っていません。OCRをかけ直せば必ず正しくなるという結論にもしていません。
コピー先で直す前に、現象を分ける
元のPDFの表示、取り出した文字、貼り付け先の表示を分けると、どこで違いが生じたかを説明しやすくなります。
| 現象 | 確認する点 |
|---|---|
| 元のPDFでも文字が崩れている | PDFの作成・表示側の問題か。コピー後だけの問題とは別 |
| 元は読めるが、抽出すると別の文字になる | 元の表示と短い文字列を一字ずつ照合する |
| 貼り付け先だけ四角い記号が出る | 抽出された文字と、貼り付け先の表示の差 |
| 行の途中に改行や空白が増える | 文字そのものの置換か、行・列の推定の問題か |
| そもそも文字を選べない | 画像だけのページか、コピー制限など別の原因か |
別の閲覧・抽出処理を使うと挙動が違う場合もありますが、どれかで文字が出たことだけを正解の証明にはできません。 自作例でも、二つの抽出処理が同じ誤った対応を読み取りました。番号や金額に使う場合は、元の表示との照合が残ります。
作成元に確認する際の材料は、該当ページ、元の表示、実際に取り出された短い文字列、使ったアプリの組合せです。元原稿からの再作成や別形式での提供を検討するにも、現象が分かる材料が必要になります。機密の全文を説明用に転記する前提ではありません。
測っていないこと・ここから先は推論
日本語の実際の文字化け、Office、Acrobat、クリップボード、OCR、フォント修復は測っていません。 抽出処理を直接実行した比較であり、コピー操作の再現試験ではありません。
n=3は1行だけの人工的な条件です。Oが0になる例を、文字化け全体の原因や発生率に一般化できません。 ToUnicode以外の原因の切り分けや、受領したPDFを直せるかどうかも未判定です。
次の1手
取り出された短い文字列を元の表示と比べ、文字の違いと改行の違いを分けるのが入口です。PDFテキスト抽出はその照合材料を作る道具で、文字の対応やPDFの内部を自動修復する機能はありません。