1. 為什么我要在 Python 3.7 上死磕文檔掃描 OCR先亮明背景。我手頭有一批紙質(zhì)合同和票據(jù)需要電子化歸檔數(shù)量大概在兩千頁上下。找現(xiàn)成的商業(yè)服務當然省事但數(shù)據(jù)要過別人的服務器心里總歸不踏實而且有些票據(jù)格式很偏通用接口識別率并不理想。于是我決定自己搭一套文檔掃描 OCR流水線跑在本地一臺舊筆記本上環(huán)境就鎖定Python 3.7——不是我不想用新版本而是這臺機器上還跑著幾個老項目依賴鎖死在 3.7動不了。這個標題看起來簡單真做起來你會發(fā)現(xiàn)它其實是三件事疊在一起文檔掃描把手機或掃描儀拍的歪斜照片矯正成規(guī)整的文檔圖、OCR把圖里的文字摳出來、以及后處理把摳出來的文字整理成能用的結構化數(shù)據(jù)。很多人一上來就pip install一個 OCR 庫然后image_to_string結果發(fā)現(xiàn)識別出來的東西錯得離譜就下結論說開源 OCR 不行。問題往往不在 OCR 引擎本身而在前面那一步——你喂給它的圖質(zhì)量太差了。這篇文章適合誰看如果你手頭有紙質(zhì)文檔要批量電子化又不想把數(shù)據(jù)傳出去或者你正在做一個票據(jù)識別、證件識別、表單錄入的小工具再或者你只是好奇掃描全能王那類 App 背后的原理——那這篇內(nèi)容應該能幫到你。我會把整條流水線拆開講包括每一步為什么這么做、參數(shù)怎么定、以及我在兩千頁實測里踩過的那些坑。全程基于 Python 3.7代碼可以直接抄。需要提前說明的是下面涉及的具體閾值、核大小這些參數(shù)都是我在自己那批文檔上試出來的經(jīng)驗值你的場景比如文檔底色、字體、拍攝角度不同需要微調(diào)。我會把調(diào)整的思路也講清楚而不是只丟一堆數(shù)字給你。2. 整條流水線的骨架先想清楚數(shù)據(jù)怎么流2.1 從一張歪照片到一行可用文字中間到底發(fā)生了什么在動手寫代碼之前我習慣先把數(shù)據(jù)流畫在紙上。文檔掃描 OCR 這條鏈路我最終定下來是五個階段圖像預處理灰度化、去噪、二值化把彩色照片變成干凈的黑白圖。邊緣檢測與透視矯正找到文檔的四個角把歪斜的四邊形拉平成正矩形。版面分析區(qū)分文字區(qū)域、表格區(qū)域、圖片區(qū)域決定 OCR 的調(diào)用順序。文字識別調(diào)用 OCR 引擎逐區(qū)域識別。后處理與結構化糾錯、合并、按業(yè)務規(guī)則輸出 JSON 或 CSV。這個順序不是拍腦袋定的。早期我圖省事跳過第 2 步直接識別結果一張傾斜 15 度的 A4 紙識別率直接從 95% 掉到 60% 出頭。原因很簡單主流 OCR 引擎不管是 Tesseract 還是 PaddleOCR在訓練時用的都是水平文本行你給它一個斜的它的行分割算法就崩了。所以透視矯正是整條鏈路里性價比最高的一步花十分鐘寫代碼能省下后面幾小時的糾錯。2.2 Python 3.7 環(huán)境下庫的選型與版本坑Python 3.7 是個分水嶺版本很多庫的新版本已經(jīng)不支持它了。我在選型時踩的第一個坑就是直接pip install opencv-python裝到了最新版結果 import 時報undefined symbol因為新版 OpenCV 編譯時用的 C 標準在舊系統(tǒng)上不兼容。最終我鎖定的版本組合是這樣的庫版本用途備注opencv-python4.5.5.64圖像預處理、透視變換4.6 開始對 3.7 支持變差numpy1.21.6矩陣運算1.22 要求 Python 3.8pytesseract0.3.10Tesseract 的 Python 封裝需另裝 Tesseract 引擎Pillow9.5.0圖像讀寫、格式轉換10.x 不再支持 3.7paddleocr2.6.1.3中文識別備選安裝包較大按需提示裝 OpenCV 時如果遇到編譯問題優(yōu)先用pip install opencv-python4.5.5.64指定版本別用--upgrade。我在這上面浪費了整整一個下午。選 Tesseract 還是 PaddleOCR我的經(jīng)驗是純英文、印刷體、版面規(guī)整的文檔Tesseract 足夠而且輕量中文、混排、有表格的PaddleOCR 的中文模型明顯更強。我最后是兩個都裝了按文檔類型分流——英文合同走 Tesseract中文票據(jù)走 PaddleOCR。這個分流策略后面會詳細講。3. 圖像預處理90% 的識別錯誤都出在這一步3.1 灰度化與自適應二值化為什么不能用全局閾值拿到一張手機拍的文檔照片第一步是灰度化。這個沒什么好說的cv2.cvtColor(img, cv2.COLOR_BGR2GRAY)一行搞定。真正有講究的是二值化。新手最容易犯的錯是用全局閾值比如cv2.threshold(gray, 127, 255, cv2.THRESH_BINARY)。為什么不行因為手機拍照必然有光照不均——左上角亮、右下角暗是常態(tài)。你用一個固定閾值 127亮的地方文字全糊成一片白暗的地方背景全變成黑。我實測過同一張圖全局閾值下識別率 72%換成自適應閾值后直接到 91%。自適應閾值的核心思想是每個像素的閾值由它周圍一小塊區(qū)域的統(tǒng)計量決定而不是全圖統(tǒng)一。代碼長這樣import cv2 import numpy as np def preprocess_image(image_path): img cv2.imread(image_path) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 自適應閾值blockSize 必須是奇數(shù)C 是常數(shù)修正項 binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, blockSize31, C10 ) return binaryblockSize31和C10這兩個值怎么來的blockSize是計算閾值時考慮的鄰域大小太小比如 11會把文字筆畫本身也算進去導致筆畫中間被掏空太大比如 101就退化成全局閾值了。31 是我在 300 DPI 掃描件上試出來的平衡點。C是從計算出的均值里減去的常數(shù)用來抑制噪點10 是個比較穩(wěn)的起點噪點多就往上加。3.2 去噪與形態(tài)學操作別把文字也一起抹掉了二值化之后圖上通常還有一堆椒鹽噪點小黑點小白點。這時候很多人會直接上高斯模糊結果文字邊緣也糊了。我的做法是先中值濾波去椒鹽再用形態(tài)學開運算去掉細小的孤立噪點# 中值濾波核大小 3 對文字損傷最小 denoised cv2.medianBlur(binary, 3) # 開運算先腐蝕后膨脹去掉小噪點但保留文字主體 kernel np.ones((2, 2), np.uint8) opened cv2.morphologyEx(denoised, cv2.MORPH_OPEN, kernel)這里有個反直覺的點形態(tài)學操作的核不能太大。我一開始用了 3x3 的核結果細體字的筆畫比如一、十直接被腐蝕沒了。后來改成 2x2效果好很多。如果你處理的文檔字體特別細甚至可以考慮跳過開運算只做中值濾波。還有一個坑去噪和銳化是矛盾的。去噪越狠文字邊緣越鈍OCR 越容易把0認成O、把1認成l。我的經(jīng)驗是寧可保留一點噪點也不要過度平滑。判斷標準很簡單——把處理后的圖放大看文字邊緣如果筆畫還是清晰的黑色實心就對了如果邊緣發(fā)灰、發(fā)虛就是處理過頭了。3.3 實測對比不同預處理組合對識別率的影響為了讓你有個直觀感受我拿同一張中文票據(jù)做了組對比實驗識別引擎統(tǒng)一用 PaddleOCR結果如下預處理方案識別準確率耗時(ms)原圖直接識別58%420僅灰度化67%380灰度全局二值化72%390灰度自適應二值化89%410灰度自適應中值濾波91%430灰度自適應中值開運算90%445可以看到自適應二值化是那個質(zhì)變點從 72% 跳到 89%。后面的濾波和形態(tài)學只是錦上添花甚至開運算因為損傷了細筆畫反而掉了 1 個百分點。所以如果你時間有限優(yōu)先把自適應二值化調(diào)好其他可以慢慢來。4. 透視矯正把歪的文檔拉正的核心算法4.1 怎么找到文檔的四個角透視矯正的前提是找到文檔在照片里的四個頂點。主流做法是邊緣檢測 輪廓查找 多邊形逼近。思路是文檔通常是一塊面積最大的、近似四邊形的亮色區(qū)域。def find_document_corners(binary_img): # 邊緣檢測 edges cv2.Canny(binary_img, 50, 150) # 膨脹一下讓斷開的邊緣連起來 edges cv2.dilate(edges, np.ones((3, 3), np.uint8), iterations1) # 找輪廓 contours, _ cv2.findContours( edges, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE ) # 按面積排序取最大的幾個 contours sorted(contours, keycv2.contourArea, reverseTrue)[:5] for c in contours: # 多邊形逼近epsilon 是精度參數(shù) peri cv2.arcLength(c, True) approx cv2.approxPolyDP(c, 0.02 * peri, True) # 如果逼近出 4 個點就認為是文檔 if len(approx) 4: return approx.reshape(4, 2) return NoneapproxPolyDP的epsilon參數(shù)這里是0.02 * peri是關鍵。它控制逼近精度太小四邊形會被逼近成很多個點太大四邊形會被簡化成三角形。0.02 倍周長是個經(jīng)驗值對大多數(shù)文檔都適用。如果你的文檔邊緣有破損或卷曲可以適當放大到 0.03。4.2 四個點的排序邏輯以及為什么順序錯了圖就廢了找到四個點之后必須按固定順序排列通常是左上、右上、右下、左下否則透視變換會把圖扭成麻花。排序邏輯我用的是坐標和差法def order_points(pts): rect np.zeros((4, 2), dtypefloat32) s pts.sum(axis1) diff np.diff(pts, axis1) # 左上角xy 最小 rect[0] pts[np.argmin(s)] # 右下角xy 最大 rect[2] pts[np.argmax(s)] # 右上角x-y 最小diff 是 y-x取最小 rect[1] pts[np.argmin(diff)] # 左下角x-y 最大 rect[3] pts[np.argmax(diff)] return rect這個方法的原理很直觀在圖像坐標系里原點在左上左上角的 xy 一定最小右下角一定最大而右上角的 x 大 y 小所以 x-y 最大注意np.diff算的是 y-x所以取最小。我見過有人用最左的點是左上這種邏輯遇到文檔旋轉超過 45 度就全亂了。坐標和差法對任意旋轉都穩(wěn)。4.3 透視變換的矩陣計算與輸出尺寸確定有了排好序的四個點就可以算變換矩陣了。這里有個細節(jié)輸出圖的寬高要根據(jù)四邊形的實際邊長算不能寫死否則文檔會被拉伸變形。def four_point_transform(image, pts): rect order_points(pts) (tl, tr, br, bl) rect # 計算輸出寬度上下邊取最大值 widthA np.linalg.norm(br - bl) widthB np.linalg.norm(tr - tl) maxWidth max(int(widthA), int(widthB)) # 計算輸出高度左右邊取最大值 heightA np.linalg.norm(tr - br) heightB np.linalg.norm(tl - bl) maxHeight max(int(heightA), int(heightB)) # 目標點 dst np.array([ [0, 0], [maxWidth - 1, 0], [maxWidth - 1, maxHeight - 1], [0, maxHeight - 1] ], dtypefloat32) M cv2.getPerspectiveTransform(rect, dst) warped cv2.warpPerspective(image, M, (maxWidth, maxHeight)) return warped為什么寬高要取上下邊、左右邊的最大值因為拍照時文檔會有透視形變上邊和下邊長度不一樣。如果取最小值文檔內(nèi)容會被裁掉取最大值最多是邊緣多留一點白不會丟內(nèi)容。這個取舍原則在圖像處理里很常見——寧可多留不可少留。實測下來透視矯正這一步對傾斜文檔的識別率提升是決定性的。我做過測試一張傾斜 20 度的文檔不矯正識別率 61%矯正后 93%。而且矯正后的圖看起來正了后續(xù)的版面分析也好做很多。5. OCR 引擎的調(diào)用策略與參數(shù)調(diào)優(yōu)5.1 Tesseract 的頁面分割模式PSM選錯等于白干Tesseract 有一個極其重要但經(jīng)常被忽略的參數(shù)--psmPage Segmentation Mode。它告訴引擎這張圖是什么版面結構選錯了識別結果天差地別。常用的幾種模式PSM 值含義適用場景3全自動分割默認規(guī)整的整頁文檔4假設是一列可變大小的文本單列排版6假設是一個統(tǒng)一的文本塊裁剪好的單段文字7把圖當成單行文本單行、標題11稀疏文本盡量找文字票據(jù)、表單這種零散文字我的經(jīng)驗是整頁合同用 3裁剪后的段落用 6票據(jù)這種文字零散的用 11。有一次我處理一批發(fā)票用默認的 3識別率慘不忍睹換成 11 之后直接起飛。原因是發(fā)票上文字分散、有大片空白PSM 3 的分割算法會被空白區(qū)域帶偏。調(diào)用代碼import pytesseract def ocr_with_tesseract(image, langeng, psm3): config f--psm {psm} --oem 3 text pytesseract.image_to_string( image, langlang, configconfig ) return text--oem 3是 OCR 引擎模式3 表示默認LSTM 傳統(tǒng)引擎混合一般不用改。lang參數(shù)要注意中文是chi_sim中英混排是chi_simeng但混排會慢不少按需選。5.2 PaddleOCR 的中文優(yōu)勢與初始化開銷PaddleOCR 在中文場景下確實強尤其是對印刷體中文的識別準確率比 Tesseract 高一個檔次。但它有個明顯的缺點初始化慢。第一次調(diào)用要加載模型大概 3-5 秒。如果你要處理幾千張圖這個開銷可以忽略但如果只是偶爾識別一張體驗就很差。我的做法是把 PaddleOCR 實例做成全局單例程序啟動時初始化一次后續(xù)復用from paddleocr import PaddleOCR _ocr_engine None def get_ocr_engine(): global _ocr_engine if _ocr_engine is None: _ocr_engine PaddleOCR( use_angle_clsTrue, # 自動糾正文字方向 langch, show_logFalse ) return _ocr_engine def ocr_with_paddle(image): engine get_ocr_engine() result engine.ocr(image, clsTrue) # result 是嵌套列表逐層拆出文字和置信度 lines [] for line in result[0]: text line[1][0] confidence line[1][1] if confidence 0.6: # 置信度過濾 lines.append(text) return \n.join(lines)use_angle_clsTrue這個參數(shù)建議開著它會自動判斷文字是不是倒的、旋轉的對手機拍的文檔很有用。confidence 0.6這個過濾閾值是我試出來的——低于 0.6 的識別結果基本都是錯的與其留著添亂不如直接丟掉后面用業(yè)務規(guī)則補。5.3 雙引擎分流什么文檔走哪條路前面提到我最后是 Tesseract 和 PaddleOCR 雙引擎。分流規(guī)則很簡單但很實用純英文、印刷清晰、版面規(guī)整→ Tesseract快且準。含中文、中英混排、有表格→ PaddleOCR。票據(jù)、發(fā)票、表單→ PaddleOCR PSM 11 的思路PaddleOCR 沒有 PSM但它的檢測模型本身對稀疏文本友好。怎么自動判斷走哪條我的做法是先跑一個輕量的語言檢測——用 Tesseract 的eng模式快速識別一遍如果識別出的字符里非 ASCII 占比超過 30%就判定為中文文檔轉 PaddleOCR 重跑。這個先探路再決定的策略比無腦上重引擎要省資源。6. 版面分析與后處理讓結果真正能用6.1 按行聚類把零散的文字塊拼回段落OCR 引擎返回的往往是零散的文字塊位置信息是有的但順序可能是亂的。尤其是 PaddleOCR它返回的是檢測框坐標加文字你需要自己按位置排序。我的做法是按 y 坐標聚類成行再按 x 坐標排序def sort_ocr_results(results, y_threshold10): # results: [(box, (text, conf)), ...] items [] for box, (text, conf) in results: # box 是四個點的坐標取左上角 x min(p[0] for p in box) y min(p[1] for p in box) items.append((x, y, text, conf)) # 先按 y 排序 items.sort(keylambda t: t[1]) # 再把 y 相近的歸為同一行 lines [] current_line [] last_y None for item in items: if last_y is None or abs(item[1] - last_y) y_threshold: current_line.append(item) else: current_line.sort(keylambda t: t[0]) lines.append(current_line) current_line [item] last_y item[1] if current_line: current_line.sort(keylambda t: t[0]) lines.append(current_line) # 拼成文本 return \n.join( .join(t[2] for t in line) for line in lines)y_threshold10是判斷兩個文字塊是否在同一行的像素閾值。這個值要跟你的圖像分辨率匹配——300 DPI 的掃描件行高大概 40-50 像素閾值設 10-15 比較合適如果是低分辨率圖要相應調(diào)小。設太大相鄰兩行會被合并設太小同一行會被拆開。6.2 常見 OCR 錯誤的糾正規(guī)則OCR 出來的文字尤其是數(shù)字和英文有幾類高頻錯誤。我整理了一份糾錯規(guī)則用正則批量處理錯誤類型典型表現(xiàn)糾正規(guī)則數(shù)字 0 與字母 O1O0 應為 100數(shù)字上下文中 O→0數(shù)字 1 與字母 l/Il23 應為 123數(shù)字上下文中 l/I→1數(shù)字 5 與字母 SS00 應為 500數(shù)字上下文中 S→5數(shù)字 8 與字母 BB8 歧義結合上下文判斷小數(shù)點丟失1234 應為 12.34金額字段按規(guī)則補import re def correct_ocr_text(text): # 在純數(shù)字串里把常見字母替換成數(shù)字 def fix_numeric(m): s m.group(0) trans str.maketrans(OolISs, 001155) return s.translate(trans) # 匹配長度3的、由數(shù)字和易混字母組成的串 text re.sub(r[0-9OolISs]{3,}, fix_numeric, text) return text這個規(guī)則要小心用。比如英文單詞 SO 會被誤傷成 50。所以我的做法是只在特定字段上應用——比如金額、日期、編號這些明確是數(shù)字的字段才跑數(shù)字糾錯正文段落不跑。這個分字段處理的思路比全局糾錯安全得多。6.3 輸出結構化數(shù)據(jù)JSON 還是 CSV最后一步是輸出。我的建議是中間結果存 JSON最終交付看用途。JSON 能保留層級和字段名方便后續(xù)程序處理CSV 適合直接給業(yè)務人員看。import json def build_structured_result(lines, doc_typecontract): result { doc_type: doc_type, raw_text: \n.join(lines), fields: {} } # 按文檔類型提取關鍵字段 if doc_type contract: for line in lines: if 甲方 in line: result[fields][party_a] line.split()[-1].strip() elif 乙方 in line: result[fields][party_b] line.split()[-1].strip() return result字段提取這塊簡單場景用關鍵詞匹配就夠了復雜場景比如表格就得上專門的表格識別模型或者用坐標做單元格切分。我處理的那批合同字段比較固定關鍵詞匹配加正則就搞定了沒必要上重型方案。能用簡單方法解決的別過度設計這是我踩了很多坑之后的體會。7. 兩千頁實測那些文檔里不會寫的坑7.1 內(nèi)存泄漏PaddleOCR 連續(xù)調(diào)用會漲內(nèi)存這個坑我踩得最慘。批量處理到第 800 多張的時候程序突然被系統(tǒng) kill 了。查了半天發(fā)現(xiàn)是 PaddleOCR 在連續(xù)調(diào)用時內(nèi)存緩慢上漲每張圖漲幾 MB累積下來就爆了。解決辦法有兩個一是分批處理每處理 200 張就重啟一次引擎二是顯式釋放中間變量。我最后用的是分批加重啟def batch_process(image_paths, batch_size200): results [] for i in range(0, len(image_paths), batch_size): batch image_paths[i:ibatch_size] engine get_ocr_engine() for path in batch: results.append(process_single(path, engine)) # 處理完一批釋放引擎 global _ocr_engine _ocr_engine None import gc gc.collect() return results重啟引擎有 3-5 秒開銷但相比程序崩潰重跑這點代價完全值得。如果你用的是 Tesseract它每次調(diào)用都是獨立進程反而沒這個問題。7.2 圖像方向EXIF 信息導致的躺平文檔手機拍的照片很多帶 EXIF 方向信息。用 OpenCV 讀進來的時候它不讀 EXIF所以一張豎著拍的照片讀進來可能是橫的。我第一次處理時就遇到這個一批圖全是躺著的OCR 識別率極低。解決方法是讀圖時用 Pillow 處理 EXIF再轉給 OpenCVfrom PIL import Image, ImageOps import numpy as np def read_image_with_exif(path): img Image.open(path) img ImageOps.exif_transpose(img) # 根據(jù) EXIF 自動旋轉 return cv2.cvtColor(np.array(img), cv2.COLOR_RGB2BGR)ImageOps.exif_transpose會自動根據(jù) EXIF 里的方向標記旋轉圖像。這一行代碼解決了我 90% 的文檔躺平問題。剩下的 10% 是 EXIF 信息丟失的只能靠 OCR 引擎的use_angle_cls兜底。7.3 處理速度優(yōu)化從每張 3 秒到每張 0.8 秒兩千頁如果每張 3 秒就是 100 分鐘。我優(yōu)化到了每張 0.8 秒總耗時降到 27 分鐘。幾個關鍵優(yōu)化點圖像降采樣如果原圖是 4000x3000先縮到 2000x1500 再處理。OCR 對分辨率的需求沒那么高2000 寬足夠速度卻能快一倍多。預處理用 OpenCV 的原地操作很多cv2函數(shù)支持dst參數(shù)可以避免創(chuàng)建新數(shù)組。多進程Python 的 GIL 讓多線程在 CPU 密集任務上沒用但多進程有效。我用multiprocessing.Pool開了 4 個進程速度提升接近 3 倍。from multiprocessing import Pool def process_wrapper(args): path, doc_type args return process_single(path, doc_type) if __name__ __main__: tasks [(p, contract) for p in image_paths] with Pool(processes4) as pool: results pool.map(process_wrapper, tasks)注意多進程下每個進程會各自初始化一份 OCR 引擎內(nèi)存占用會翻倍。如果你的機器內(nèi)存緊張進程數(shù)要相應減少。我那臺舊筆記本 8G 內(nèi)存開 4 個進程剛好開 6 個就開始 swap 了。7.4 識別質(zhì)量的最后一公里人工抽檢策略再好的 OCR 也不可能 100% 準確。我的做法是按置信度分層抽檢置信度高于 0.9 的抽 5% 人工核對0.7-0.9 的抽 30%低于 0.7 的全部人工核對。這樣既保證了質(zhì)量又不會讓人工成本失控。具體實現(xiàn)就是在輸出結果里帶上置信度然后按閾值分流def split_by_confidence(results, high0.9, mid0.7): high_conf, mid_conf, low_conf [], [], [] for r in results: if r[confidence] high: high_conf.append(r) elif r[confidence] mid: mid_conf.append(r) else: low_conf.append(r) return high_conf, mid_conf, low_conf這套策略跑下來我那兩千頁文檔最終的錯誤率控制在 0.5% 以內(nèi)人工核對只花了大概 3 小時。如果全部人工核對至少得 20 小時。把人力用在刀刃上這是批量 OCR 項目里最值錢的經(jīng)驗。8. 寫在最后的一點個人體會這套流水線我前后迭代了大概三周從最初能識別就行到后來識別率 95% 以上中間踩的坑基本都寫在上面的章節(jié)里了。如果讓我給正在做類似項目的朋友一句建議那就是別急著調(diào) OCR 引擎的參數(shù)先把圖像預處理和透視矯正做扎實。我見過太多人把時間花在換引擎、調(diào)模型上結果喂進去的圖還是歪的、糊的怎么調(diào)都沒用。另外Python 3.7 雖然老但生態(tài)其實夠用關鍵是鎖死版本別讓pip自作主張升級。我現(xiàn)在的做法是每個項目都配一個requirements.txt把版本號寫死換機器時pip install -r requirements.txt一把梭省心。最后分享一個小技巧如果你處理的文檔類型比較固定比如都是同一種發(fā)票可以把第一張識別正確的圖存下來當模板后續(xù)的圖先跟模板做配準再按模板的坐標去切字段。這樣字段提取的準確率能再上一個臺階比純靠關鍵詞匹配穩(wěn)得多。這個思路我在處理一批格式統(tǒng)一的票據(jù)時用過效果很好值得一試。