先讀範圍，再決定 OCR 的結果能用到哪裡。

• 一次一個動作：選圖、載入模型、開始辨識、檢查結果。圖片單張上限 25 MiB、一次至多 20 張（PNG、JPEG、WebP、BMP、GIF、AVIF）；長邊超過 3200 像素會縮小，超過的檔案會明確說明原因。
• 辨識模型約 7.42 MiB，要你按下「載入辨識模型」才會下載；只有英數的模式約 5.84 MiB。瀏覽器支援 SIMD 時用較快的核心，不支援就用相容核心。
• 前處理依每張圖自動建議（灰階、對比拉伸、區域對比、去除表格線、反相、放大 2×、傾斜校正），都可以手動改；原圖不會被改動。
• 辨識在背景 Worker 執行，一次處理一張，隨時可取消；取消會立刻終止辨識程式，要再辨識需重新載入模型。
• 結果可直接編輯；逐行顯示信心（偏低的行用文字 ▲ 標示，不只靠顏色）；可在原圖上疊框，點一行就標出它在圖上的位置；多張圖可切換或合併。
• 擷取面板：手機、市話、網址、Email、金額、日期時間、統一編號、疑似帳號／卡號、LINE ID，每項一鍵複製；可選「遮蔽後輸出」。
• 輸出：複製文字、TXT、JSON（含座標、信心、引擎版本、前處理與用時，不含圖片）、CSV（每行一列）、「送到線索推理艙」。

• 不上傳、不聯網（除了從本站載入程式與模型檔）、不使用任何瀏覽器儲存空間（含 cookie、IndexedDB、CacheStorage）。
• 不自動「更正」數字或文字。易混淆的字（例如夾在數字裡的 O、l）只會標示「請對照原圖」。
• 不辨識手寫字、藝術字、直書；不處理 HEIC、PDF、TIFF（請先轉成圖片）；不做長截圖分塊（超長圖縮小後字可能太小，請先裁切）。
• 不判斷圖片是否被修改，也不判斷來源或時間。
• 不提供準確率承諾，也不排名比較其他 OCR 工具。

• 引擎：tesseract.js 7.0.0（Apache-2.0）搭配 tesseract.js-core 6.1.2（內含 Tesseract 5.1.0）與 tessdata_best 的整數量化版 chi_tra、eng（僅 LSTM）。注意：tesseract.js 7.0.0 的套件宣告相依 core 的 ^7.0.0，本站放的是 6.1.2，不是上游列出的組合；我們在本站的安全政策下測過載入與辨識，但沒有測過所有情境。來源、sha256 與授權在 /v236-ocr/README.txt。
• 灰階：亮度 ＝（77 R ＋ 150 G ＋ 29 B）÷ 256。對比拉伸：把第 1 與第 99 百分位拉到 0 與 255，範圍小於 16 色階時略過。Otsu 二值化：自動取閾值，預設不開。
• 區域對比：輸出 ＝ 255 －｜像素 － 區域平均｜× 比例；視窗為長邊的 4%（限 15 至 75 像素的奇數），比例以偏差的第 99.5 百分位為準。目的是把對話泡泡、色塊的底色抹平；缺點是泡泡邊緣會留下淡淡的暈邊，可能讓部分圖變差。
• 去除表格線：以 Otsu 把較少的那一類當墨色，找連續長度至少 60 像素且至少 30% 邊長、厚度不超過長邊的 0.4%（6 至 16 像素）的橫線與直線；同向至少 3 條，或橫直各至少 2 條才會建議去除。（V236 開發時曾把文字筆畫誤判成直線，現已收緊。）
• 傾斜校正：投影輪廓法，在 ±12° 內每 0.5° 試一次再細調到 0.1°；偵測角度至少 0.8° 且得分增益至少 1.04 倍才建議校正。
• 兩種前處理比較：畫面有兩個以上明顯的底色群而自動建議了區域對比時，會另外用「一般灰階」（其他設定不變）再辨識一次，採用「信心加權字數」較高者（每行：信心 ÷ 100 × 字數，加總）。結果頁會寫出兩者的分數。這個分數是引擎自己的估計；它在調參用的合成圖上大多選到較好的一種，但不承諾每張都選對。你自己改過前處理設定的圖不會再多跑一次。
• 放大 2× 重辨：首輪行高中位數小於 14 像素、完全沒有結果、或整體信心低於 45，且還能再放大至少 5% 時，放大 2× 再辨識一次，同樣以信心加權字數擇優。
• 信心分級：行信心低於 70 標為偏低，85 以上為較高，中間為中等。整體信心以字數加權平均，另列中位數與最低值。
• 擷取與遮蔽：手機與市話依台灣號碼格式；統一編號以檢查碼比對（與本站統編查驗的檢查邏輯交叉測試）；10 至 16 位的長數字只標記「疑似帳號／卡號」並做 Luhn 檢查；全形數字會先折成半形再比對。遮蔽規則：電話與統編保留最後 3 碼，帳號與卡號保留最後 4 碼，Email 只留首字與網域，網址遮蔽 ? 之後的內容，LINE ID 只留前 2 碼。
• 輸出：JSON 的座標單位是原圖像素（左、上、右、下）；CSV 中以 = + - @ 開頭的儲存格會在前面加單引號，避免試算表當成公式；「送到線索推理艙」只用同源 postMessage，需要你按按鈕、最多等 12 秒、文字上限 20 萬字，失敗會說明原因並建議改用複製文字。

• 逐行對照原圖：到「對照原圖」分頁，點一行，圖上會標出它的位置；先看標示偏低的行，再看所有數字。
• 量自己的錯誤率：手動打出一小段正解，用下面的 Python（不依賴本站任何程式）算字元錯誤率 CER ＝ 編輯距離 ÷ 正解長度（比對前移除所有空白與換行）。

import re, unicodedata
def strip(s): return re.sub(r"\s+", "", unicodedata.normalize("NFC", s))
def edit(a, b):
    prev = list(range(len(b) + 1))
    for i, x in enumerate(a, 1):
        cur = [i]
        for j, y in enumerate(b, 1):
            cur.append(min(prev[j] + 1, cur[j - 1] + 1, prev[j - 1] + (x != y)))
        prev = cur
    return prev[-1]
truth = strip(open("truth.txt", encoding="utf-8").read())
ocr = strip(open("ocr.txt", encoding="utf-8").read())
print("CER = %.3f" % (edit(truth, ocr) / max(1, len(truth))))

• 確認沒有外送：用瀏覽器開發者工具的「網路」分頁，載入並辨識一次，應該只有本站網域的請求（頁面、程式、模型檔），沒有其他網域，也沒有上傳。
• 核對模型檔：用 sha256sum 對 /v236-ocr/ 底下的檔案計算，與 README.txt 列出的值比對。
• JSON 可以用任何語言讀取：每一行有座標與信心，沒有圖片資料。

下表是 12 個合成情境加 3 個更小字的補充情境（Noto CJK 繁體字型畫出來的圖，有標準答案），在真實頁面、預設設定下各辨識一次的結果。CER ＝ 編輯距離 ÷ 正解長度，比對前移除所有空白與換行；「NFKC 後」是另外把全形半形等相容字元統一後再算；「不看順序」把正解與結果各當成一袋字元，只算多少字不同，與 CER 的差距大致就是版面順序或換行位置造成的部分。對話截圖的正解以畫面幾何順序（由上而下、同一列由左而右）定義，時間戳記在泡泡旁，這類順序常被引擎排得不同。

平均（未加權，只算最初的 12 個情境）：文件與小字類 2.2%、對話截圖 19.7%、表格 0.0%。字小於 12 像素時誤差明顯變高，即使有自動放大 2× 重辨也一樣；單一樣本，不要從 9、10、11 px 的先後推論趨勢。這些是乾淨的合成圖；真實的螢幕截圖、斜拍的照片、手寫、反光與摩爾紋都沒有涵蓋，真實世界的誤差通常更高，不能拿這張表當成準確率。

對話截圖的結果不穩定。另外用一批調參用的合成圖（18 張對話截圖，含淺色、深色、三種泡泡配色，不是上表那 12 張，也同時用來挑規則，所以偏樂觀）比較：只用灰階平均 CER 為 35.7%，只用區域對比為 31.7%，兩種都跑並取信心加權字數較高者為 23.5%。這就是「兩種前處理比較」存在的原因。

速度與資源（本機沙箱小樣本，單次量測）

桌面完整流程（選圖、載入、辨識、輸出）主執行緒超過 100 ms 的長任務：0 次。手機模擬（4× 降速）：1 次，發生在頁面載入階段（起點 113 ms、長 118 ms），辨識與前處理期間沒有。

• 「信心高就是對」：信心是引擎的自我估計，會把相似字讀成通順但錯誤的字，而且信心依然偏高。
• 「看起來通順就沒錯」：OCR 的錯字常常剛好是另一個常見字；金額與帳號少一位也一樣通順。
• 「放大、二值化一定更準」：不一定。放大對小字常有幫助，二值化與區域對比對某些底色反而變差；所以預設只做自動建議的處理，必要時再手動比較。
• 「對話截圖的時間戳記順序一定對」：時間戳記通常貼在泡泡旁，可能被排在不同位置，請對照原圖。
• 「遮蔽後就可以隨便分享」：遮蔽只處理擷取到的特定樣式，不承諾涵蓋所有個資；JSON 與 TXT 也可能含有姓名、地址等其他內容。
• 「模型載一次就一直在」：本頁不使用瀏覽器儲存空間，重新整理或關閉分頁後要再載入一次（瀏覽器自己的一般快取可能讓再次載入比較快，但不是本頁控制的）。
• 「這是官方鑑識結果」：不是。它沒有任何時間戳、簽章或第三方背書。

• 量測只用合成圖；真實截圖、手寫、斜拍、陰影、反光、摩爾紋、直書、藝術字沒有測過。
• 真實手機的速度與記憶體沒有量過；CPU 降速只放慢主執行緒，不能代表手機上的辨識時間，低階手機可能要等很久，也可能因記憶體不足而中止。
• 模型檔以 .gz 原樣放在站上；正式站（Netlify）對這類檔案的回應標頭沒有實測，本頁只在自己的測試站驗證過。
• tesseract.js 與 core 的版本搭配不是上游列出的組合（見上面「引擎」）。
• 極長的截圖不分塊處理，會縮小到長邊 3200 像素，文字可能因此太小。

• 一次建議不超過 2 種，最多 3 種；超過會擋下並說明原因。每多選一種，要多下載一個模型（約 0.9 至 2.0 MiB）、多用一些記憶體與時間。
• 選簡體中文時，辨識完成後可勾選「轉為繁體」，用 OpenCC 轉成臺灣用字與用詞；原始辨識的簡體文字會保留，不會遺失。
• 換了語言組合，就要重新載入模型。

• 不自動判斷圖片是什麼語言，要你自己選。
• 簡轉繁的詞彙不一定全部正確；人名、地名、專有名詞與同形異義字仍可能轉錯，請對照原圖。
• 不處理直書、手寫字與藝術字。

用程式合成的三張圖（文件、小字、截圖樣式；每種語言四行字）量測字元錯誤率 CER（比對前移除空白與換行）。樣本很小，只能看出大方向，不代表你的圖。

簡體中文的另一份量測：辨識結果對照簡體正解，CER 為 0 ／ 0 ／ 0.028；轉成繁體後與 OpenCC 預期結果相同（差異同為 0 ／ 0 ／ 0.028，截圖樣式多出一個雜訊字）。

• 三種語言同時選時，部分組合會明顯變差：例如「繁體中文＋日文＋韓文」在韓文樣本上 CER 約 1.0，「日文＋韓文＋英文」在繁體中文樣本上 CER 約 0.90。語言越多，引擎越容易把相近的字形判成別的語言。
• 這是小樣本的觀察，不是通則；你的圖可能比較好，也可能更差。建議一張圖只選真正出現的語言。
• 辨識時間隨語言數增加：本機沙箱量測四行短文，兩種語言約 3 秒，三種語言約 5 至 7 秒；你的裝置會不同。

1. 偵測：依辨識出的文字與座標比對規則，列出每一項、類型、信心與理由。
2. 檢查：信心高與中的項目預設勾選，信心低的預設不勾；逐項勾選或取消，點一項就在圖上標出位置。
3. 手動加框：偵測不到的地方，用「畫框」自己拉出矩形；可復原。
4. 產生：輸出每張圖的塗黑版 PNG，可單張下載或打包成 ZIP。
5. 驗證：對塗黑後的圖再辨識一次，檢查已選項目的文字是否還讀得到；讀得到會明確警告。

• 身分證字號樣式、居留證號樣式、護照號碼（需要標籤）、信用卡號（含 Luhn 檢查）、手機、市話、國際電話、Email、網址、LINE ID／社群帳號、銀行帳號、IP 位址、經緯度、車牌、地址、姓名（需要「姓名」「收件人」這類標籤）、生日／日期。
• 身分證字號與卡號等敏感值，畫面上只顯示遮蔽後的預覽，不顯示完整內容；格式符合只代表長得像，不代表真有此人。
• OCR 容易把 0 看成 O、1 看成 l，偵測時會容忍這類字元，並標示「含容易看錯的字元」。

• 引擎給的字元座標在中英混排的行上可能偏移（我們量到最多約 13 像素），所以預設會「貼齊字跡」：在框的附近找深色筆畫，把框修到剛好蓋住，並略為外擴；可取消勾選。
• 貼齊只看局部像素，在背景花、字很擠或有底線的圖上仍可能蓋不全。

• 塗黑是不透明的黑色，直接畫進像素，輸出為新建的 PNG；不含原圖的 EXIF、色彩描述檔與文字註解。
• 含拍攝方向資訊的照片，會先轉正再塗黑；超過像素上限的圖會縮小，並明說縮了多少。
• 新圖是由程式重畫的結果；塗黑處的原內容不在新圖裡。但沒框到的地方當然仍然看得到，請自行確認。

• 12 張合成圖（對話、帳單、轉帳、證件樣式、長截圖、全半形混排、雜訊、小字、傾斜、旋轉照片），共 89 個標準答案個資：偵測到 88 項，預設會塗黑 88 項，其中完全蓋住原筆畫的 88 項。
• 沒偵測到：1 個手機號碼（全形與半形數字混排的圖，OCR 把全形數字重複辨識成兩倍長度，已知問題）。另有 2 個「姓名」在沒有標籤的情境下不會被框（刻意不做，因為無標籤的姓名誤框率太高）。
• 誤框：在含假資料誘餌（發票號碼、客服專線、一般日期）的圖上，誘餌都被標成信心低且預設不勾選；偵測到而不屬於標準答案的有 1 項（證件樣式圖上的日期，信心低、預設不勾）。
• 手機視窗（390×844 觸控）37 項全中；CPU 降速 4× 的小批次 28 項全中。全程沒有非同源請求、沒有內容安全政策違規。
• 耗時：12 張圖辨識約 32 秒（本機沙箱），偵測約 1.3 秒，產生輸出約 1 秒。實際速度依你的裝置而定。

• 沒有標籤的姓名、暱稱、頭像、人臉、簽名、條碼與 QR Code、浮水印、車輛外觀、門牌照片，都不會自動偵測。
• OCR 沒讀到的字，規則就沒機會比對；模糊、傾斜、太小或反光的字最容易漏。
• 對 OCR 認不出的字，驗證步驟也認不出，所以「驗證通過」不代表真的蓋乾淨。
• 驗證時的巧合：塗黑後再辨識，偶爾會因為別處有相同數字而誤報，請看提示指向哪一項。
• 這個功能整理的是圖片上的視覺內容，不處理檔案名稱、系統記錄或其他附屬資訊。