Track 2 磁道数据解析 —— 拆开它，读懂服务码

贴一串 track 2 进来，每一段都给你标出名字：卡号（带 Luhn 校验）、有效期、三位服务码逐位解释、以及发卡行放在自定义字段里的那一段。ASCII 和 BCD 两种分隔符都认。

Track 2 磁道数据 —— DE35

一串里装着卡号、什么时候到期、这张卡被允许做什么，以及一段由发卡行自己定义的数据。它最早是磁卡上的第二条磁道；同样的排布现在以 DE35 的身份走在 ISO 8583 里，从芯片卡上读出来时叫 EMV 的 tag 57。

值得细看的是那三位服务码 —— 那是卡在告诉你，它本来应该接受哪些交易。

Track 2 数据（带起止哨兵也行，会自动去掉）

试试：

这一串是由什么组成的

track 2 是一行，中间有个分隔符。分隔符之前是卡号；之后是几段固定位置的数据，再加上发卡行自己选择放进去的东西。

整串装在 37 个字符里，因为物理磁道一共 40 个字符 —— 含起始哨兵、结束哨兵和一位校验字符。这也正是 ISO 8583 里 DE35 的上限。一串超过 37 就装不进那个域，说明上游已经出了问题。

有两处可以直接忽略：开头的 ;，以及结尾的 ? 再加一个字符，那是物理读卡留下的起止哨兵和纵向冗余校验。日志里经常连它们一起打印。本页解析前会自动去掉。

三位数字，每一位回答一个不同的问题。这是大家最常来查的一段，也是一张卡会被终端直接拒掉、而终端压根没联系过任何人的原因。

所以大家查得最多的 101，意思是：可国际使用、常规授权、买什么都不限。201 是同样这张卡带芯片。221 再加上「须联机联系发卡行」。而服务码以 9 开头的是测试卡 —— 这个值得设个告警：它没有理由出现在生产流量里。

这三位里有三种取值会改变你对一笔拒绝的理解。如果第三位要求 PIN 而终端压根没做持卡人验证，那这笔拒绝是卡本身解释的，不是发卡行的风控。如果第一位说仅限境内而交易跨了境，同理。先读服务码，往往能省掉一轮升级。

ASCII 下域分隔符是 =。但 track 2 用的是纯数字字符集，当数据被压缩成 BCD（一个字节装两位数字）时，没有一个码位能表示等号，于是用十六进制的 D 顶上。

两种写法说的是同一张卡。你看到哪一种，取决于你在链路的哪一层抓的数据 —— 所以同一笔交易可能在网关日志里是 =，在主机跟踪里是 D。只认其中一种的代码解另一种会失败，而且不会说明原因，这才是需要知道这件事的实际理由。本页两种都认。

这个排布来自磁条，但名字活得比介质长。芯片卡在 EMV 的 tag 57 里带一份等价数据，结构一样，是从芯片读出来的；非接触碰一下也会产生它。所以报文里出现 track 2 数据，并不能说明卡是怎么被读取的。

真正记录这件事的域是 DE22，服务点输入方式。要判断一笔交易是芯片读、磁条读还是降级，去看 DE22 —— 如果服务码说这张卡有芯片、而 DE22 说是从磁条读的，这个组合就是降级的定义。

track 1 是另一套排布：字母数字混合、更长，而且含持卡人姓名。它走的是 DE45，本页不解析它。

自定义数据由发卡行定义。它常用来放 PIN 校验值和卡片校验值，但每一段从哪里开始、有多长，来自发卡行自己的个人化规范，不来自哪个标准。

一个通用解析器如果去猜这些偏移，只会给出看起来很自信的胡话。所以本页把这个字段显示出来就停下。真要拆，排布得从发卡行那里拿。

有一件相关的事是公开的、也值得知道：磁条上的那个校验值，和芯片里 track 2 等价数据里的那个，是故意做成不一样的。这是设计如此 —— 从芯片里抄出来的值做不出一条能用的磁条。而这两个都不是卡背面印的那串数字，那是另一个完全不同的值。

数据不出浏览器。解析全在本页的 JavaScript 里跑，所以真实磁道数据也可以贴进来。如果你们的规定是真实卡数据绝不碰网站，离线版存在的意义正是让你能证明这一点。上面的示例用的是各家公开的测试卡号。