EAN-13 追溯：重複與漏讀

目的與適用邊界

判斷重複出現的解碼內容，究竟是同一單件被重複取像，還是確實存在內容相同的產品，同時不遺漏任何一次讀取失敗（no-read）事件。

本教學給出的是一套工程評估方法，而不是開箱即用的產品認證。Deyi Vision 目前公開的 PC 範例，涵蓋在已確認的樣本影像上執行的 EAN-13 流程。工程程式碼中涉及原生 OCR 與檢測的部分，使用前必須對照已安裝的執行環境、已綁定的模型和作業逐項核對。瀏覽器範本並不能證明已在瀏覽器中實際執行：規劃中的 OpenCV.js 後端需要單獨驗證。雲端辨識必須事先明確批准影像範圍、服務供應商、模型和費用。審查存檔不是可執行的發行套件。相機、韌體和驅動程式的相容性需要各自單獨核查。下列範例表中的所有數值均為假設資料，不是 Deyi Vision 的量測結果，也不是客戶結果。

準備佐證

準備多件連續的、帶有相同貿易項目代碼的單件，以及一份儲存下來的影格回放。獨立於條碼的解碼內容，來定義實物單件事件。寫出的失敗紀錄，要讓另一位工程師無需猜測用的是哪張影像或哪個版本，就能回放。紀錄中包括原始來源、受影響區域、實際輸出、預期處置，以及第一個出現分歧的中間結果。記錄該現象是出現在回放中、即時取像中，還是兩者都有。修正之後，重新執行最初的失敗案例，以及先前成功的相鄰條件。靠排除警報區域，或接受缺失的結果來消除一條警報，這樣的修復改變的是需求，並沒有解決原因。如果失敗仍未解決，應讓受影響的操作保持在 Review 或禁止狀態並寫明原因；不要把未經測試的變通辦法標成已驗證的解決方案。解碼、識別碼驗證、印刷品質驗證和單件追蹤應分別記錄。EAN-13 值所識別的是一種貿易項目，通常由多個實物單件共用；它既不是逐影格序號，也不是唯一序列號。解碼成功，並不能證明印刷品質合規、商品主資料正確，也不能證明後段剔除成功。本系列以 EAN-13 作為限定範圍的範例，因為這是已確認的公開 PC 評估範圍。其他碼制、QR 碼、直接零件標記和讀碼器硬體，都需要各自經確認的整合。原始來源影像必須保留條、空和靜區；僅有裁剪後的顯示圖或清理過的二值圖，不足以作為失敗佐證。要在追溯資料庫中明確規定缺失的影格與無法讀取的條碼有何區別。從最早可觀察到的分歧點開始排查。把同一份儲存的來源影像分別回放給未做改動的基線版本和候選版本，並比較中間影像、區域、數值和結果狀態。如果來源影像本身就不同，這一對比就無法再把演算法單獨隔離出來。每次只改變一個懷疑的原因，執行前先寫下預期效果，假設不成立時也要保留這個否定結果。要把佐證無法讀取、規則不吻合、相依項缺失和執行故障區分開來，它們需要不同的補救辦法。回放可以重現軟體故障，但無法驗證即時觸發、照明時序或實物剔除路徑。這些取像和產線方面的檢查，應作為單獨的後續實驗另行進行。

步驟

1. 在對重複的字串去重之前，先比較取像 ID 和單件事件。
2. 要把 no-read、缺失影格和無效解碼內容區分開；每個事件都要檢查其原圖。
3. 先回放一次儲存的取像，以測試冪等接收，再送入多次內容相同的獨立真實取像。
4. 用事件識別碼檢查重新啟動和佇列順序；絕不能僅因為 EAN-13 文字相同，就把所有單件去重。

解讀試驗結果

在這份假設紀錄中，具有相同 EAN-13 的 4 個不同單件事件，需要 4 條單件紀錄。1 次取像的重複送達只需要 1 條單件紀錄，並保留接收歷史。EAN-13 指代一種貿易項目，其本身並不是唯一的實物單件序列號。

紀錄表

兩個工程視角

故障排除

• 依解碼內容是否唯一來計數，會掩蓋合法存在的重複產品。
• 用前一次讀取成功的結果頂替缺失的影格，會製造出佐證從未建立過的追溯關係。

驗收與交接

當每個應出現的單件各有一條終態紀錄，且回放不會憑空多出一個單件時，可驗收事件核算。要把預期觸發、收到的影像、no-read 和終態紀錄逐項對帳，期間不得刪去失敗的事件。

把來源影像、預期判定、確切版本和完整的結果紀錄放在一起儲存。在選定最終參數之前，先凍結評估集。如果之後用這些答案來調整工作流程，就應把該集合標記為開發資料，並重新取得一個獨立的驗收集。Review、NoResult、執行錯誤和取像缺失都要保留在分母中，不得透過篩選資料列把它們變成合格。除成功樣本外，還要儲存一個可重現的失敗樣本。交接時應寫明：誰可以更改配方，如何恢復先前已批准的版本，以及在驗收之前哪些裝置輸出仍保持禁止。僅憑軟體結果，不能證明移動中的實物工件已到達正確的目的地。