这里有一个正则表达式，它可以让我同时选择轨道1和轨道2。使用正则表达式选项“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和轨道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中的FC（格式代码）和NM（名称）（匹配2），因为它们在磁道2中没有使用。
如果你的正则表达式引擎不支持NAMED GROUPS，只要杀死“？“每个捕获组的一部分。然后，使用位置来确定每个组。
此外，我的单SWIPE包含轨道1和轨道2（按照这个顺序，轨道1，一个crlf，然后轨道2）。根据原始问题中的维基百科链接，卡片最多可以有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轨进行比较作为额外的错误检查步骤。
抱歉回答了似乎已经回答的问题！

我正准备在regular-expressions.info上发布相同的链接，用于验证曲目的cc号部分。
现在，棘手的部分来了。磁道数据在发卡机构甚至读卡器之间的格式各不相同。例如，“分隔符”字符并不总是相同的。这同样适用于“哨兵”。
Wikipedia提供了一个很好的概述：http://en.wikipedia.org/wiki/Magnetic_stripe_card
在track 2中，卡号后面是'='（或偶尔是'D'）。然后你有到期日作为MMDD。在此之后，Track 2具有“自由裁量数据”，其可以是任何数据。
在这之后我不会太担心。如果是轨道数据，你现在应该很确定了。我想这取决于你打算用这些数据做什么。
无论如何，对于Track 2，你可以做得比在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}

字符串
对于track 1，您可以执行类似的操作…Track 1包含更多的可变数据，因此可能会更复杂。
祝你好运！

下面的两个正则表达式似乎验证了磁道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

字符串