当检测到未经训练的购物者输入信用卡/借记卡号时,一些花哨的网站会显示错误对话框,因为它打印在带有空格的卡上.是否有可能以某种方式编写一个Java Web应用程序,用空格处理这些数字,就好像它们是正确的一样？
我的观点是,任何拒绝带有空格的信用卡号的Web应用程序都无法正常工作.当您收到信用卡号码时,很容易做到:
String ccNumber = ccNumber.replaceAll("[\\s-]+", "");
删除空格和破折号(有些也使用它们).然后验证结果.如果您强迫他们删除您可以轻松删除的空间,您只会烦扰您的用户.
至于如何验证,这取决于很多事情,例如您正在使用的Web框架以及您选择的验证选项.例如Struts 1可能会也可能不会使用Apache Commons Validator,而Spring MVC将(可能)使用Spring验证等等.所以我不能确切地告诉你如何验证,但我可以告诉你要验证什么.
的第一件事是,随着空格的CC数应该不会被拒绝.大多数人会发现:
4123 0987 8876 2939
比以下更容易阅读:
4123098788762939
如果用户错过或错误输入数字并且需要找到他或她的信用卡号码验证失败的原因,那么这一点非常重要.这篇文章顶部的replaceAll()涵盖了这种情况.
第二件事是你以正确的方式显示信用卡号码(即使出于安全原因用X替换了某些数字).我建议你阅读信用卡号码剖析.
该页面为您提供了位数和有效前缀的规则.一个强大的Web应用程序将实现这些,因此您可以在尝试使用它之前判断信用卡号是否无效.最多可能需要30秒(或更长时间)才能将信用卡详细信息提交给付款网关,因此您不应该这样做,直到您确定可以接受付款为止.否则就是提供非常糟糕的用户体验.如果用户失败1-2次而不是等待,用户将有机会放弃.
至于显示它们,取决于数字位数:
16:4组由空格隔开;
15:像美国运通卡一样,即4-6-5,每组之间有空格;
14:像大莱卡一样,即4-6-4,每组之间有空格;
13:从未见过13,但4-5-4或4-4-5或5-4-4(或可能是3-3-3-4)让人想起.
在提交处理作为标准验证例程的一部分之前,应根据页面中提到的校验和算法验证信用卡号.该页面具有该例程的Java实现.
每个接受信用卡付款的网站都应该将上述所有内容作为绝对最低限度,或者只是丢弃业务,因为一部分用户会感到沮丧.
所以简短版本是两个简单的规则:
用户输入尽可能宽容; 和
尽可能在提交之前验证信用卡详细信息.
我会去除所有非数字字符,然后检查长度是否有效,然后通过像Luhn算法这样的真实验证运行用户输入.
String ccNumber = input.replaceAll("\\D", "");
去除所有非数字String input.
网站强迫您以特定格式输入信用卡号码(和类似的东西) - 严重惹恼我.
那些人只是因为他们(开发人员)懒惰而给顾客带来不便.没有理由不以任何提供的格式接受信用卡号码,电话号码等信息.唯一的限制是需要了解如何解释该值.
您不应该关心我是否输入5555-4444-3333-2222或5555444433332222,如果您不喜欢它们,只需删除破折号 - 与空格相同.使用电话号码,除非您要自动拨号,否则您可能根本不关心它的格式,因此除非必须,否则不要惹恼您的用户.
很不幸的是,不行.Java只是无法处理这些要求,因为在x86芯片上模拟Java虚拟机涉及很多开销,没有留下像Perl的正则表达式这样的有用构造的空间,因此可以这样做:
$input =~ s/\D//g;
Java几年前尝试添加正则表达式,但它们只运行在不再使用的PowerPC芯片上.问题是所有正则表达式都必须作为字符串包含而不是作为第一类语言构造,因此需要加倍反斜杠,但是每个人都知道反斜杠在x86架构的主操作系统上意味着不同的东西.
我的建议是升级到Perl.Scheme也被称为能够处理这种情况并且比竞争对手具有巨大的优势,但Scheme仅在LISP机器上运行.
不幸的是,为什么这些花哨的网站需要向未经训练的购物者显示错误对话框:强迫购物者以机器喜欢的格式重新输入他们的号码.
为什么,如果只有机器可以进行"数据处理",那么机器本身就可以改变数据格式!或者,只要没有"未经训练"的购物者这样的东西!唉!
京公网安备 11010802040832号 | 京ICP备19059560号-6 