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

我正准备在regular-expressions.info上发布相同的链接,以验证曲目的cc-number部分。

现在,棘手的部分来了。磁道数据在发卡机构和读卡器之间的格式不同。例如,“分隔符”字符并不总是相同的。同样适用于“哨兵”结尾。

维基百科提供了一个很好的概述: http://en.wikipedia.org/wiki/Magnetic_stripe_card

对于track2,卡号后面跟着一个“=”(有时是一个“d”)。那么你的有效期是月日。之后,track2有“任意数据”,可以是任何数据。

过了这一步,我不会担心太多。如果这是跟踪数据,你现在肯定会知道的。我想这取决于你打算用这些数据做什么。

无论如何,对于track2,您可以做得比添加[=d][0-9]4而不是在cc regex末尾添加$糟糕得多:

^(?: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包含更多的变量数据,所以触摸屏可能更复杂。

祝你好运!

这里有一个regex,我可以选择轨道1和轨道2。将此选项与regex选项“dot does not match newline”一起使用。

^%(?<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

我用这些数据进行了测试(我的读卡器按照这个顺序读取一个磁道1和二个磁道记录,对于我测试的同一张卡,下面更改了编号和名称。)

%B5581123456781323^SMITH/JOHN^16071021473810559010203?
;5581123456781323=160710212423468?

上面的regex使用命名的捕获组(“?”从每个(组)开始,我看到结果(与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。

如果regex引擎不支持命名组,只需杀死“?”每个捕获组的一部分。然后,使用位置来确定每个组。

另外,我的单次刷卡同时包含磁道1和磁道2(依次是磁道1、CRLF,然后是磁道2)。根据原始问题中的维基百科链接,卡片最多可以有3个轨迹,读者可以同时阅读轨迹1和2(或其中一个或另一个),很少阅读轨迹3。

出于这个原因,我认为使用一个同时查找轨道1和轨道2的regex是一个安全的赌注,如果两者都得到,您可以忽略轨道2(因为轨道1有更多的数据)或您希望的任何内容。

因为这两个磁道都存在于我的刷卡中,所以regex引擎将返回2个与上面的regex匹配的结果(假设读卡器和支持这两个磁道的读卡器没有读取错误)。在我的例子中,这并不困扰我,我只打算使用“第一场比赛”而忽略第二场比赛。

如果您只对轨道1感兴趣,请使用以下regex:

^%(?<FC>.)(?<PAN>[\d]{1,19}+)\^(?<NM>.{2,26})\^(?<ED>[\d]{0,4}|\^)(?<SC>[\d]{0,3}|\^)(?<DD>.*)\?\Z

如果您只对轨道2感兴趣,请使用regex:

^;(?<PAN>[\d]{1,19}+)=(?<ED>[\d]{0,4}|=)(?<SC>[\d]{0,3}|=)(?<DD>.*)\?\Z

但我认为检查这两个方面并没有什么坏处,然后使用您得到的第一个,或者可能将跟踪1与跟踪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?

轨道1,格式B翻译为

^%B[^\^\W]{0,19}\^[^\^]{2,26}\^\d{4}\w{3}[^?]+\?\w?$

对什么构成有效字符有一些假设。

当然,没有检查数据是否真正有意义,并且LRC(如果存在)也不能被验证。

你能对照一些真实的数据检查一下这个吗?

轨道2翻译为

;[^=]{0,19}=\d{4}\w{3}[^?]+\?\w?

注意:track1中的帐号可以包含美国运通卡的空格。 所以:

^%(?.)(?[\d\s]{1,19}+)\^(?.{2,26})\^(?[\d]{0,4}|\^)(?[\d]{0,3}|\^)(?.*)\?|;(?[\d]{1,19}+)=(?[\d]{0,4}|=)(?[\d]{0,3}|=)(?.*)\?\Z