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、执行错误和采集缺失都要保留在分母中，不得通过筛选行把它们变成合格。除成功样本外，还要保存一个可复现的失败样本。交接时应写明：谁可以更改配方，如何恢复先前已批准的版本，以及在验收之前哪些设备输出仍保持禁止。仅凭软件结果，不能证明移动中的实物工件已到达正确的目的地。