OCR 技術深解：電腦如何學會從圖像中讀取文字

用十六進位編輯器打開任意一張圖片。一張路牌的照片，一張收據，一張 PDF 的截圖。偏移量為零時看到的是格式頭。再往下幾千位元組，就到了像素資料：RGB 模式下每個像素三個位元組，一個數字網格，其中 (128, 52, 19) 可能是一堵磚牆，而 (240, 238, 220) 可能是紙張。在這個網格中的某處，有一塊寫著"STOP"的停車標誌，白字紅底，字型是 Highway Gothic。人看到的是四個字母。電腦看到的是一個 47 × 19 的偏紅色像素區域，其中 R 通道接近 200，G 和 B 低於 40。將這塊區域對應到字串"STOP"，這就是光學字元辨識（OCR），自 1929 年 Gustav Tauschek 為第一臺閱讀機申請專利以來，它一直是一個開放的研究問題。

OCR 的難度是欺騙性的，因為閱讀本身太容易了。一個六歲的孩子能認出幾十種字型裡的字母 A，不同大小、光線不均、輕微旋轉、部分遮擋、用鉛筆寫的——全都能認出來。而電腦需要的是一條流水線：清理圖像、找到文字區域、分割字元或字形序列、然後逐一分類。每個階段都有各自的失敗模式，而失敗會層層累積。

OCR 為什麼這麼難

核心問題並不是分類。將一張預分割好的 28 × 28 字元圖像分到 62 個類別（A–Z、a–z、0–9）中，這個任務 90 年代的 LeNet 就能做到 99% 的準確率。真正的難點在於分類器之前的所有步驟。

字型差異。 字母"g"至少有四種常見的結構變體：單層式（手寫體）、雙層式（大多數襯線字型）、Helvetica 的環尾式，以及 Futura 的開尾式。一個用 Tahoma 訓練的模型在遇到 Univers 字型時會以可測量的頻率出錯。實際場景中的 OCR 要涵蓋數百種字型，再加上手寫——而手寫根本沒有一致的筆畫拓撲結構。

幾何畸變。 文件照片很少是平板掃描的效果。用手機拍一張收據會引入透視傾斜、彎曲和不均勻的縮放。靠近書脊的文字會彎曲。白板照片會拍進攝影師的影子。10 度的傾斜就能讓 Tesseract 的準確率從約 97% 降到 85% 以下（基於標準基準測試）。去傾斜演算法（霍夫線檢測、Radon 變換、投影輪廓分析）能挽回一部分損失，但無法全部挽回。

光線與雜訊。 不均勻的光線把統一背景變成了漸層，破壞了全域閾值化。JPEG 壓縮偽影在銳利邊緣周圍產生振鈴效應——在 OCR 的語境下，這意味著字母筆畫周圍產生振鈴。低光感測器的椒鹽雜訊用深色像素填滿空白區域，看起來像標點符號。影印件再影印會讓細筆畫黏連在一起，把"rn"變成"m"，把"cl"變成"d"。

版面複雜性。 文件包含分欄、圖註、表格、頁首、頁尾和側邊欄。文字環繞圖片流動。有些語言從右向左書寫。有些在同一段落中混合方向。識別閱讀順序（哪塊文字在前，哪塊在後）是一個獨立於辨識之外的版面分析問題，順序搞錯了，即使每個字元都分類正確，輸出也會被打亂。

上下文歧義。 僅憑像素圖案，"0"（數字零）、"O"（大寫字母 O）和"o"（小寫字母 o）在許多無襯線字型中是完全一樣的。"1"、"l"、"I"和"|"共享同一根豎線。解析度增加了另一個維度：在 12 像素高度下，"e"和"c"的區別僅在於一根三像素寬的橫線。人類讀者靠上下文來分辨這些。機器需要語言模型——無論是統計的還是學習的——來做出同樣的判斷。

傳統 OCR 流水線

在深度學習出現之前，OCR 是一系列手工設計的階段。每個階段由不同研究團隊獨立開發，並針對某種特定的退化場景進行調校。這條流水線大致如下：

原始圖像 → 預處理 → 二值化 → 去傾斜 → 版面分析
  → 字元分割 → 特徵提取 → 分類 → 後處理（語言模型） → 文字輸出

預處理與二值化

彩色圖像先轉為灰階。降噪在閾值化之前平滑訊號。中值濾波處理椒鹽雜訊。高斯模糊處理感測器雜訊。當需要保留邊緣時則使用雙邊濾波。

二值化將灰階圖像轉為白色背景上的黑色文字。標準演算法是大津演算法（Otsu's method，1979 年發表）：它窮舉搜尋能最小化前景與背景像素分佈類內變異數的閾值。大津演算法假設圖像具有雙峰直方圖（文字像素聚集在某一個強度值，背景像素聚集在另一個），這在受控光線下的平板掃描上效果很好，但在有陰影的手機照片上會失敗。區域自適應方法（Sauvola、Niblack）根據每個像素鄰域的統計量計算不同的閾值，能處理不均勻光線，但代價是邊緣附近會產生偽影。

去傾斜與版面分析

文件傾斜透過對邊緣像素做霍夫變換，或透過投影輪廓分析來檢測——在角度範圍內旋轉文件，選擇水平投影峰值最尖銳的角度。獲知傾斜角度後，用仿射變換將圖像旋轉回來。

版面分析將頁面分割為文字區塊。經典方法是執行連通分量分析（CCA）來找出前景像素的連通區域，按鄰近度將其分組為詞，再將詞分組為行，將行分組為區塊。XY-cut 演算法透過沿水平和垂直投影尋找空白間隙來遞迴地切分頁面，構建出區域樹。現代實作採用混合方式：用 CCA 做初始區域檢測，再用學習模型將每個區域分類為文字、圖片、表格或分隔線。

字元分割

對於機器印刷的文字，分割意味著將詞圖像切割為獨立的字元。垂直投影輪廓（每列前景像素計數的直方圖）在字元中心處產生峰值，在字元邊界處產生谷值。這個方法在兩個字元粘連，或一個字元包含不連續的部分（"i"、"j"、":"、"%"）時會失效。一種處理方案是先過度分割（切得過細），再根據分類器置信度進行合併。另一種方案是完全跳過分割，直接辨識整個詞——這正是現代基於序列的方法所做的。

特徵提取與分類

有了字元圖像後，需要用數值來描述它，以便送入分類器。深度學習之前的特徵包括：

• 原始像素值，展開為一維向量（簡單，但對平移和縮放很脆弱）
• 分區法（Zoning）：將字元邊界框劃分為 N × N 的網格，統計每個儲存格的前景像素數，用這些計數作為特徵
• 梯度特徵（HOG）：方向梯度長條圖捕獲邊緣方向資訊，對小幅平移較為強健
• 尺度不變特徵變換（SIFT）：檢測並描述對尺度、旋轉和光線不變的關鍵點

分類器通常是帶有 RBF 核的支援向量機（SVM），針對每種字型用數萬張標註字元圖像進行訓練。一套調校得當的 SVM + HOG 流水線在乾淨印刷文字上可以達到約 98% 的單字元準確率。但同樣的流水線在面對雜訊、傾斜或手寫輸入時，準確率會跌到 70–80%。

Tesseract：從 HP 實驗室到 LSTM

Tesseract 是開源 OCR 引擎的標竿。它始於 1980 年代 HP 實驗室 Bristol 的一個博士專案，2005 年開源，2006 年起由 Google 維護。其架構清晰地分為兩個時代。

版本 3：經典流水線

Tesseract 3 實作了傳統流水線並做了若干創新。其版面分析使用了一種定位點檢測演算法，透過對齊詞的邊界框來找到列邊界——這是在 90 年代 HP 掃描典型文件時調出來的實用啟發式方法。字元分割使用了切分器/關聯器（chopper/associator）邏輯：切分器將詞圖像過度分割為候選切割點，關聯器利用分類器置信度和詞典來決定哪些切割點應該合併。

分類器是一個雙通道系統。第一通道（靜態分類器）將分割後的連通區域與原型（聚類後的訓練樣本）進行最近鄰匹配。第二通道（自適應分類器）在文件本身上進行微調，學習該圖像中使用的具體字型。自適應分類器大約需要一頁文字才能變得有效，這就是為什麼 Tesseract 3 在路牌和圖註等單次圖像上表現不佳的原因。

Tesseract 3 以 .traineddata 檔案的形式發布：這些歸檔檔案包含原型聚類、字元集定義、詞頻詞典，以及一張對應易混淆字元對的 unichar 歧義表。訓練一種新語言需要給 Tesseract 提供文字圖像及其對應的真值轉錄、框出每個字元，然後執行訓練工具。每種語言需要數小時的處理時間。

版本 4/5：LSTM 取代流水線

Tesseract 4（2018 年）用單個 LSTM 神經網路替換了整條辨識路徑。LSTM 對文字行圖像的垂直切片序列進行操作，每個切片寬度為一個像素，高度為整行文字。每個切片被送入堆疊的雙向 LSTM 層。輸出是一系列字元機率，使用連結時序分類（CTC）損失函數將可變長度的輸出序列與真值文字對齊，無需預分割的字元位置。

LSTM 模型無需切分器/關聯器的機制，就能處理變寬字元、粘連字元和字型差異。它仍然依賴 Tesseract 遺留的版面分析來尋找文字行，但行辨識是完全端到端的神經網路。在 ICDAR 2017 基準測試上，Tesseract 4 在印刷英文上達到了 4.4% 的字元錯誤率（CER），而 Tesseract 3 為 7.2%。訓練過程也從遺留的逐字框選工具切換為將文字行與轉錄文字配對。仍然是監督學習，但每行只需一個標籤，而不是每個字元一個。

.traineddata 格式被擴展為在單個檔案中同時儲存 LSTM 模型權重（數 MB）和遺留資料（詞典、unichar 表）。對於拉丁字母語言（約 100 個字元類別），在現代 GPU 上從頭訓練一個快速 LSTM 模型大約需要 24 小時；CJK 語言由於字元集更大，需要更長的時間。

準確率特性

Tesseract 5 在版本 4 的基礎上擴大了訓練語料並最佳化了預設參數，但架構沒有變化。準確率高度依賴輸入條件：

LSTM 模型消除了版本 3 的大部分字型敏感問題，但引擎在以下場景仍然會退化：低解析度（低於 200 DPI 時，LSTM 的像素切片輸入會丟失筆畫細節）、手寫文字（模型是在印刷字型上訓練的；手寫具有根本不同的筆畫統計特徵）、複雜版面（版面分析仍然是遺留程式碼路徑，而非神經網路路徑）。

現代深度學習方法

學術上，OCR 大約在 2019 年超越了 CTC + LSTM 範式。目前文獻中有三種架構佔據主導地位。

CRNN + CTC

卷積迴圈神經網路（CRNN）由 Shi 等人於 2015 年發表，它將 CNN 特徵提取器與 RNN 序列模型和 CTC 解碼配對使用。CNN 從圖像中提取空間特徵，本質上是在學習 Tesseract 中 LSTM 需要手工獲取的東西（垂直切片表示）。RNN 對提取出的特徵之間的序列依賴關係進行建模。CTC 處理對齊問題。CRNN-CTC 成為標準基線：端到端可訓練，泛化能力好，推理速度快（GPU 上約每行 20 ms）。

基於注意力的編碼器-解碼器

基於注意力的模型借鑑了機器翻譯中的 seq2seq 範式。CNN 或視覺編碼器生成圖像的特徵圖。RNN 解碼器一次一個字元地生成輸出文字，每一步都關注特徵圖的相關空間區域。注意力機制消除了 CTC 的單調約束：解碼器可以在語言模型預期出現重複模式時跳回圖像的更早部分，但這種靈活性也為不可辨認的輸入帶來了幻覺風險。基於注意力的解碼器在乾淨印刷英文上達到約 1.5–3% 的 CER，在長序列和不規則版面上優於純 CTC 模型。

Vision Transformer（TrOCR、Donut）

TrOCR（Microsoft，2021 年）將 Transformer 架構應用於 OCR。圖像被分割為補丁（patch），由 ViT（Vision Transformer）編碼器編碼，文字由 Transformer 文字解碼器自迴歸地解碼。這是一個標準多模態模型的架構，專門為 OCR 而訓練。TrOCR 在印刷文字上取得了最先進的結果（乾淨掃描上低於 1% CER），無需任何 CNN 預處理、顯式語言模型或字元級分割。

Donut（NAVER，2022 年）將這一方法擴展到文件理解：輸入是整張文件圖像，輸出是直接從視覺特徵中提取的結構化 JSON，完全跳過了 OCR → NLP 的流水線。這模糊了 OCR 與文件解析之間的界限，對實際應用來說意義重大：提取發票總額、護照號碼或研究論文中的表格，變成了單次模型呼叫，而不是 OCR + 正則 + 啟發式規則。

效能對比（印刷英文，乾淨 300 DPI）

在基準測試上，Tesseract 與最佳 Transformer 模型之間的差距是真實存在的。在實務中，這種差距會縮小，因為大多數部署系統餵給 Tesseract 的都是乾淨、光線充足、300 DPI 的輸入，在這種輸入下，1.8% 的 CER 意味著每 55 個字元中有一個錯誤。對於搜尋索引來說可以接受，對於法律文件的轉錄來說則不盡然。

非英文 OCR：為什麼更難

英文 OCR 已經是一個已解決的問題。26 個大寫字母、26 個小寫字母、10 個數字和少量標點——總共約 70 個類別，一個多分類問題，90 年代的 LeNet 就綽綽有餘。世界上的其他書寫系統則沒有那麼寬容。

CJK：字元集爆炸

中文、日文和韓文（CJK）僅從字元集規模上來說就是最難啃的 OCR 挑戰。簡體中文約有 3,500 個常用字，通用文字中超過 6,000 個。繁體中文還要再加一千多個變體。日文將兩種音節文字（平假名、片假名：各 46 個字元）與約 2,000 個常用漢字以及拉丁字母數字混合在同一句子中。韓文（諺文）在音系上是規則的（24 個基本字母組合成音節塊），但視覺上非常密集：單個音節塊最多可包含六個基本 jamo 組件，擠在約兩個拉丁字元並排的空間中。

CJK OCR 系統不能將辨識視為 70 路分類問題。日語至少要 4,000 路分類，簡體中文要 6,000 路，繁體中文則超過 10,000 路。僅 softmax 輸出層的參數量就超過一整個拉丁字母 OCR 模型。訓練資料需求隨字元集規模而增長：要達到可接受的準確率，每類約需 100 個標註樣本，因此中文訓練集起步就是 60 萬張文字行圖像。

Tesseract 提供了 CJK 的 traineddata 檔案（chi_sim、chi_tra、jpn、kor），但它們比拉丁模型大得多。chi_sim.traineddata 約 50 MB，而 eng.traineddata 約 15 MB，且由於輸出空間更大，辨識速度也更慢。Tesseract 5 在乾淨印刷 CJK 文字上的準確率約為 2–5% CER，大約是在同等條件下的英文錯誤率的 2–3 倍。

阿拉伯文與從右向左的書寫系統

阿拉伯文除了字元集問題（28 個字母，每個字母根據在詞中的位置有不同的上下文形態）之外，還增加了兩個難題。第一，它從右向左書寫，所以 OCR 引擎必須檢測文字方向並反轉輸出順序。第二，阿拉伯文是連寫的——詞內字母透過基線筆畫相互連接，因此分割天然比拉丁和西里爾字母的分離式字元形態更難。一個阿拉伯文詞圖像是一個連續的連通區域；基於字元的分割實際上是不可能的，這也是為什麼 LSTM/CTC 方法（在詞圖像上操作而無需字元分割）對阿拉伯文 OCR 的突破比對英文 OCR 更大。

希伯來文、烏爾都文、波斯文和普什圖文共享其中部分挑戰的組合。Tesseract 提供了阿拉伯文 traineddata，但在乾淨印刷文字上的準確率約為 5–8% CER，大約是同等條件下英文的 4 倍。

印度系文字：連字問題

天城文（印地語、馬拉地語、尼泊爾語）和其他婆羅米系文字代表了一種獨特的挑戰：書寫單位不是字元，而是連字（conjunct）——一個輔音、一個母音修飾符、有時再加一個輔音在視覺上融合成的簇。Unicode 天城文區塊有 128 個碼點，但可能的連字數量超過 1,000 個。"Shirorekha"（連接詞內字元的水平頂線）使分割更難，因為頂線將相鄰字元合併為一個視覺單元。

Tesseract 的印地語 traineddata（hin）覆蓋了常見的連字，但在印刷文字上的準確率比英文差 3–4 倍。泰米爾文、泰盧固文、孟加拉文及其他印度文字的覆蓋更不完善，有些甚至完全沒有官方的 traineddata 檔案。根本原因是訓練資料量：印地語有數百萬張高品質的標註文字行圖像，而康納達語的可用資料集只有數萬張。

直排文字與混合方向版面

日文和繁體中文有時採用直排，行從上到下，列從右到左。Tesseract 的版面分析假設文字是水平排列的；直排文字需要預先旋轉或使用單獨的引擎。同一頁上同時出現水平和直排文字（在日本報紙和漫畫中很常見）完全打破了單一方向假設，需要在辨識之前進行區域級別的方向檢測。

小語種與訓練資料

對於使用人數少於 1,000 萬的語言，高品質的 OCR 訓練資料幾乎不存在。Unicode 聯盟已經編碼了 150 多種文字系統，但 Tesseract 大約只為 120 種語言提供了 traineddata，其中許多是用標準字型在乾淨背景上生成的合成文字。合成資料適用於常見字型下的印刷文字，但對於實際文件中出現的字型、紙張和印刷品質則會失效。一個在 300 DPI 下用合成 Arial 訓練的模型，無法讀取 1970 年代打字機敲出的阿姆哈拉語文件。

瀏覽器端 OCR：Tesseract.js

在 WebAssembly 面世之前，在瀏覽器中執行 OCR 是不現實的。Tesseract.js 透過 Emscripten 將 Tesseract 5（LSTM）編譯為 WebAssembly，用 JavaScript API 封裝 C++ 引擎，並為每個辨識任務執行一個 Web Worker。引擎、語言資料和 Worker 都從靜態資源載入。圖像資料無需往返伺服器。

API 介面很簡潔：建立一個指定一種或多種語言代碼的 Worker，傳入圖像，返回辨識出的文字及每個字元的置信度分數。多個 Worker 可以並行執行，受限於可用的 CPU 核心數。消費級筆記型電腦上通常可以同時跑 4 個辨識任務，最新的手機上可以跑 6 到 8 個。

效能受三個因素制約。第一，WebAssembly 執行速度約為原生的 50–70%；在原生 Tesseract 中耗時 100 ms 的文字行，在瀏覽器中大約需要 160 ms。第二，traineddata 檔案透過網路載入。eng.traineddata 約 15 MB，chi_sim.traineddata 約 50 MB，兩者都需要完全下載後才能開始辨識。第三，圖像解碼（JPEG/PNG/WebP/HEIC 到原始像素資料）使用瀏覽器內建的解碼器，速度很快，但會因格式和裝置而異。

隱私優勢是結構性的。客戶端 OCR 意味著圖像永不離開裝置。護照照片、銀行對帳單、醫療記錄——像素在瀏覽器中解碼，相當於 Textract 的功能在 Web Worker 中執行，結果是一段使用者可以複製或儲存的文字。沒有資料中心處理該圖像。這不是一個功能，而是伺服器的缺失——這與承諾「我們不會看」的隱私政策在本質上是不同的。

我們的 Image to Text 工具執行的就是這套技術棧：Tesseract.js 配合 LSTM 辨識、Web Worker 並行處理，以及 12 種語言的 traineddata（英文、西班牙文、法文、德文、葡萄牙文、義大利文、簡體中文與繁體中文、日文、韓文、印地文和俄文）。拖入一張照片，選擇語言，獲得文字。該工具讀取 JPEG、PNG、WebP、BMP 和 GIF 輸入，應用解析度感知預縮放（最長邊超過 3,000 像素的圖像會被縮小，以保證辨識延遲處於合理範圍），並輸出每張圖片的純文字，附帶每字元置信度。

圖像格式的選擇在實務中影響 OCR 品質。來自 iPhone 的 HEIC 照片，在轉換為 JPEG 後進行 OCR 時，會在文字邊緣周圍產生壓縮偽影，降低辨識準確率。先將 HEIC 轉為 PNG（無失真，無量化偽影）則可以保留 LSTM 所依賴的銳利邊緣。我們的 HEIC to JPG 和 HEIC to PNG 轉換器直接在瀏覽器中完成這一預處理步驟。同樣，在低光環境下拍攝的照片，在閾值化之前轉換為能保留完整色調範圍的格式會更有優勢：JPG to PNG 可以避免 JPEG 來源檔案重新編碼時產生的二次壓縮偽影。

瀏覽器 OCR 技術棧在吞吐量上無法與 GPU 加速的伺服器端模型競爭。一臺在 32 個 CPU 核心上執行原生 C++ Tesseract 的伺服器，總能跑贏一個瀏覽器分頁。它的優勢在於隱私、零基礎設施和每次請求零成本。對於掃描幾頁檔案、一張收據或幾個路牌來說，200 ms 和 50 ms 之間的延遲差異是察覺不到的。

OCR 的未來走向

OCR 大約從 2022 年起不再是一個獨立的研究領域，而是融入了更廣闊的文件 AI 和多模態模型空間。三個轉變正在發生。

多模態大語言模型作為零樣本 OCR。 GPT-4V、Claude 和 Gemini 可以在沒有顯式 OCR 訓練的情況下從圖像中讀取文字。給模型一張文件照片並索要文字，它就會返回。不是因為它有一個專門的 OCR 頭，而是因為文字辨識能力從數十億圖像-文字對的訓練中湧現出來。品質並不均勻。在乾淨印刷英文上，GPT-4V 達到約 1% CER，與微調後的 TrOCR 相當。在中文收據的低解析度手機照片上，它可以勝過 Tesseract，因為模型利用了上下文（它知道收據長什麼樣，以及應該期待哪些數字），而不僅僅依賴像素級證據。在手寫文字上，它比微調後的辨識器差，因為訓練分佈中沒有包含足夠的手寫圖像。

權衡是成本和延遲。呼叫一次 GPT-4V 進行 OCR，根據 token 數量計算，每頁成本 1–3 美分，耗時 1–3 秒。Tesseract 在本機執行，每頁 100–500 ms，成本為零。掃描一份 200 頁的文件，差值是 2–6 美元和數分鐘的牆上時間，對比零成本和不到一分鐘。對於一次性使用（一張收據、一張白板照片），多模態模型更簡單且往往更準確。

端側推理。 支撐伺服器端 OCR 的模型正在縮小。ONNX Runtime Web 在瀏覽器中執行量化後的 CRNN 和小型 ViT 模型，在使用 WebGPU 時每行文字 50–100 ms。Apple 的 Vision 框架在 iOS 和 macOS 上內建了一個緊湊的 OCR 模型，透過 VNRecognizeTextRequest 即可存取，無需網路請求。「伺服器 GPU 模型」和「瀏覽器模型」之間的差距正在縮小，因為兩者都趨向同一個架構甜蜜點：一個小型 ViT 編碼器（約 2,000–5,000 萬參數）加上輕量解碼器，量化為 INT8 或 FP16。

文件理解，而非僅僅是轉錄。 OCR 的輸出是一個字串。大多數實際任務涉及從該字串中提取結構化資訊：發票號碼、日期、總額、姓名、地址。傳統方法將 OCR 與正則表達式、命名實體辨識和模式對應串聯使用。每個階段都是一個獨立的模型，有各自的失敗模式。端到端文件理解模型（Donut、LayoutLMv3、Pix2Struct）跳過 OCR，將文件圖像直接對應為結構化輸出。一個在收據上微調的 Donut 模型不會先生成文字轉錄再解析它，而是直接從像素輸入生成 {"total": "42.50", "date": "2026-07-27", "vendor": "..."}。OCR 這一步驟——本文的主題——變成了一個不可見的實作細節。

這並不意味著 OCR 被淘汰。它變成了一個構件。這條流水線仍然需要處理邊緣情況：在昏暗餐廳裡斜著拍的收據、泛黃紙張上 50 年前的打字文件、沒有哪個大型多模態模型訓練過的語言的標誌。針對這些特定分佈訓練的專業 OCR 引擎，在速度和效能上將超越通用模型多年，因為一個在整個網際網路上訓練的通用模型，只將其微乎其微的一小部分能力分配給了閱讀 1970 年代阿姆哈拉文打字機輸出。

對於世界上的大多數語言和大多數真實成像條件來說，OCR 並不是一個已解決的問題。它只在一個最窄、資金最充足的子集上被解決了：乾淨、300 DPI、英文、單欄、機器印刷的文字。其餘的，仍然開放。