 Leo
|
55ed2c86a7
|
feat(t73): PDF 抽取器接上 PDFium-via-wazero——leo 裁定的引擎，實測通過
⭐ 決定性實測：Chrome headless 列印的中文 PDF 完整抽出
「船舶維修合約書／第一條 維修費用為新台幣 350,000 元整／2026 年 8 月 15 日」
——這正是 pdf-extraction-options.md §3 實測「純 Go 套件會整段亂碼」的那種檔，
也是客戶最常丟的（瀏覽器列印）。選 PDFium 的理由至此坐實。
用戶不必裝任何東西（回答 leo「我的用戶可能不會自己裝 Python 環境」）：
pdfium.wasm 由 wazero(純 Go WASM runtime)在本行程跑，embed 進執行檔。
實測 CGO_ENABLED=0 GOOS=windows 交叉編譯一行成功 → PE32+ executable x86-64，
證實「無 CGo」承諾為真，不加重 t72 負擔。
體積實測(有實際呼叫路徑，避開今天記過的 dead-code 陷阱)：
mac 14.53MB / windows 15.15MB(strip 後)
leo 定調「全運作在客戶電腦上，肥一點喘一點也沒事」
設計決定：
- lazy init（sync.Once）——多數資料夾可能一個 PDF 都沒有，不該白付 WASM 啟動的記憶體
- pdfMu 互斥——pool 單 worker，別依賴「scan 是循序」這個假設
- 單頁失敗不放棄整份，但留「（第 N 頁讀取失敗）」痕跡
- 抽不出字 → ErrNoText（掃描件；PDFium 不做 OCR），絕不靜默送空內容
測試 4/4：Chrome PDF 中文正確／無文字回 ErrNoText／壞檔報錯可辨識
（『可能損壞或有密碼保護』）／連續多檔不爆(daemon 長駐會遇到)。
|
2026-07-27 21:07:11 +08:00 |
|
|
Leo
|
66d4fef045
|
feat(t73/t16): 本地轉檔層骨架＋docx 抽取器（leo 定的『收集端 Markitdown』）
leo 07-27 定的形狀：「本地任何檔案都透過一個機制把它轉成模型可讀，再把模型可讀
內容發給它」「能不能讀 PDF 根本不是 Arcrun 的工作」。
convert.go＝調度層(工頭)：認副檔名→派抽取器→統一吐純文字。
加新格式只要在 extractors 註冊一行，不動架構。
convert_docx.go＝第一個抽取器，純標準庫 archive/zip+encoding/xml。
三個設計決定（都有理由，非隨手）：
① ErrNoText 獨立錯誤——掃描件 PDF 抽不出字時絕不能靜默略過（leo 撞過的病），
要能轉成使用者看得懂的訊息；與 ErrUnsupported 分開因為說法不同。
② NFKC 正規化——PDF 抽中文會出康熙部首變體，長得一樣但碼位不同＝用戶搜不到
自己的檔案。廉價保險，對其他來源同樣有效。
③ 只取 word/document.xml——頁首頁尾多是雜訊(頁碼/公司名)，知識萃取不要。
測試 10/10 + 真 Word 檔實測：
textutil 產生的 real.docx → 抽出「船舶維修合約/350,000/2026 年 8 月 15 日」全對
同段落多 run 相連(Word 常把一句話切成多個 w:r)
壞檔(舊版 .doc 改名)報錯且不歸類成 ErrNoText
NFKC 康熙部首摺回正常字
註：全形「，」會被 NFKC 轉半形「,」＝正常行為，對搜尋無害(反而統一)。
下一步：接 PDFium-via-wazero(+10.43MB)。未接進 extract_gemma 主流程。
|
2026-07-27 20:36:02 +08:00 |
|