ISO 8583 是什么

ISO 8583 到底是什么

它是一份关于银行卡交易报文的国际标准。它规定的是「字节该怎么排」：两个从没打过交道的系统照它排字节，就能对同一条支付请求的含义达成一致。网络、接口、产品形态都不在它的范围里。1987 版至今仍在跑：联机卡授权大多用它，Mastercard IPM 这类清算格式用 1993 版。

现行版本是 ISO 8583:2023，它把 2003 年分三册出的内容合回了一份文档。但实际工作里你遇到的多得多的是老版本：联机卡授权大多还跑 1987 版，而 Mastercard IPM 这类清算格式是 1993 版的。版本之间的差别在于有哪些域、某些域多宽，所以版本不是无关紧要的细节：同样的字节在两个版本下可以解出不同结果。MTI 的第一位就告诉你这是哪一版。

几乎没人跑纯粹的 ISO 8583。Visa、Mastercard、各国本地转接机构都有自己的一套：域号相同，但私有域各填各的、各自还有额外的码值，有时字符编码也不一样。标准给的是信封，卡组织的规范才告诉你信里写了什么。两者说法不一致时，以你手上那份接口规范为准。

一条报文长什么样

从左往右分三段读。

1. MTI——四位数字，说明这是什么报文

每一位各管一件事：

所以 0100 是 1987 版、收单方发出的授权请求，0110 是它的响应。0400 是冲正请求，0800 是签到、心跳这类网络管理报文。把四位分开读，比背一张 MTI 清单快得多。

上面这张表是 1987 和 1993 版的。2003 版把类别体系改过——冲正和拒付拆成了两个独立类别，还新增了别的——所以别把这张表套到 2003 版的链路上。完整的表在 MTI 解码 和 MTI 码值清单。

2. 位图——这条报文里有哪些域

位图是 64 个二进制位，通常写成 16 个十六进制字符。第 n 位是 1，就表示第 n 个数据域出现了，按域号从小到大排列；没出现的域就是真的不在报文里，不补位、不留占位符。这就是这个格式的诀窍：不需要额外的结构说明也能很紧凑，因为位图本身就是结构说明。

第 1 位是特殊的：它不表示 DE1，而表示后面还跟着第二个位图，把范围扩到 DE128。第 1 位是 0 的话，报文到 DE64 就结束，位图也只有 16 个十六进制字符。

还可能有第三个位图。Visa 现行规范定义了覆盖 130–192 域的第三位图，它由第二个位图的第一位——也就是第 65 位来指示，机制和第 1 位指示第二位图完全一样；没有第三位图时那一位必须是 0。所以第 65 位也不是数据域，它同样只是个开关。按「到 DE128 结束」写的解析器，在用到第三位图的链路上会从第 130 域起全部读错。

位图相关的问题大多出自两个地方：从 0 开始数位，以及忘了位图可能是 8 个原始字节而不是 16 个十六进制字符。两种情况都会让后面的域整体错开一位。

3. 数据域——值本身

每个域要么是定长，要么自己带长度前缀：

声明的长度算的是值的字符数，而不总是字节数：Hex/BCD 下两个数字压进一个字节，而二进制域的长度按字节还是按位算，取决于具体规范。解析器出现「一个域一个域地往后错」时，先查长度的单位。

拆一条真实报文

下面是一条完整的授权请求，用的是测试卡号和占位终端号，不含任何真实持卡人数据。

010072200000008080001641111111111111110000000000000010000821143000123456TERM0001702

从左往右拆开：

注意：DE49 没读之前，DE4 是没有含义的。先币种、后金额这个顺序，是金额差出一百倍最常见的来源。

上面这条报文可以直接粘进首页的解析器，看它逐域拆开。

实际会碰到的那几个域

1987 版寻址 128 个数据域；带第三位图时范围到 192。但实际工作中的问题几乎都集中在这十来个上：

域字典里有全部 128 个域的长度、格式和说明。

各类码表

ISO 8583 的日常工作里，查码值含义的时间通常多过解析报文。值得存下来的几张表：

• DE39 响应码——交易为什么被拒，以及该不该重试。
• DE3 处理码——交易类型和账户类型的完整清单，逐个码值说明。
• DE22 输入方式——磁条、芯片、非接、手输，各自意味着什么。
• MTI 解码——四位数字逐位拆开。
• EMV TLV 标签——用来看 DE55 里装了什么。
• ISO 4217 币种码——含每个币种有几位小数。

各家实现不一样的地方

有四个地方，标准到此为止、接下来得看别人的文档。每一个都让人花过一整周。

• 私有域。DE48、DE60–DE63 这些是留给私有使用的，也就是各家卡组织各填自己的子结构，不存在通用的解法。没有规范就读不了——硬猜出来的结果看着像对的，但是错的。
• 字符编码。ASCII、EBCDIC、Hex/BCD 都在用，有时同一条报文里不同的域用的还不一样。解出来是乱码，通常是编码假设错了，不是文件坏了。
• 版本之间域宽不同。DE22 在 1987 版是三位，1993 版起是十二个字符、拆成十二个子域、PAN 输入方式挪到子域 7。按一个版本写的解析器，读另一个版本时会从这个域开始一路错下去，而且不报错。
• 额外的码值。各卡组织会在标准清单之外自己加响应码和处理码。遇到没见过的值，它是卡组织自定义的可能性远大于它非法，所以该记下来继续走，而不是把报文拒掉。

常见问题

ISO 8583 现在还在用吗？

在用。卡授权链路目前仍以 8583 为主；ISO 20022 在账户间转账和实时支付上增长很快，也有面向卡交易的消息集（ATICA），两者现在是并存关系。

ISO 8583 和 ISO 20022 有什么区别？

8583 是按位置排布的紧凑字节，是为 1980 年代的线路设计的；20022 是 XML 或 JSON，数据模型丰富得多。8583 用少得多的字节表达少一些的信息，这正是它能在对时延敏感的卡组织网络上活下来的原因。它们是两种格式做部分重叠的事，不是同一个东西的两个版本。完整对比见 ISO 8583 与 ISO 20022:卡域到底变了什么。

做 ISO 8583 必须买那份标准吗？

基础结构——MTI、位图、域号、长度——不需要，这部分公开资料很充分，本站也讲了。但有一点要注意：公开流传的字段表多是第三方重建的，而且普遍不写自己描述的是哪一版，偏偏有几个域的宽度是跟版本挂钩的（DE22 就是典型）。凡是长度或名称跟版本有关的地方，以你这条链路实际跑的那一版为准。但你的报文里出现的那些私有域和额外码值，得拿到你所在卡组织或处理机构的规范。那部分不公开，也推不出来。

解析器为什么解到几个域之后就错位了？

基本上都是长度单位或者编码问题：二进制域的长度按字节给、却当成字符读；Hex/BCD 的域被当成 ASCII 读；或者位图发的是 8 个原始字节、却按 16 个十六进制字符读。找到最后一个解对的域，查它的长度规则。

延伸阅读

• ISO 8583 报文示例逐域拆解
• ISO 8583 域字典（DE2–DE128）
• DE3 处理码完整清单
• ISO 8583 学习路径