把 Mastercard IPM 清算文件拖进来，直接看字段而不是十六进制。1014 分块、VBS 记录框、EBCDIC 编码都会自动处理。
自动识别失败时，用上面两个下拉手动指定编码和格式。
一个 IPM 清算文件是三层叠起来的，每一层都有各自的坑。
1014 字节分块
记录被塞进 1014 字节的块里：1012 字节内容 + 2 个 0x40 填充字节。不先剥掉填充，第一块之后的所有记录都会错位。
VBS 记录框
解块之后的字节流里，每条记录前面有 4 字节大端长度。长度为 0 表示文件结束。这一步错了，记录边界会悄悄漂移。
EBCDIC 编码
文本字段是 EBCDIC 不是 ASCII，数字在 0xF0–0xF9 而不是 0x30–0x39。本工具从 MTI 四个字节自动判断编码。
每条记录开头是 4 位 MTI，紧跟 16 字节位图，覆盖数据域 1–128。位图决定哪些字段存在，所以字段位置不是固定的——取决于位图怎么说。标记为 PDS 载体的字段会再展开一层：一个 PDS 条目是 4 位 tag + 3 位长度 + 数据，循环到字段用完为止。
它读的是 IPM 格式的交易文件，实际就是 T112。Mastercard 的报表类文件它读不了，那是完全不同的格式：T140 是 GCMS 对账报表、TQR4 是 Mastercom 对账报表，两者都不含 ISO 8583 记录。IPM 参数抽取文件（IP0000T1 那一类）同样不在范围内——外层封装一样，但记录布局不同。
它只内置公开可得的 IPM 数据域布局。PDS 的值按原始文本展示，EMV/ICC 数据按原始 TLV 十六进制展示，不解释任何卡组私有子域名称。Visa BASE II、CTF 及其它卡组的结算格式不包含在内：这些布局没有公开授权的来源，硬猜比不做更糟。
字段定义和解析规则遵循 Anthony Delosa 的 cardutil（MIT 许可）。本页是同一套公开规则的独立浏览器端实现。