信用卡跟踪数据的正则表达式

Question

是否有任何已知的正则表达式来验证信用卡轨道1和跟踪2数据？

编辑:

来自维基百科:

金融卡上的第1轨道上的信息包含在几种格式中:A,保留用于发卡机构的专有用途,B,如下所述,CM,保留供ANSI分技术委员会X3B10和NZ使用,它们是可供个别发卡机构使用:

第1轨,格式B:

• 开始哨兵 - 一个角色(通常是'%')
• 格式代码="B" - 一个字符(仅限alpha)
• 主帐号(PAN) - 最多19个字符.通常(但不总是)与卡片正面印刷的信用卡号码相匹配.
• 字段分隔符 - 一个字符(通常为"^")
• 名称 - 2到26个字符
• 字段分隔符 - 一个字符(通常为"^")
• 到期日期 - YYMM格式的四个字符.
• 服务代码 - 三个字符
• 全权委托数据 - 可能包括Pin验证密钥指示符(PVKI,1个字符),PIN验证值(PVV,4个字符),卡验证值或卡验证码(CVV或CVK,3个字符)
• 结束哨兵 - 一个角色(一般是'？')
• 纵向冗余校验(LRC) - 它是根据轨道上的其他数据计算的一个字符和有效性字符.应该注意的是,当将卡刷到表示层时,大多数读取器设备不返回该值,并且仅使用它来验证读取器内部的输入.

专题2:此格式由银行业(ABA)开发.该轨道采用5位方案(4个数据位+ 1个奇偶校验)写入,允许16个可能的字符,即0-9,加上6个字符:<=>？.六个标点符号的选择可能看起来很奇怪,但实际上十六个代码只是映射到ASCII范围0x30到0x3f,它定义了十个数字字符加上那六个符号.数据格式如下:

• 开始哨兵 - 一个角色(通常是';')
• 主帐号(PAN) - 最多19个字符.通常(但不总是)与卡片正面印刷的信用卡号码相匹配.
• 分隔符 - 一个字符(通常为'=')
• 到期日期 - YYMM格式的四个字符.
• 服务代码 - 三个字符
• 自由裁量数据 - 如第一轨道
• 结束哨兵 - 一个角色(一般是'？')
• 纵向冗余校验(LRC) - 它是根据轨道上的其他数据计算的一个字符和有效性字符.应该注意的是,当将卡刷到表示层时,大多数读取器设备不返回该值,并且仅使用它来验证读取器内部的输入.

Answer 1

这是一个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,那就杀掉"？" 每个捕获组的一部分.然后,使用位置确定每个组.

此外,我的单个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作为额外的错误检查步骤进行比较没有坏处.

很抱歉回答似乎回答的问题!

Answer 2

我正准备在regular-expressions.info 上发布相同的链接，用于验证曲目的抄送号码部分。

现在，棘手的部分来了。跟踪数据的格式因发卡机构甚至读卡器而异。例如，“分隔符”字符并不总是相同。这同样适用于最后的“哨兵”。

维基百科给出了很好的概述：http ://en.wikipedia.org/wiki/Magnetic_stripe_card

对于 track2，卡号后跟一个“=”（有时是“D”）。那么您的到期日期为 MMDD。之后，Track2 拥有“任意数据”，可以是任何数据。

过了这一步我就不会太担心了。如果是跟踪数据，您现在就可以确定了。我想这取决于您打算如何处理数据。

无论如何，对于 Track2，您可能会做得比在 cc 正则表达式末尾添加 [=D][0-9]{4} 而不是 $ 更糟糕：

^(?: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 包含更多可变数据，因此可能会更复杂一些。

祝你好运！