有谁知道用于检查支付卡上的模数 10“双加双”校验位的增强或增强 Luhn 公式的任何实现?
本文建议进行增强:http: //d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf
增强的 Luhn 检查是否有实际用途?
有谁知道用于检查支付卡上的模数 10“双加双”校验位的增强或增强 Luhn 公式的任何实现?
本文建议进行增强:http: //d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf
增强的 Luhn 检查是否有实际用途?
这篇论文被同行评审期刊接受有点奇怪。这篇论文描述了 1970 年代 Fletcher 校验和存在的问题。它的长度和数据转置无法准确检测。
但让我们考虑一下这个提议的实际方面。如果真的深挖细节,确实是不可行的,原因很多。
Luhn 算法是一种简单的、尽力而为的方法来验证卡号。早在信用卡开始以电子方式进行广泛处理时(它们以前是用纸质印记完成的),还没有永远在线的网络来调用服务进行验证。Luhn 可以在不需要网络连接来执行验证的情况下实现。这是建立不可行性的第一个前提:您必须能够执行验证而无需遍历网络。
这种“无网络遍历”的前提使得 MII 查找不可行。有两种方法可以实现这一点:
处理卡授权可以是异步的。亚马逊这样做;他们确认收到您的订单,并且通常会在稍后确认付款处理。
最后,作者对卡片的长度做出了错误的假设。Luhn 算法适用于许多长度,因为卡号长度可以长于或短于 16 位数字。美国运通的消费卡是 15 位数字,其他卡是 16 位。商务卡长度可超过16位;我见过最多 20 位数的商用空气燃料卡。如果作者查看了 IEC/ISO 7812 标准,就会理解这一点。标准委员会甚至提议延长标准卡号的长度。很棒的是,当/如果卡号长度延长时,Luhn 算法仍然会验证卡。
帮自己一个忙,将 Luhn 作为您的第一步,然后让处理器通过现有的卡处理网络验证卡无疑是正确的,从而为您完成繁重的工作。
我进行了 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 日访问)。