解析各卡组 ISO 8583 报文:MTI、位图、128 数据域含义,DE55 EMV-TLV 逐 tag 解码,支持 ASCII / Hex(BCD) / EBCDIC。
一条 ISO 8583 报文永远是同一个三层结构：4 位 MTI（消息类型指示符）说明这是什么消息，紧随其后的一到两张 64 位位图标明哪些数据域出现，然后各数据域按域号从小到大依次排开。上面的解析器会把这三层拆开展示；理解它们是怎么咬合的，才知道解析结果哪部分可信、出问题时该从哪里查起。
MTI 逐位读：版本、消息类、功能、来源。0100 是授权请求，0110 是它的应答；0200 是金融类请求，0400 是冲正，0800 是网络管理（签到、回声测试）。位图之后，数据域按域号升序排列，每个域有自己的格式——n 数字、an 字母数字、b 二进制——以及长度类型：定长，或带 2/3 位长度前缀的变长（LLVAR / LLLVAR）。入门推荐先读《看懂 ISO 8583 报文：MTI、位图、数据域》，全部 128 个域的名称、格式和含义见《ISO 8583 数据域完整列表》。还有一个值得尽早知道的坑：DE4 金额是按货币最小单位存的整数，000000001000 在美元下是 10.00、在日元下是 1000——原因见《金额为什么没有小数点》。
主位图的第 1 位很特殊：它不对应任何数据域，而是一个开关——置 1 表示主位图后面还紧跟一张副位图，覆盖域 65–128。速判方法：位图第一个十六进制字符大于等于 8，就说明第 1 位为 1，位图总长是 32 个十六进制字符而不是 16。这一位判断错，位图之后的所有字段会整体错位。手工推位图可以用位图计算器。
线路上的字节本身不带"我是什么编码"的标签，怎么读全靠双方约定。ASCII 下一个字符占一字节，MTI 0200 是 30 32 30 30；压缩 BCD 一个字节装两个数字，同一个 MTI 只有 02 00 两字节；EBCDIC 是 IBM 主机字符集，数字 0 编码为 F0，于是 0200 变成 F0 F2 F0 F0。用错约定，轻则一屏乱码，重则后面每个域的边界全部错位。更麻烦的是真实报文经常一条里混用几种编码：数字域走 BCD、文本域走 EBCDIC、DE55 是二进制 TLV。想直观对比同一串字节在两种字符集下长什么样，用十六进制查看器；数字与 BCD 的互转用进制与 BCD 转换器。
另外注意：授权报文和清算文件是两套体系。Mastercard 清算走 IPM 文件，基于 ISO 8583:1993，要用单独的 IPM 清算文件解析器。
ISO 8583 是银行卡交易报文的国际标准，终端、收单机构、卡组织和发卡行之间传递交易信息就靠它。每条报文由三层组成：4 位 MTI 表明消息类型，一到两张位图标明哪些域出现，最多 128 个数据域承载实际内容。目前主流卡组织的授权链路大多仍基于 1987 版。
主位图 64 位，即 16 个十六进制字符，第 N 位为 1 表示数据域 N 在报文里出现。若第 1 位为 1（位图首个十六进制字符大于等于 8），主位图后面紧跟一张覆盖域 65–128 的副位图，位图总长变成 32 个十六进制字符。把十六进制展开成二进制、标出为 1 的位置，就得到要依次读取的域清单。
四位各司其职：第 1 位是版本（0 = 1987 版），第 2 位是消息类（1 授权、2 金融、4 冲正、8 网络管理），第 3 位是功能（0 请求、1 应答、2 通知），第 4 位是来源（谁发起）。例如 0100 是授权请求，0110 是对应的应答；0200/0210 是金融请求与应答，0400 是冲正。
解析全程在你的浏览器里用本地 JavaScript 完成，报文不会上传到任何服务器，也不会被存储，无需注册登录。如果是生产环境的真实报文，把解析结果分享给他人之前，仍建议先自行遮蔽卡号等敏感字段。
因为字节本身不携带编码信息，怎么解读完全取决于约定。数字 0200 在 ASCII 下是 30 32 30 30，在压缩 BCD 下是 02 00，在 EBCDIC 下是 F0 F2 F0 F0——按错的约定去读，后面每个域的边界都会错位。真实卡组报文还经常一条里混用多种编码：数字域 BCD、文本域 EBCDIC、DE55 二进制 TLV。
两家的授权报文都基于 ISO 8583，但不能互换：报文头、编码约定和私有域布局都不同，比如 Mastercard 的 DE48 内部按 PDS 子域组织。清算侧差异更大，Mastercard 走基于 ISO 8583:1993 的 IPM 文件格式，和授权报文不是一套。
想支持的卡组 / 数据域、发现的解析问题、功能建议——欢迎留言,提交后我们会尽快查看。