增强型Luhn算法的实现？

有没有人知道增强或增强Luhn公式的任何实现用于检查支付卡上的模数-10“双加双”校验位数？ http://d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf 增强型Luhn算法的实现？

会增强卢恩检查的实际用途：

增强在该文件建议？

来源

2017-03-27 Simon Towler

不，不是真的。验证PAN的唯一方法就是将其发送给收单机构进行授权 - 同样，验证电话号码的唯一方法就是调用它。我没有看到该论文或其中包含的任何有效提案的要点，假设一个平底锅的长度是一个固定的16位数是开始的错误。 –

这篇论文被同行评审的期刊接受，这有点奇怪。该论文描述了1970年代基本上被认定为弗莱彻校验和的问题;它的长度和数据转换无法准确检测。

但让我们来思考此提案的实际方面。如果你真的深入细节，实施起来有很多原因是不可行的。

Luhn算法是作为一个简单的，尽力而为的方法来验证卡号。当信用卡开始以电子方式进行广泛处理时（之前他们已经完成了纸质印记），因此没有永远在线的网络来呼叫服务进行验证。 Luhn可以在不需要网络连接的情况下执行验证。这是建立不可行性的第一个前提：您必须能够执行验证而不需要遍历网络。

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

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

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

的MII数据库的周期分布到所有设备。每个手机应用程序，支付终端，网站，ERP等都将不断需要添加新的MII并删除旧的MII。他们中的很多人可能会过时一段时间，导致某些商家拒绝交易，但在使用同一张卡时为其他人批准交易。消费者会不相信使用这些卡。

最后，笔者对于该卡的长度一个错误的假设。 Luhn算法适用于很多长度，因为卡号长度可以长于或短于16位。美国运通卡的消费者卡是15位数，其他卡是16位。商业卡可以超过16位数字;我已经看到了20位数的商业空气加油卡。如果作者研究了IEC/ISO 7812标准，这将会被理解。标准委员会甚至建议延长标准卡号的长度。最重要的是，当卡号长度延长时，Luhn算法仍然会验证卡片。

帮自己一个忙，依靠卢恩作为第一步，但然后让处理器为你做繁重的任务通过验证该卡是通过现有的卡处理网络不可否认的是正确的。

来源

2017-04-22 12:18:49 Nathan

我做了一个Google搜索，发现软件实现了一个由Hussein等人在软件开发人员Pawel Decowski的Luhn检查中提出的相同的两个增强。这是他的jQuery信用卡验证器（Decowski，2015/2016）。我会推测Decowski受到侯赛因等人的影响。

Decowski，P.（2015/2016）jquery-creditcardvalidator [Online]。可在https://github.com/PawelDecowski/jquery-creditcardvalidator（2017年4月11日查阅）。

来源

2017-06-19 10:38:50

增强型Luhn算法的实现？

回答

相关问题