为什么这个有效的USPS跟踪号码不能根据他们的规格进行验证？

Question

我正在写一个宝石来检测跟踪号码(称为tracking_number,natch).它在文本中搜索有效的跟踪号格式,然后通过每个相应服务规范中指定的校验和计算来运行这些格式,以确定有效数字.

有一天,我使用USPS认证邮件邮寄了一封信,从USPS获得了随附的跟踪号码,并将其输入我的宝石,但未通过验证.我相当肯定我正在正确地执行计算,但是已经没有想法了.

使用USS Code 128验证该号码,如以下文档的第2.8节(第15页)中所述:http://www.usps.com/cpim/ftp/pubs/pub109.pdf

我从邮局得到的跟踪号是"7196 9010 7560 0307 7385",我用来计算校验位的代码是:

def valid_checksum?
  # tracking number doesn't have spaces at this point
  chars = self.tracking_number.chars.to_a
  check_digit = chars.pop

  total = 0
  chars.reverse.each_with_index do |c, i|
    x = c.to_i
    x *= 3 if i.even?
    total += x
  end

  check = total % 10
  check = 10 - check unless (check.zero?)
  return true if check == check_digit.to_i
end

根据我提供的规格计算,最后一位数应为3才能生效.但是,Google的跟踪号码自动检测功能可以很好地提取数字,所以我只能假设我做错了什么.

Answer 1

从我的手动计算中,它应该与您的代码所做的相符:

posn: 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2   sum  mult
even:  7     9     9     1     7     6     0     0     7     8    54   162
 odd:     1     6     0     0     5     0     3     7     3       25    25
                                                                       ===
                                                                       187

因此校验位应为三位.

如果该数字有效,那么他们将使用与您认为的算法不同的算法.

我想可能就是这种情况,因为当我将您提供的号码插入USPS跟踪器页面时,我可以看到它的整个路径.

实际上,如果查看出版物91 "确认服务技术指南",您会看到它使用两个额外的数字,包括91跟踪应用程序ID的前面部分.应用中发现的算法是公开给我们:

posn: 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2   sum  mult
even:  9     7     9     9     1     7     6     0     0     7     8    63   189
 odd:     1     1     6     0     0     5     0     3     7     3       26    26
                                                                             ===
                                                                             215

这确实会给你一个5的校验位.我不是说这是答案,但它确实与事实相符,至少是一个可行的解释.

可能你最好的选择是联系USPS获取信息.