ISO 8583 Parser
免费 · 解析器 · 约 6 分钟 · 最后更新 2026-08-09
在线工具

Mastercard IPM 文件解析(T112)

把 Mastercard IPM 清算文件(也就是 T112)拖进来,按字段名读,不用对着十六进制猜。1014 分块、VBS 记录框、EBCDIC 解码自动处理,PDS 子域直接展开。

文件不会离开你的电脑

解析完全在当前浏览器标签页里跑,纯客户端 JavaScript。这个页面没有上传接口——不放心可以打开开发者工具的网络面板,边解析边看:没有任何请求带着你的文件出去。断网也照样能用。

这是刻意的设计,不是顺带的优点。IPM 文件从来不是测试数据,里面每一条都是真实卡号和真实交易——所以要求上传清算文件的解析工具,多数发卡行和处理商在合规上根本不允许用。

自动识别失败时,用上面两个下拉手动指定编码和格式。

清算文件不能外传?离线版 →

IPM 文件里有什么

一个 IPM 清算文件是三层叠起来的,每一层都有各自的坑。三层没有一层是随便定的——每一层都是这个格式出身的化石。

1014 字节分块
记录被塞进 1014 字节的块里:1012 字节内容 + 2 个填充字节。这个数字看着莫名其妙,直到你注意到填充通常是什么:0x40,EBCDIC 的空格。分块是大型机时代的文件传输惯例——固定大小的物理块让磁带和数据集 I/O 可预测——而清算链路两端跑了几十年大型机,惯例就留下来了。解析前先剥掉填充,否则第一块之后的所有记录都会错位。

VBS 记录框
解块之后的字节流里,每条记录前面有 4 字节大端长度,长度为 0 表示文件结束。没有分隔符也没有换行,出错后没有任何东西帮你重新对齐:一个长度读错,后面所有记录边界都会悄悄漂移。

EBCDIC 编码
文本字段是 EBCDIC 不是 ASCII,数字在 0xF0–0xF9 而不是 0x30–0x39。它和分块活下来的原因是同一个:清算是批处理管道,两端几十年前就约定好了编码,批处理格式不到万不得已不会改,而这一个从来没被逼到那一步。确实也有 ASCII 变体存在,所以本工具从第一条记录的 MTI 字节判断编码。

PDS 子域不是「更多的数据域」

一条 IPM 记录里其实有两种字段。数据域是 ISO 8583 那一层:编号 1–128,存在与否由位图决定,每个域有固定的类型和长度规则。这套布局紧凑但死板——128 个按位置排的槽位,装不下清算想说的所有事情。

于是有几个数据域(48、62、123–125)充当 PDS(Private Data Subelements)的载体。PDS 条目是自描述的:4 位 tag + 3 位长度 + 值,循环到载体域用完为止。因为每个条目自带名字,新 tag 可以随时加进来而不动位图布局——这正是为什么商业上真正有料的数据(费用、标志位、产品标识)大多在 PDS 里,而不在某个编号的 DE 里。

本工具会把载体域全部展开,每个 PDS tag 单独一行。值按原样展示:它们内部怎么再切分属于 Mastercard 自己的文档,本页只解释公开层面的结构。

拿到一个 IPM 文件,先看什么

看任何字段值之前,先确认外框没问题——大部分「文件坏了」最后查出来是框架层的问题,不是数据的问题。

先定编码。第一条记录的 MTI 字节(4 字节长度前缀之后)就能定案:F1 F6 F4 F4 是 EBCDIC 的「1644」,31 36 34 34 是 ASCII 的同一串。

再看首尾。一个完整的文件以 MTI 1644 的文件头记录开始,以 1644 的文件尾记录结束,中间的交易是 1240 明细记录。从半截开始、或者没有尾记录的文件,是在传输路上被截断的。

边界不对时。记录长度离谱、字段整体错位,多半是解块方式选错了,或者文件在传输途中被重新编码——FTP 文本模式悄悄改字节是经典案例。先修传输,再怀疑字段。

怎么看解析结果

每条记录开头是 4 位 MTI,紧跟 16 字节位图,覆盖数据域 1–128;位图决定哪些字段存在,所以字段位置从来不是固定的。输出先给业务视图——金额按各币种的小数位换算、卡号默认脱敏——下面才是完整的技术字段表、单条 JSON 和原始 hex。同一个文件,对账的人和做对接的人各看各的那一层。

为什么清算文件不该被上传

凡是碰 IPM 文件的工具,别的功能都排在一个问题后面:文件去了哪里?清算文件就是当天的卡交易明细,没有任何脱敏——按 PCI DSS 的口径,光是里面的卡号就已经构成持卡人数据。

清算文件不是日志文件:里面每一条记录都是一个真实卡号加一笔真实交易,文件本身就是敏感数据。它一旦落到你控制不了的服务器上,解析问题就变成了数据事件问题。

这就是这个解析器整个设计的出发点:文件用浏览器的 FileReader API 读进来,从头到尾不进任何网络请求——而且这一点不需要你信任谁,你自己开发者工具的网络面板就能证明。

这个工具不做什么

它读的是 IPM 格式的交易文件,实际就是 T112。Mastercard 的报表类文件它读不了,那是完全不同的格式:T140 是 GCMS 对账报表、TQR4 是 Mastercom 对账报表,两者都不含 ISO 8583 记录。IPM 参数抽取文件(IP0000T1 那一类)同样不在范围内——外层封装一样,但记录布局不同。

它只内置公开可得的 IPM 数据域布局。PDS 的值按原始文本展示,EMV/ICC 数据按原始 TLV 十六进制展示,不解释任何卡组私有子域名称。Visa 清算文件是另一种格式,不在本工具的处理范围内。

字段定义的来源

字段定义和解析规则遵循 Anthony Delosa 的 cardutil(MIT 许可)。本页是同一套公开规则的独立浏览器端实现。

延伸阅读