增强Luhn算法的实现？

Question

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

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

增强的Luhn检查会有实际用途吗？

Answer 1

有点奇怪的是，这篇论文被同行评议的期刊接受了。这篇论文描述了20世纪70年代Fletcher校验和本质上被识别的问题；它的长度和数据转置不能被准确检测。

但让我们考虑一下这个提案的实际方面。如果你真的深入研究细节，由于许多原因，实现它确实是不可行的。

Luhn算法是一种简单的、尽最大努力验证卡号的方法。回到信用卡开始被广泛电子化处理的时候(它们以前是用纸质印记完成的)，没有始终在线的网络来调用验证服务。可以在不需要网络连接来执行验证的情况下实现Luhn。这是确定不可行性的第一个前提:您必须能够在不需要遍历网络的情况下执行验证。

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

1. 执行MII查找的web服务。这意味着每个数据输入都需要一个网络调用来验证卡号，然后再进行网络调用来处理支付。验证调用的时间有可能与事务处理的时间一样长或更长。在验证的情况下，它必须是同步的-用户需要等待结果，然后才能继续订单。如果由于某种原因无法完成呼叫，客户可能会直接在其他地方订购。

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

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

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

帮你自己一个忙，依靠Luhn作为你的第一步，然后让处理器通过现有的卡处理网络验证卡的无可否认的正确性，为你做繁重的工作。

Answer 2

我在谷歌上搜索了一下，在软件开发人员Pawel Decowski的Luhn检查中，我发现了一个在软件中实现了侯赛因等人提出的相同的两个增强功能。这是他的jQuery信用卡验证器，(德科夫斯基，2015/2016)。我推测Decowski受到了侯赛因等人的影响。

Decowski，P. (2015/2016) jquery-在线验证器。可在https://github.com/PawelDecowski/jquery-creditcardvalidator上获得(2017年4月11日访问)。