增强Luhn算法的实现？

Posted 2023-02-22

【中文标题】增强Luhn算法的实现？

【英文标题】：Implementation of enhanced Luhn algorithm?

【发布时间】：2017-08-20 12:58:02

【问题描述】：

有人知道用于检查支付卡上模数为 10 的“双加双”校验位的增强型或增强型 Luhn 公式的任何实现吗？

本文提出了增强建议：http://d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf

增强的 Luhn 检查是否有实际用途？

【问题讨论】：

不，不是。除了琐碎之外，验证 PAN 的唯一方法是将其发送给收单方以尝试授权 - 同样验证电话号码的唯一方法是拨打电话号码。我看不出那篇论文的重点或其中包含的任何有效提案，假设平底锅的长度是固定的 16 位数字一开始是完全错误的。

【参考方案1】：

这篇论文被同行评审期刊接受有点奇怪。该论文描述了 1970 年代 Fletcher 校验和存在的问题。它的长度和数据转置无法准确检测。

但让我们考虑一下这个提议的实际方面。如果真的深挖细节，确实是不可行的，原因很多。

Luhn 算法是一种简单、尽力而为的方法来验证卡号。早在信用卡开始以电子方式进行广泛处理时（它们以前是用纸质印记完成的），还没有永远在线的网络来调用服务进行验证。 Luhn 可以在不需要网络连接来执行验证的情况下实现。这是确定不可行性的第一个前提：您必须能够执行验证而无需遍历网络。

这种“无网络遍历”的前提使得 MII 查找不可行。有两种实现方式：

执行 MII 查找的 Web 服务。这意味着在网络调用处理付款之前，每个数据输入都需要一个网络调用来验证卡号。验证调用可能会花费与事务处理一样长或更长的时间。在验证的情况下，它必须是同步的——用户需要等待结果才能继续订购。如果由于某种原因无法完成通话，客户可能会在其他地方订购。

处理卡授权可以是异步的。亚马逊这样做；他们确认收到您的订单，并且通常会在稍后确认付款处理。

将 MII 数据库定期分发到所有设备。每一个手机APP、支付终端、网站、ERP等等都会不断的增加新的MII和删除旧的MII。其中许多可能会在一段时间内过时，导致某些商户的交易被拒绝，但在使用同一张卡时，其他商户的交易却被批准。消费者会不信任使用这些卡。

最后，作者对卡片的长度做出了错误的假设。 Luhn 算法适用于许多长度，因为卡号长度可以长于或短于 16 位数字。美国运通的消费卡是 15 位数字，其他卡是 16 位。商务卡长度可超过16位；我见过最多 20 位数的商用空气燃料卡。如果作者查看了 IEC/ISO 7812 标准，就会理解这一点。标准委员会甚至提议延长标准卡号的长度。很棒的是，当/如果卡号长度延长时，Luhn 算法仍然会验证卡。

帮自己一个忙，将 Luhn 作为您的第一步，然后让处理器通过现有的卡处理网络验证卡无疑是正确的，从而为您完成繁重的工作。

【参考方案2】：

我进行了 Google 搜索，并在软件开发人员 Pawel Decowski 的 Luhn 检查中发现了与 Hussein 等人提出的相同两项增强功能的软件实现。这是他的 jQuery 信用卡验证器（Decowski，2015/2016）。我推测 Decowski 受到了 Hussein 等人的影响。

Decowski, P. (2015/2016) jquery-creditcardvalidator [在线]。可在https://github.com/PawelDecowski/jquery-creditcardvalidator 获取（2017 年 4 月 11 日访问）。