是否有任何已知的正则表达式来验证信用卡轨道1和跟踪2数据?
编辑:
来自Wikipedia:
金融卡上第1轨的信息包含多种格式:A,保留供发卡机构专有使用,B,如下所述,CM,保留供ANSI分技术委员会X3B10和NZ使用,可供个别发卡机构使用:
跟踪1 ,格式B:
Track 2 :此格式由银行业(ABA)开发。该轨道采用5位方案(4个数据位+ 1个奇偶校验)写入,允许16个可能的字符,即0-9,加上6个字符: < => ? 。六个标点符号的选择可能看起来很奇怪,但实际上十六个代码只是映射到ASCII范围0x30到0x3f,它定义了十个数字字符加上那六个符号。数据格式如下:
答案 0 :(得分:10)
这是一个REGEX,可以让我选择Track 1和Track 2.使用正则表达式选项“Dot不匹配换行符”。
^%(?<FC>.)(?<PAN>[\d]{1,19}+)\^(?<NM>.{2,26})\^(?<ED>[\d]{0,4}|\^)(?<SC>[\d]{0,3}|\^)(?<DD>.*)\?|;(?<PAN>[\d]{1,19}+)=(?<ED>[\d]{0,4}|=)(?<SC>[\d]{0,3}|=)(?<DD>.*)\?\Z
我测试了这些数据(我的读者正在按照这个顺序读取Track 1和Track 2记录,对于我测试的同一张卡 - 下面更改了数字和名称。)
%B5581123456781323^SMITH/JOHN^16071021473810559010203?
;5581123456781323=160710212423468?
上面的REGEX使用NAMED CAPTURE GROUPS(从每个(组)开始的“?”),我看到结果(使用RegexBuddy):
Match 1: %B5581123456781323^SMITH/JOHN^16071021473810559010203? 0 54
Group "FC": B 1 1
Group "PAN": 5581123456781323 2 16
Group "NM": SMITH/JOHN 19 10
Group "ED": 1607 30 4
Group "SC": 102 34 3
Group "DD": 1473810559010203 37 16
Match 2: ;5581123456781323=160710212423468? 56 34
Group "FC" did not participate in the match
Group "PAN": 5581123456781323 57 16
Group "NM" did not participate in the match
Group "ED": 1607 74 4
Group "SC": 102 78 3
Group "DD": 12423468 81 8
请注意,第二场比赛不会在第2道(比赛2)中识别FC(格式代码)和NM(名称),因为它们未在第2道中使用。
如果你的正则表达式引擎不支持NAMED GROUPS,那就杀掉“?”每个捕获组的一部分。然后,使用position来确定每个组。
此外,我的单个SWIPE包含BOTH轨道1和轨道2(按顺序,轨道1,一个crlf,然后是轨道2)。根据原始问题中的维基百科链接,卡片最多可以有3个曲目,读者可能会读取曲目1和曲目2(或者一个或另一个),很少会跟踪曲目3.
出于这个原因,我认为使用寻找轨道1和轨道2的REGEX是一个安全的选择,如果你同时获得两者,你可以忽略轨道2(因为轨道1有更多数据)或任何你想要的。
因为我的滑动中存在两个轨道,所以REGEX引擎将返回上面的REGEX的2个匹配(假设读取器和支持两个轨道的读取器没有读取错误)。在我的情况下,这不会打扰我,我只是打算使用“第一场比赛”并忽略第二场比赛。
如果您只对曲目1感兴趣,请使用此正则表达式:
^%(?<FC>.)(?<PAN>[\d]{1,19}+)\^(?<NM>.{2,26})\^(?<ED>[\d]{0,4}|\^)(?<SC>[\d]{0,3}|\^)(?<DD>.*)\?\Z
如果您只对曲目2感兴趣,请使用正则表达式:
^;(?<PAN>[\d]{1,19}+)=(?<ED>[\d]{0,4}|=)(?<SC>[\d]{0,3}|=)(?<DD>.*)\?\Z
但是我认为检查两者然后使用你得到的第一个,或者可能将轨道1和轨道2作为额外的错误检查步骤进行比较没有坏处。
很抱歉回答似乎已回答的问题!
答案 1 :(得分:2)
我准备在regular-expressions.info上发布相同的链接,用于验证曲目的cc编号部分。
现在,是棘手的部分。跟踪数据在发卡机构甚至读卡器之间的格式各不相同。例如,“分隔符”字符并不总是相同。同样适用于最终的“哨兵”。
维基百科提供了一个很好的概述:http://en.wikipedia.org/wiki/Magnetic_stripe_card
对于track2,卡号后跟一个'='(或偶尔为'D')。那么你的有效期是MMDD。在那之后,Track2有“自由裁量数据”,可以是任何东西。
在此之后我不会太担心。如果它是跟踪数据,那么你现在就可以肯定了。我想这取决于你的目标是做什么。
无论如何,对于Track2,你可能会比添加[= D] [0-9] {4}而不是cc正则表达式末尾的$更糟糕:
^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})[=D][0-9]{4}
对于track1,您可以执行类似的操作... Track1包含更多可变数据,因此可能触摸更复杂。
祝你好运!答案 2 :(得分:2)
以下两个正则表达式似乎验证了轨道1和轨道2数据。请注意,这些正则表达式假定所使用的字符是上面维基百科信息中“通常”使用的字符。
Track 1: ^%B\d{0,19}\^[\w\s\/]{2,26}\^\d{7}\w*\?$
假设%和?是哨兵字符,^用作字段分隔符。还假设帐号,日期和服务代码是数字。
Track 2: ;\d{0,19}=\d{7}\w*\?
假设;和?是前哨字符,=是字段分隔符。还假设帐号,日期和服务代码是数字。
我使用从MagTek读卡器读取的轨道数据测试了这些表达式。以下两组轨道数据与读取器读取的内容匹配,并根据上面的两个正则表达式进行验证(数字显然已更改):
%B1234567891234567^SMITH/JOHN ^15024041234567891234?
;1234567891234567=152024041234567891234?
答案 3 :(得分:1)
曲目1,格式B转换为
^%B[^\^\W]{0,19}\^[^\^]{2,26}\^\d{4}\w{3}[^?]+\?\w?$
对于什么构成有效角色有一些假设。
当然,没有检查数据是否真正有意义,并且LRC(如果存在)也无法验证。
您可以针对某些实际数据进行检查,看看它是否有效吗?
Track 2转换为
;[^=]{0,19}=\d{4}\w{3}[^?]+\?\w?
答案 4 :(得分:0)
注意:track1中的帐号可以包含American Express卡的空格。 所以:
^%(?.)(?[\d\s]{1,19}+)\^(?.{2,26})\^(?[\d]{0,4}|\^)(?[\d]{0,3}|\^)(?.*)\?|;(?[\d]{1,19}+)=(?[\d]{0,4}|=)(?[\d]{0,3}|=)(?.*)\?\Z