軟體PDF 閱讀原理：為什麼OCR 辨識
以 PDF.js 為例，它會先把內容流轉成一連串「操作符（operator list）」，再由 canvas 渲染器逐項執行。文字的部分會交給字型載入器：如果是內嵌的 TrueType 或 CFF 字型，就透過 FontFace API 載入；如果是標準 14 字型（Helvetica、Times 等），則用系統或替代字型頂替。這也是為什麼有些 PDF 在別台電腦打開會「字型跑掉」——因為原始字型沒有內嵌，閱讀器只能拿相近的字型來替代。
文字選取與全文搜尋是怎麼做到的
當閱讀器執行到 Tj 或 TJ 運算子時，它除了把字形畫出來，還會在記憶體裡記錄一筆「文字片段」：內容是解碼後的字串、位置是經過文字矩陣與 CTM 轉換後的座標、大小是字級乘以變換矩陣的縮放。這些片段累積起來，就形成一層看不見的「文字層」。當你用滑鼠拖曳選取時，閱讀器其實是在做「命中測試（hit testing）」：把游標座標換算成頁面座標，找出落在範圍內的文字片段；當你按 Ctrl+F 搜尋時，閱讀器則是對這層文字片段做字串比對。
這裡有個關鍵推論：文字選取與搜尋完全依賴「內容流裡有文字運算子」與「字型具備可逆的編碼對照」。只要其中一個條件不成立，文字層就是空的，使用者體驗立刻從「電子文件」退化為「看圖」。
三、掃描型 PDF 的困境：圖片裡的文字對電腦而言只是色塊
掃描器的運作原理是用光學感測器把紙張的反射光轉成電訊號，再取樣成像素陣列。它不知道什麼是「字」，只知道「這個位置的亮度是 230，那個位置是 40」。所以掃描產出的 PDF，本質上就是一張（或數張）點陣圖被塞進 PDF 容器裡，內容流裡只有一個 Do 運算子用來繪製影像 XObject，完全沒有 BT、Tj 這些文字指令。
掃描 PDF 的內部組成
一份典型的掃描 PDF，頁面資源字典裡會有一個 /XObject，指向一個 /Subtype /Image 的影像物件。這個影像的 /Filter 可能是 DCTDecode（JPEG 壓縮，彩色掃描常見）、CCITTFaxDecode（黑白傳真式壓縮）、JBIG2Decode（黑白高效率壓縮，專利爭議較多）或 FlateDecode（無損壓縮）。整頁就是這一張圖，沒有任何字型資源、沒有 /ToUnicode、沒有文字片段。
有些掃描軟體會額外產生「影像遮罩（image mask）」或「軟遮罩（SMask）」來處理背景，也有些會把頁面切成多個影像區塊以利壓縮，但無論怎麼切，本質都一樣：對 PDF 閱讀器而言，這頁就是一堆像素，沒有語意。
沒有字型資源就沒有文字語意
這解釋了幾個使用者常見的困惑。第一，為什麼複製貼上是空的？因為文字層不存在，閱讀器沒有東西可以複製。第二，為什麼 Ctrl+F 搜不到？因為搜尋是對文字層做比對，不是對像素做影像辨識。第三，為什麼檔案特別大？因為點陣圖的資訊量遠高於文字，一頁 300 dpi 的 A4 彩色掃描動輒 2～8 MB，而同樣內容的文字型 PDF 可能只有 50 KB。
更麻煩的是，即使你用截圖工具把掃描頁「看起來像文字」的部分截下來，貼到 Word 裡，得到的仍然是一張圖片。電腦從頭到尾都不知道那張圖裡寫的是「營業收入」還是「營養午餐」——除非，你導入 OCR。
四、OCR 辨識的原理：讓機器「讀懂」像素裡的文字
OCR 的目標，是從點陣圖中還原出「字元序列」與「位置資訊」。這個過程聽起來簡單，實作起來卻是一連串誤差累積的工程。現代 OCR 系統通常分成四個階段：影像前處理、版面分析、字元識別、後處理。每個階段都會影響最終的辨識率，而真正的難點往往不在「認得字」，而在「知道哪裡有字、字跟字怎麼分群」。
影像前處理：把雜訊變成乾淨的候選區域
掃描件的第一個問題是「不乾淨」：紙張泛黃、裝訂處陰影、影印機條紋、原子筆畫線、印章覆蓋、頁面傾斜。前處理的任務就是把這些干擾降到最低。常見步驟包括：灰階化（把 RGB 轉成亮度）、二值化（用 Otsu 演算法或自適應閾值把影像分成黑白）、去噪（中值濾波、連通域面積過濾）、傾斜校正（用霍夫變換或投影法估算角度後旋轉）、去除邊框與表格線（形態學運算偵測長直線後抹除）。
這一步做得好不好，對辨識率影響極大。特別是「表格線」——很多紙本表單有格線，如果沒有先移除，OCR 引擎會把格線當成筆畫，把「1」認成「4」、把「0」認成「8」。這也是為什麼有些免費 OCR 工具在處理發票、對帳單時表現特別差。
版面分析與文字行偵測
前處理之後，系統要回答「哪裡有文字」。傳統做法是連通域分析（connected component analysis）：把相鄰的黑色像素黏成一個「連通域」，再依據面積、長寬比、密度判斷它是文字、雜訊還是圖形。接著用「投影剖面法（projection profile）」把同一水平線上密集的連通域合併成「文字行」，再依垂直間距切成「段落」與「欄位」。
現代系統則大量使用深度學習做版面分析，例如把頁面切成網格後用 CNN 分類每個區域是「標題」「正文」「表格」「圖片」「頁碼」，或用物件偵測模型（如 YOLO 系列、LayoutLM 系列）直接預測區塊邊界。這對多欄排版、圖文混排、表格密集的文件特別重要——如果版面分析把兩欄的文字錯併成一行，後面的字元識別再準也沒用，因為輸出的句子順序已經亂了。
字元識別：從傳統特徵工程到深度學習
真正的「認字」環節，就是把每個文字行的影像轉成字元序列。早期做法是「切割 + 分類」：把文字行切成單一字元，抽取特徵（如方向梯度直方圖 HOG、筆畫密度、Zernike 矩），再交給 SVM、KNN 或隨機森林分類。這種方法的致命傷是「切割錯誤」——中文字筆畫相連、英文連筆字（cursive）難以切分，一旦切錯，後面全錯。
後來主流轉向「免切割」的序列辨識。Tesseract 4 之後採用 LSTM（長短期記憶網路）搭配 CTC（Connectionist Temporal Classification）損失函數，直接把整行影像映射成字元序列，不需要先切字。更現代的系統則用 CRNN（CNN + RNN + CTC）或 Transformer 架構（如 TrOCR），甚至把「文字偵測」與「文字辨識」整合進同一個端到端模型（如 DBNet + CRNN 的組合）。
對中文而言，挑戰又更高一層。常用漢字數千，字形相近者極多（「己、已、巳」「未、末」「日、曰」），加上明體、黑體、楷體、手寫體的筆畫差異，模型必須看過大量樣本才能穩定辨識。這也是為什麼中文 OCR 的準確率通常比英文低幾個百分點，而「繁體中文」又比「簡體中文」更難——繁體字筆畫多、相似字更多，且高品質訓練資料相對少。
語言模型後處理與信心分數
字元識別完之後，通常還會接一層「語言模型」來修正明顯錯誤。例如辨識結果是「營菜收入」，語言模型會根據上下文判斷「營業收入」的機率遠高於「營菜收入」，於是自動替換。常見做法包括 N-gram 統計、詞典比對、以及近年流行的 BERT 類遮罩語言模型。有些系統還會輸出「信心分數（confidence score）」，讓使用者知道哪些字是「有把握」的、哪些是「猜的」，方便人工複核。
不過要提醒的是：後處理是把雙面刃。它能把「rn」修成「m」、把「0」修成「O」，但也可能把正確的專有名詞「改成」常見詞。對於合約、病歷、財報這類不容許誤差的文件，過度依賴自動修正反而危險，最好保留原始辨識結果並以信心分數標記。
五、OCR 與 PDF 閱讀器的整合：可搜尋 PDF 是怎麼被「造」出來的
OCR 辨識出文字與座標之後，下一步是把它「塞回」PDF，讓閱讀器重新具備文字層。這個產物一般稱為「可搜尋 PDF（searchable PDF）」或「OCR PDF」，它的頁面仍然保留原始掃描影像（所以視覺外觀不變），但在影像之上疊了一層「隱藏文字」。使用者在螢幕上看不到這層文字，卻可以選取、複製、搜尋，等於同時擁有「紙本外觀」與「電子便利」。
隱藏文字層的技術細節
技術上，工具會在頁面內容流裡追加一段文字繪製指令，並把文字渲染模式設為 3（Tr 3，invisible text rendering mode）。這個模式下，字形不會被填色、也不會描邊，等於完全透明，但閱讀器仍然會建立文字片段。為了讓文字位置與底圖對齊，工具會用 Tm（文字矩陣）把每個字放到 OCR 偵測到的座標上，並依字型寬度調整字距。
字型的選擇也有講究。有些工具會內嵌一個「通用字型」（如 Noto Sans）並建立 ToUnicode 對照表；有些則使用 PDF 內建的標準字型搭配自訂編碼。前者檔案較大但相容性好，後者檔案小但可能在某些閱讀器上出現亂碼。專業工具（如 OCRmyPDF）預設會內嵌字型並確保 Unicode 對照正確，這是它被廣泛用於文件數位化的原因之一。
座標對齊與字型映射的難題
聽起來很簡單，但實作上有幾個坑。第一，OCR 給的座標是「像素座標」，PDF 用的是「點（point，1/72 英吋）」，兩者之間要換算 dpi 與頁面旋轉。第二，OCR 的「文字行」可能包含不同字級、不同字型的混合內容，但隱藏文字層若只用單一字型，就可能出現「字距怪怪的」或「選取範圍偏移」。第三，旋轉文字（如表格側欄、浮水印）需要額外處理文字矩陣的旋轉分量，否則選取時會歪掉。
更細緻的問題是「詞邊界」。英文有空白，OCR 相對容易判斷詞與詞的界線；中文沒有空白，詞與詞之間要靠語言模型推斷。如果隱藏文字層把整行幾十個字都擠在一起，複製貼上到 Word 就會變成一長串沒有斷句的字，閱讀體驗很差。好的工具會依據字距與標點插入適當空白，甚至保留段落結構。
六、市面 PDF 閱讀與 OCR 軟體評測
理解原理之後，我們可以更有判斷力地看待市面上的工具。以下針對幾款常見軟體，從「閱讀體驗」「OCR 準確率」「格式還原」「價格與隱私」四個維度做評析。需要先聲明：OCR 準確率高度依賴文件品質（掃描解析度、字體、語言、版面），以下描述是「一般辦公文件」條件下的相對表現，實際結果仍會因檔案而異。
Adobe Acrobat Pro：整合度最高的老牌選手
Acrobat Pro 的優勢在於「它自己就是 PDF 標準的制定者」，對 PDF 結構的支援最完整。它的 OCR 功能（「辨識文字」）可以直接把掃描頁轉成可搜尋 PDF，並且支援多語言、自動偵測頁面方向、修正輕微傾斜。辨識後的文字層與底圖對齊相當準確，複製貼上到 Word 的段落結構也相對合理。缺點是價格高昂（訂閱制），且 OCR 對複雜表格的欄位還原仍有進步空間——它能把文字抓出來，但表格結構往往需要手動重建。
隱私方面，Acrobat 的 OCR 是在本機執行的（除非你使用雲端服務），對處理機密文件的公司來說是加分項。整體而言，如果你需要「一份工具解決閱讀、編輯、簽署、OCR」並且預算充足，Acrobat Pro 仍是最省心的選擇。
ABBYY FineReader PDF：OCR 準確率的標竿
ABBYY 長年被視為 OCR 領域的技術標竿，特別是對「複雜版面」的處理能力。它的強項在於版面分析與表格還原：多欄排版、跨頁表格、圖文混排的文件，FineReader 通常能保留較合理的閱讀順序與表格結構。它支援的語言數量極多，繁體中文的辨識表現在同級產品中屬於前段班。輸出格式也很彈性，除了可搜尋 PDF，還能轉成保留格式的 DOCX、XLSX、EPUB。
缺點同樣是價格偏高，且介面對於「只想快速 OCR 一份文件」的輕度使用者來說稍嫌複雜。另外，它的授權模式分為永久授權與訂閱制，選購時要看清楚版本差異（有些入門版有頁數或功能限制）。
Tesseract 與 OCRmyPDF：開源陣營的主力
Tesseract 由 HP 實驗室起源、後來由 Google 維護，是目前最廣泛使用的開源 OCR 引擎。它支援超過 100 種語言（包含繁體中文 chi_tra），第四版之後改用 LSTM 引擎，對一般印刷體的辨識率已經相當可用。它的優勢是「免費、可離線、可嵌入自家系統」，許多商業軟體的 OCR 底層其實也是它。
但 Tesseract 是「引擎」而不是「產品」，直接使用門檻較高。這時 OCRmyPDF 就派上用場：它是一個命令列工具，把 Tesseract 包裝成「為 PDF 加上文字層」的流程，能自動處理影像前處理、頁面旋轉、多執行緒，輸出標準的可搜尋 PDF。它基於 pikepdf 操作 PDF 結構，產出的檔案在 Acrobat、PDF.js、Foxit 上都能正常選取文字。對於需要批次處理大量掃描檔的 IT 人員或數位典藏單位，OCRmyPDF 几乎是首選。
它的限制是「沒有圖形介面」（雖然有第三方 GUI 如 OCRmyPDF-Web、Papermerge 等），且對極複雜版面的還原不如商業軟體。但以「免費 + 可自動化 + 隱私完全可控」這三點來說，性價比極高。
其他實用選擇：PDFelement、Foxit、線上工具
Wondershare PDFelement 與 Foxit PDF Editor 屬於「中間價位」的整合型工具，閱讀、編輯、註解、OCR 一應俱全，介面比 Acrobat 親民，價格也較低。它們的 OCR 準確率對一般文件足夠，但在多欄排版與表格還原上通常略遜於 ABBYY。Foxit 的閱讀器流暢度口碑不錯，適合以「閱讀為主、偶爾 OCR」的使用者。
線上 OCR 工具（如 Google Drive 內建 OCR、各種免費轉換網站）的優點是「零安裝、免費」，但缺点也很明顯：檔案要上傳到別人的伺服器，機密性堪憂；免費版常有頁數或檔案大小限制；辨識結果的文字層對齊品質參差不齊。建議只用於「不敏感、少量、一次性」的文件，千萬不要把身分證、合約、病歷上傳到不明網站。
七、選購與使用建議：什麼情況下你真正需要 OCR？
看完原理與評測，最後回到實務。以下幾個判斷點可以幫你決定「該不該花錢買 OCR 軟體」：
另外提醒一個常見誤區：OCR 不是萬靈丹。它能把「圖片上的字」變成「可選取的字」，但無法保證 100% 正確。解析度太低（低於 200 dpi）、嚴重歪斜、紙張皺褶、印章覆蓋、手寫潦草，都會讓辨識率大幅下降。實務上，重要的文件在 OCR 之後仍應人工校對，並保留原始掃描檔作為佐證。這也是為什麼正規的數位化流程（如政府檔案、圖書館典藏）都會把「OCR 文字層」與「原始影像」並存，而不是只留文字。
結語：OCR 是橋樑，不是終點
回顧整篇文章，我們從 PDF 的物件結構談到內容流的文字運算子，從閱讀器的渲染流程談到文字層的建立，再從掃描 PDF 的「無語意」困境，一路走到 OCR 的影像前處理、版面分析、字元識別與後處理。你會發現，PDF 閱讀與 OCR 其實是兩個不同層次的技術：前者負責「把檔案正確地畫出來」，後者負責「把像素裡的字找回來」。兩者結合，才有了我們熟悉的可搜尋 PDF。
下次當你打開一份掃描講義，發現 Ctrl+F 搜不到任何東西時，你就不會再誤以為「檔案壞了」，而會知道：「這是一份圖片型 PDF，我需要 OCR。」而當你選擇工具時，也會更清楚自己要的是「閱讀體驗」「辨識準確率」「批次自動化」還是「隱私可控」——因為這四件事，往往無法用同一套軟體同時滿足。
技術會持續進步，端到端的文件理解模型（Document AI）正在把「版面分析 + OCR + 問答」整合成單一流程，未來我們或許不再需要手動「先 OCR 再搜尋」，而是直接對整份掃描文件提問。但在那一天全面普及之前，理解 PDF 與 OCR 的基本原理，仍然是讓你在眾多軟體廣告中保持清醒的最好方式。毕竟，工具會換，原理不會。