【问题标题】:Are there any valid credit numbers that are initial substrings of other valid credit card numbers?是否有任何有效的信用卡号是其他有效信用卡号的初始子串?
【发布时间】:2016-09-18 01:27:21
【问题描述】:

我正在尝试实现对有效信用卡号的识别,以便我可以转换到下一个字段。鉴于信用卡号码有各种长度,我的问题是我是否可以指望这样一个事实,即如果我确认一个有效的信用卡号码(通过正则表达式和 Luhn 算法使用),我不会排除其他有效的信用卡号码(就正则表达式/Luhn 和发行而言)更长。

【问题讨论】:

  • 我在不久的将来看到了风滚草徽章
  • 这与编程有什么关系?
  • 它是关于您是否可以合理地自动推进信用卡号码输入的最后一位的编程问题。不过,我承认这根本不是编程问题。

标签: credit-card luhn


【解决方案1】:

考虑有效 PAN 长度为 16 到 19 位数字的 Visa,因为最后一位数字是前面数字的校验位,总会有另一个 PAN 有一个额外的数字,它将通过 LUHN 测试。

4929847243031832
49298472430318328
492984724303183283

【讨论】:

  • 我在想,根据政策,Visa 可能不会发布任何前一个子字符串有效的数字。这仍然让他们有足够的扩张空间。你确定不是这样吗?
  • 我不知道他们的政策是什么。
  • @彼得。 Visa不会直接管理每个号码。他们为发行人分配范围。前六位数字是发行人标识符号,其余数字由该发行人分配。 Visa 是否按照此处建议的方案提供指导,我不确定。不过我的怀疑是,即使他们这样做了,您也可能会发现一个忽略该指导的古怪发行人。
  • @PaulG 如果您想将此作为答案,那么赏金就是您的,因为这似乎是我将获得的最多信息。 :-)
  • @PeterAlfvin,也许亚历克斯可以将此信息编辑到他的答案中。我仍然会说这个答案对于您的问题是根本正确的。我确实花了一些时间浏览了一些官方 Visa 文档,但没有看到任何可以缓解此问题的内容。
【解决方案2】:

我不确定使用正则表达式是否是检查信用卡有效性的有效方法。几乎可以肯定地说 card.length=16 因为任何数字 1234567...16 都是有效的 我认为如果您正在实施支付系统以使用有效的支付处理库,因此您可以通过他们的图书馆

【讨论】:

  • 我说的是正则表达式和 Luhn 测试。有关详细信息,请参阅参考问题。对每个键入的字符都访问服务器是不切实际的。
  • 只是一个简单的 luhn 谷歌和信用卡给我这个rosettacode.org/wiki/Luhn_test_of_credit_card_numbers#C.23,它看起来很容易实现。你看到了吗?我指的是当您实施第三方支付库并需要自定义验证时。
  • 正如我在对另一个答案的评论中指出的那样,这不是代码问题,甚至不是 Luhn 算法的问题,对此我已经有了一个完美的工作实现。这是一个关于信用卡发行政策的问题。
【解决方案3】:

有效的信用卡号(PAN-primary account number)有11到24位数字,不同的系统有自己的长度,最后加上LRC(纵向冗余校验)。 如果它是 VISA 或万事达卡的 18 个符号,则 123456789123456789 将是有效的。 https://en.wikipedia.org/wiki/Longitudinal_redundancy_check 它在标准 ISO/IEC_7813 https://en.wikipedia.org/wiki/ISO/IEC_7813 中定义

【讨论】:

    【解决方案4】:

    考虑法律问题:当用户认为自己输入了正确的号码时,他们确实应该是告诉您的人。我只删除空格,其他任何内容都可能使您因干扰而承担责任。我会建议您不要尝试做什么。在用户尝试进行交易时,这种可用性类型不会影响交易。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2020-03-23
      • 2018-04-22
      • 2012-12-17
      • 2014-01-20
      • 2014-12-30
      • 2011-01-10
      • 2018-12-23
      • 2014-10-27
      相关资源
      最近更新 更多