EAN-13 追溯：解碼與資料規則

目的與適用邊界

把符號解碼、校驗位驗證和商品主資料關聯分開處理，避免能夠讀出的條碼悄悄地指向錯誤的貿易項目。

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

準備佐證

凍結所支援的碼制、預期的商品來源版本和讀取失敗（no-read）策略。預期識別碼不要作為解碼器的輸入，並單獨標明所有對模型的依賴。在解讀最終旗標之前，先對照介面約定檢查中間輸出。缺失的區域、格式錯誤的文字欄位、無效的座標或非有限的數值，都必須保持為明確的失敗，而不能當作預設的良好結果。記錄該次執行實際使用的執行後端和依賴項；不要把使用同名範本的另一個後端的驗收結論轉用過來。如果選用了新的模型或前處理版本，要保留之前的版本，並重新執行固定的對比，而不是把不同版本識別碼下的結果混在一起。要給出嘗試的案例總數、其中有多少回傳了可用佐證，以及對其餘案例所作的處理決定。這些數量既反映辨識品質，也反映涵蓋率和失敗處理情況。解碼、識別碼驗證、印刷品質驗證和單件追蹤應分別記錄。EAN-13 值所識別的是一種貿易項目，通常由多個實物單件共用；它既不是逐影格序號，也不是唯一序列號。解碼成功，並不能證明印刷品質合規、商品主資料正確，也不能證明後段剔除成功。本系列以 EAN-13 作為限定範圍的範例，因為這是已確認的公開 PC 評估範圍。其他碼制、QR 碼、直接零件標記和讀碼器硬體，都需要各自經確認的整合。原始來源影像必須保留條、空和靜區；僅有裁剪後的顯示圖或清理過的二值圖，不足以作為失敗佐證。要在追溯資料庫中明確規定缺失的影格與無法讀取的條碼有何區別。把工作流程看作一連串有類型的判定，而不是單個模型給出的一個答案。執行實驗之前，先綁定輸入識別碼、區域變換、節點版本、前處理和模型套件。在開發影像上選取參數，與在凍結評估集上評估要分開進行，該評估集的答案不得用於調參。每個案例的基線結果和候選結果都要保留，包括執行失敗的情況。AI 的建議可以提出修訂方案，但不能確認參考答案，不能授予資料上傳權限，也不能批准投入生產使用。如果對服務供應商的呼叫無法確定是否已被接收，要保留請求識別碼，並先查清接收情況，再考慮是否重發。執行環境是否可用、辨識品質和發布審批，是相互獨立的檢查。

步驟

1. 對原始 ROI 進行解碼，並在驗證之前保留原始解碼內容、碼制和來源 ID。
2. 檢查宣告的長度和校驗位，不要依據預期答案去修正不一致的數字。
3. 查詢已批准的商品對映，並區分「識別碼未知」和「與已知商品不符」。
4. 為讀取成功、no-read、無效資料、不吻合和執行錯誤回傳結構化結果；在任何 PLC 輸出之前先測試這些情形。

解讀試驗結果

對於假設的前幾位數字 123456789012，交替位求和分別為 26 和 22。加權和為 26 + 3 × 22 = 92，校驗位為 8，得到 1234567890128。這只是算術演示用的固定資料，不是已分配給客戶的 GTIN。校驗位正確，並不能證明該識別碼屬於預期的商品。

紀錄表

W = 26 + 3 * 22 = 92
c = (10 - (92 % 10)) % 10 = 8

兩個工程視角

故障排除

• 對校驗和進行「修復」，可能把一張真正貼錯的標籤變成一次誤比對。
• 解碼器的回應如果沒有宣告碼制或來源識別碼，就屬於不完整的佐證，即使其文字看起來合理。

驗收與交接

每條規則都要用獨立的影像和已批准的參考紀錄來驗收。解碼成功、校驗和有效和商品關聯應作為各自獨立的驗收欄位；其中任何一項單獨都不能證明 GS1 印刷品質驗證通過。

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