EAN 与 UPC 条码校验位：商品条码怎么算最后一位

超市收银台那一声提示音背后，其实藏着一次很朴素的算术：扫描枪读出的一串数字先被本地算一遍校验位，算不对就直接拒绝。这让绝大多数输错一位的情况在联网之前就被拦下。商品条码的校验设计得早，思路清晰，是理解校验位的好样本。

商品条码的最后一位是怎么来的?

一套商品条码由若干位数字组成，最后一位不参与商品标识，只用于校验。它由前面的位共同决定：把这些位按位加权、求和，对模数取余，再取余数的补数作为校验位。任何一位改动都会改变计算结果，因此这一步能高效地发现单个数字写错。

之所以用取补而不是直接使用余数，是为了让校验位落在十进制数字的取值范围内，同时保持对每一位的敏感性。这类「求和、取模、映射」的骨架在别的体系里也能见到，只是参数不同，参见校验位算法家族。

要留意的边界情况是：当加权和恰好是模数的整数倍时，余数为零，补数会让校验位写成零。这类输入看着特殊，实际完全合法，实现时不要把它当成异常拒绝掉。

两种常见长度的条码与权重安排

商品条码有不止一种长度。最常见的两套标准各自规定了位数，名字里的数字就是位数的来源，它们本身只是标准名称的一部分，不表示别的含义。较短的版本多用于小包装零售商品，较长的版本能容纳更多标识空间。

两套标准的分工主要体现在可用的标识容量上，而不是校验方式上。校验思路一致，参数随长度调整，这个设计让人可以在同一段代码里处理两种输入。

选择哪一套长度通常不是开发者决定的，而由商品在哪个环节流通决定：面向零售终端的包装印的是较短的版本，需要更大标识空间的场景用较长的版本。处理数据时应当两套都接受，并按长度分流后再算校验位，不要在长度还没确定之前就开始加权。

还有一类输入值得单独处理：仅供门店内部使用的自编码。它们外观与标准条码相似，却可能遵循完全不同的分配规则，套用标准算法会得到大量看似失败的结果。遇到这类数据，最稳的做法是先确认来源，再决定要不要校验。

从右往左加权的算法思路

加权的时候，交替权重不是随意安排的。因为位数可能是奇数也可能是偶数，若从左边开始分配权重，同一套标准里不同位置的数字会拿到相反的权重，反而制造混乱。因此常见做法是固定从右往左编号，让权重与「距离末尾第几位」绑定。

这样安排之后有一个直接的好处：校验位自己始终拿到同一类权重，不会因为号码总长度变化而改变角色。实现时若写成从左往右的循环，短号码上的结果就会与标准不符，而且往往只在奇偶长度混用的批量数据里才暴露出来。

另外一个实现细节是，计算校验位时最后一位本来就不参与；如果你把完整的条码整串丢进计算，得到的结论会永远对不上。这个错误很常见，因为完整串才是用户手上真正存在的那个值。

还有一点值得写进注释：末位本来就不参与加权，所以为一段已有标识补算校验位时，输出应当是原串加一位，而不是把末位替换掉。两种操作在批量脚本里混用，会产出长度不一致的结果，下游按固定长度解析时随之全部错位。

条码前缀在说什么、不说什么

条码最前面的一段数字由负责分配的机构按国家或地区划段，用于标识号码的分配范围，也就是这段编号由哪套体系发放。它是体系归属的线索，不是商品信息。

它不代表商品的生产地或制造地。同一种商品可以在不同地方生产而使用同一个条码，因为是品牌方为商品申请了这段标识，生产安排并不改变它。把前缀当作产地信息，是使用条码数据时相当普遍的误解。

前缀也不能用来判断商品是否真实存在。一段前缀只说明它落在某个分配范围内，至于对应的商品是否已经登记、是否仍在销售，条码本身不会回答。

校验通过就能扫出来吗?

不能。校验通过说明这串数字自洽，接下来能不能扫出商品，取决于该条码有没有被登记在对应的商品数据源里、数据源是否覆盖该地区、以及查询是否成功。这几件事都在算术之外。

顺带说明一个容易混淆的点：扫描枪对校验位的处理发生在本地，所以网络断开时它一样能判断数字是否写错，只是查不到商品名称。这也是为什么收银场景中「扫不出来」与「提示错误」是两种不同的反馈。

反过来，如果校验不通过，结论应当是这串数字在录入或印刷环节出了问题，需要复查，而不是断言这个商品不存在。

还有一个容易被忽略的事实：条码里只有数字，没有商品名称与价格。价格由后台数据源决定，同一条码在不同门店也可能对应不同售价，这与校验无关。印刷质量同样不在校验范围内——条码印糊、被折痕截断、贴在曲面上反光，扫描枪都可能读不出来，但它在字符层面完全合法。遇到读不出码的情况，先排查印刷与扫描条件，而不是去重算校验位。

给开发者：批量扫描与错误定位

处理批量条码数据时，先做归一化：去掉扫描或导出时夹带的空白与不可见字符，确认字符集是纯数字，再做长度分流，最后算校验位。顺序颠倒会让错误定位变得困难。

错误报告要落到具体位置。一条记录失败时，至少要回传原始值、规范化后的值、判定为哪一类失败（字符集、长度、校验位），以及它在源文件里的行号。只有「一批里有三条失败」这种粒度的报告，对排查几乎没有帮助。

如果同一份数据里混有书号刊号之类的其他编号，别硬套商品条码的规则。它们的校验位算法属于同一家族但参数不同，混在一起必然误判，可看ISBN 与 ISSN 校验位。批量处理的流水线设计见批量校验工作流。

下一步

把一条可疑的条码粘进号码校验工具，看它是否被判为校验位不成立——这通常意味着印刷或录入环节出了问题，值得回原始数据核对。若你要处理整份商品清单，先把字符集与长度两类错误单独统计出来，再决定要不要逐条核对。

本文只说明公开的校验位思路与条码体系的通用结构，不提供真实条码数据；文中校验结论仅关于字符是否自洽，不代表任何商品已登记、在售或可被扫描出对应信息。