13

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

编辑:

来自维基百科

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

音轨 1,格式 B:

  • 开始哨兵——一个字符(通常是'%')
  • Format code="B" — 一个字符(仅限字母)
  • 主帐号 (PAN) — 最多 19 个字符。通常,但并非总是如此,与印在卡正面的信用卡号相匹配。
  • 字段分隔符 - 一个字符(通常为 '^')
  • 名称 — 2 到 26 个字符
  • 字段分隔符 - 一个字符(通常为 '^')
  • 到期日期 — YYMM 格式的四个字符。
  • 服务代码——三个字符
  • 任意数据 — 可能包括密码验证密钥指示符(PVKI,1 个字符)、密码验证值(PVV,4 个字符)、卡验证值或卡验证码(CVV 或 CVK,3 个字符)
  • End sentinel - 一个字符(通常是“?”)
  • 纵向冗余校验 (LRC) — 它是一个字符和一个有效字符,由轨道上的其他数据计算得出。需要注意的是,大部分读卡器设备在刷卡到表现层时并不会返回这个值,只是用来验证读卡器内部的输入。

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

  • 开始哨兵——一个字符(通常是';')
  • 主帐号 (PAN) — 最多 19 个字符。通常,但并非总是如此,与印在卡正面的信用卡号相匹配。
  • 分隔符 - 一个字符(通常为 '=')
  • 到期日期 — YYMM 格式的四个字符。
  • 服务代码——三个字符
  • 自由裁量数据——如第一轨
  • End sentinel - 一个字符(通常是“?”)
  • 纵向冗余校验 (LRC) — 它是一个字符和一个有效字符,由轨道上的其他数据计算得出。需要注意的是,大部分读卡器设备在刷卡到表现层时并不会返回这个值,只是用来验证读卡器内部的输入。
4

5 回答 5

11

这是一个 REGEX,它适用于我选择 Track 1 和 Track 2。将其与正则表达式选项“点不匹配换行符”一起使用。

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

上面的正则表达式使用命名捕获组(“?”开始于每个(组)),我看到结果(使用 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 道中使用。

如果您的正则表达式引擎不支持命名组,只需取消“?” 每个捕获组的一部分。然后,使用位置来确定每个组。

此外,我的单次 SWIPE 包含轨道 1 和轨道 2(按此顺序,轨道 1、crlf 和轨道 2)。根据原始问题中的 Wikipedia 链接,卡片最多可以有 3 个轨道,而读者可能会同时读取轨道 1 和 2(或其中一个),而很少读取轨道 3。

出于这个原因,我认为使用同时查找轨道 1 和轨道 2 的 REGEX 是一个安全的选择,如果您同时获得两者,则可以忽略轨道 2(因为轨道 1 有更多数据)或任何您想要的。

因为这两个轨道都出现在我的滑动中,所以 REGEX 引擎将返回 2 个与我上面的 REGEX 匹配的匹配项(假设阅读器没有读取错误,并且阅读器支持这两个轨道)。就我而言,这不会打扰我,我只是打算使用“第一场比赛”而忽略第二场比赛。

如果您只对轨道 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 进行比较作为额外的错误检查步骤并没有什么坏处。

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

于 2013-11-19T21:06:25.047 回答
2

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

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

维基百科给出了一个很好的概述: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 包含更多可变数据,因此可能会更复杂一些。

祝你好运!

于 2010-03-29T20:27:12.643 回答
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?
于 2010-03-30T13:48:54.637 回答
1

音轨 1,格式 B 转换为

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

关于什么构成有效字符的一些假设。

当然,没有检查数据是否真正有意义,也无法验证 LRC(如果存在)。

你能对照一些真实数据检查一下,看看它是否有效吗?

音轨 2 转换为

;[^=]{0,19}=\d{4}\w{3}[^?]+\?\w?
于 2010-03-29T20:25:59.343 回答
0

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

^%(?.)(?[\d\s]{1,19}+)\^(?.{2,26})\^(?[\d]{0,4}|\^)(?[\d]{0,3}|\^)(?.*)\?|;(?[\d]{1,19}+)=(?[\d]{0,4}|=)(?[\d]{0,3}|=)(?.*)\?\Z
于 2017-04-22T18:53:39.607 回答