IBAN生成器测试_结构拆解与mod-97校验

使用方法

在国家／地区下拉框选一个（默认 DE 德国（22 位）），括号里的数字是该国 IBAN 的总长度，长度由 ISO 13616 登记表固定，不能自选。
在生成数量填 1～50 的整数，默认 5 条。
按 Enter 或点「生成 IBAN」。结果区给出按每 4 位分组的号码，例如 DE89 3704 0044 0532 0130 00，每条都自带正确的 mod-97 校验位。
看结果区下方的mod-97 自检：显示「全部 = 1」说明本次生成的每一条都通过了 ISO 7064 MOD 97-10 校验；若有任何一条不等于 1，说明生成逻辑出错。
把要核对的号码粘进校验单个 IBAN 框（默认就是那条公开测试号），按 Enter 或点按钮，结果框会给出「有效」或具体原因（长度不符、mod-97 不等于 1、含非法字符等）。

这个IBAN生成器测试能解决什么问题

一是给开发和测试造数据。写支付、对账、Swift 报文相关的程序时，测试库里需要一批「结构合法但不指向真实账户」的 IBAN。手工编的号码十有八九校验位是错的，校验函数一测就红；用本页生成，校验位是用同一套 mod-97 公式算出来的，能确定地通过格式校验。

二是反向核对别人给的号码。收到一份号称来自海外的 IBAN，先看长度对不对、再看 mod-97 是不是 1，十秒钟就能筛掉绝大多数手抄错误。mod-97 能挡住的是「打字打错一位」这类错误，挡不住整段伪造——这一点后面会讲清。

三是理解 IBAN 到底由什么组成。很多人把 IBAN 当成一个长长的账号，其实它是「2 位国家码 + 2 位校验位 + 国家自定的 BBAN」三段。拆开之后，做界面校验、填正则、写数据库字段长度时就知道该约束哪一段。

四是给文档和截图准备脱敏样例。产品文档里需要展示 IBAN 的示例，用真实号码有泄露风险，用本页生成的测试号既格式正确又不对应真实账户，还标注了「仅测试」。

这个IBAN生成器测试不做真实转账、不做账号归属查询，也不验证账户是否存在——IBAN 的校验位只证明「号码自身没打错」，不证明账户存在。要校验银行卡号的 Luhn 校验位请用「银行卡号校验」，要生成 SWIFT/BIC 代码请用「虚拟SWIFT代码生成器」。

原理与规则说明：IBAN 三段结构与 mod-97 算法

结构：IBAN = 2 位国家码 + 2 位校验位 + BBAN。国家码取 ISO 3166-1 alpha-2（DE、GB、FR…）；校验位是两位数字 00～98；BBAN（Basic Bank Account Number）由国家自定，长度和字符集都不一样，德国是 18 位纯数字，英国是 18 位字母数字混合，爱尔兰的 BBAN 前四位是银行代码字母。所以 IBAN 总长只由前两位决定：DE=22、GB=22、FR=27、NL=18、ES=24、IT=27、CH=21、BE=16、AT=20、IE=22、PL=28、AE=23，范围从 15 位（NO 挪威）到 34 位不等。

校验算法：ISO/IEC 7064 MOD 97-10。三步：① 把 IBAN 的前四位（国家码 + 校验位）整段搬到字符串末尾，得到 BBAN + 国家码 + 校验位；② 把所有字母按 A=10、B=11 … Z=35 换成一到两位的数字，得到一串纯数字；③ 对这串数字整体取模 97，结果必须等于 1。示例 DE89 3704 0044 0532 0130 00 去空格后重排成 370400440532013000DE89，字母替换后是 370400440532013000131489，对 97 取模恰好等于 1，所以它有效。

校验位怎么算出来。生成时反过来用同一个公式：把 BBAN 后面拼上国家码和占位的 00，即 BBAN + DE + 00，对这串取模 97 得到 m，校验位就是 98 − m；若结果小于 10 就补一个前导零。以德国示例的 BBAN 370400440532013000 为例，mod97(370400440532013000DE00) = 9，于是校验位 = 98 − 9 = 89，组装出 DE89…。这正是本页默认示例的来历。

为什么用 97 这个模数。校验位只有两位数字（00～98），要能检测出「单个数字打错」「相邻两位写反」这两类最常见的抄写错误，模数必须与 10 互素且足够大。97 是小于 100 的最大素数，能覆盖 00～98 全部取值，且对调位、单字符错位的检出率接近 100%（这类系统叫 ISO 7064 混合系统，同一套规则也用在中国的统一社会信用代码里）。

大整数怎么取模。IBAN 替换字母后最长会到 30 位以上数字，超出 JavaScript 安全整数范围，所以不能直接 parseInt 再取模。本页用逐位累乘：r = (r * 10 + 当前数字) % 97，一位一位滚动，永远只处理小于 97×10 的值，既不丢精度也不需要 BigInt。

完整示例（数值仅作演示）

与页面打开时的默认值一致：国家 = DE（德国，22 位），生成数量 = 5 条，校验框 = DE89 3704 0044 0532 0130 00。IBAN生成器测试给出的下面每一个数字都由复算脚本实测，不是手写的：

德国示例的 BBAN 是 370400440532013000（18 位）；
mod97(370400440532013000 + 'DE' + '00') = 9，故校验位 = 98 − 9 = 89；
组装后 DE89 3704 0044 0532 0130 00，总长 22 位，重排取模 = 1，判定为有效；
把末位 0 改成 1，重排取模变成 28，判定为无效——只错一位就会被挡下；
删掉末位后总长变成 21 位，长度检查先于 mod-97 报错；
把国家码写成 ED，重排取模变成 7，同样无效；
另取英国公开测试号 GB82 WEST 1234 5698 7654 32，模数结果也是 1，可作为交叉验证。

下表是 18 个国家的长度与示例（示例均为按公式生成的测试号，仅 DE/GB 两条为公开标准示例）：

国家码	IBAN 总长	BBAN 长度	示例（测试）IBAN	mod-97
DE 德国	22	18	DE89 3704 0044 0532 0130 00	1
GB 英国	22	18	GB82 WEST 1234 5698 7654 32	1
FR 法国	27	23	FR14 2004 1010 0505 0001 3M02 606	1
NL 荷兰	18	14	NL91 ABNA 0417 1643 00	1
ES 西班牙	24	20	ES91 2100 0418 4502 0005 1332	1
IT 意大利	27	23	IT60 X054 2811 1010 0000 0123 456	1
CH 瑞士	21	17	CH93 0076 2011 6238 5295 7	1
BE 比利时	16	12	BE71 0961 2345 6769	1
AT 奥地利	20	16	AT92 1904 3002 3456 7890	1
IE 爱尔兰	22	18	IE29 AIBK 9311 5212 3456 78	1
PL 波兰	28	24	PL35 1090 1001 0000 0000 0000 0012	1
AE 阿联酋	23	19	AE07 0331 2345 6789 0123 456	1
PT 葡萄牙	25	21	PT50 0002 0123 1234 5678 9015 4	1
SE 瑞典	24	20	SE83 5000 0000 0005 6789 0123	1
DK 丹麦	18	14	DK56 0040 0440 0123 45	1
NO 挪威	15	11	NO93 8601 1117 947	1
FI 芬兰	18	14	FI21 1234 5600 0007 85	1
TR 土耳其	26	22	TR29 0006 1000 4310 5167 2485 13	1

输入范围与对照表

各字段的范围与填错时的动作，右列是结果区会显示的具体提示：

字段／情况	允许范围	超限或填错时的动作
生成数量	1～50 的整数	空值、0、负数、超过 50 均拒绝，并报出当前填的值与允许区间
生成数量为小数	不接受	提示「必须是整数条」，不四舍五入代替用户决策
国家码	下拉框内 18 项	只能选预设项；无该国家长度信息时拒绝并提示「未收录该国家长度」
校验输入为空	必填	提示「校验框为空」，不静默返回「无效」
校验输入含非法字符	只允许 A-Z 0-9 与空格	报出第一个非法字符及其位置，例如「第 5 位出现 `$`」
长度不符	按国家码固定	先于 mod-97 报错，给出「应为 N 位、实际 M 位」
mod-97 不等于 1	必须为 1	报出实际模数，例如「结果 = 28」

两种校验手段能挡住什么、挡不住什么，容易混淆，单独列一张表：

检查项	能发现	不能发现
长度检查	漏抄、多抄、少一位	位数对但内容错
mod-97 校验位	单字符抄错、相邻两位写反	整段被伪造、账户是否真实存在
国家码前缀	不属于 ISO 3166 的两位字母	国家存在的账户结构差异（各 BBAN 规则不同）

输入范围、边界与精度说明

每个国家只有一种合法长度。长度不是本页的自由参数，而是查表得到的常量。德国 22 位、法国 27 位都是登记表规定，多一位少一位都直接判无效，不存在「差不多就行」。
字符集随国家变化。德国、法国、荷兰等 BBAN 是纯数字；英国、爱尔兰、意大利的 BBAN 含大写字母。本页生成德国等纯数字国家时只用 0～9，生成 GB/IE 时才引入字母，避免造出「形式上不是该国风格」的号码。
字母替换 A=10…Z=35 是固定的。有人误以为要先做 Base36 或按 ASCII 减 55 之外的处理，其实 ISO 7064 规定的就是十进制拼接：DE 变成 1314、GB 变成 1611。顺序必须是「先重排再替换」或「先替换再重排」二者等价，但不能只替换不重排。
大整数用逐位取模。重排替换后最长可达 30 位以上数字，超过 Number.MAX_SAFE_INTEGER（9007199254740991，约 16 位），直接转数字会丢精度导致校验结果随机漂移。本页用 r = (r * 10 + d) % 97 滚动取模，结果与任意精度整数完全一致。
校验位范围是 00～98。没有 99：因为 98 − m 中 m 取值 0～96 时得到 98～2，m 不会让结果为 99。这也是为什么校验位永远两位数、且第一位可能是 0。
空格与大小写会被规范化。输入里的空格、制表符一律剥掉，小写字母转成大写后再校验，因为 IBAN 打印时按每 4 位分组、书写时也常小写。规范化只影响比对，不影响号码本身。
长度上限带来的性能边界。批量生成上限 50 条，最长 34 位（英国部分结构）时也只是几毫秒的循环，不存在卡顿；把上限放到几千条也很快，但截图上没有意义，故限制在 50。
生成结果不是「真账户」。本页只用随机数造 BBAN，再用公式补校验位，因此号码能通过格式校验，但对应的银行、分行、账户通常不存在。仅供测试。

常见问题

校验通过是不是说明这个 IBAN 真实存在？

不是。mod-97 只验证「号码本身有没有抄错」，它是一道校验位算术，任何按公式拼出来的号码都能通过。伪造者只要改了 BBAN 再重算校验位，同样能造出「校验通过」的号码。所以校验通过只能排除手抄错误，账户是否存在必须由银行系统查询。这也是本页强调生成结果仅供测试的原因。

为什么德国的 IBAN 是 22 位、挪威只有 15 位？

因为 BBAN 的长度由国家自己定。IBAN 总长 = 4 + BBAN 长度，德国 BBAN 18 位得到 22，挪威 BBAN 11 位得到 15。各国银行体系的历史结构不同，ISO 13616 只是把长度登记下来统一约束，并不强求一致。做法是「先读国家码，再按登记表取长度」，不能用一个固定正则套所有国家。

国家码写反了（比如 DE→ED）会怎样？

会直接被判无效。示例里把 DE89… 写成 ED89…，重排取模得到 7 而不是 1。因为国家码参与了字母到数字的替换，顺序一变整串数字就变了。顺带一提，ED 也不是 ISO 3166 登记的国家码，两层检查都会拦住它。

为什么不能只算校验位、跳过长度检查？

能过 mod-97 的号码仍然可能长度不对，比如把德国号码少抄一位后凑巧重算校验位。长度检查成本极低、能挡掉一类错误，所以本页把它放在 mod-97 之前执行：先看总长对不对，再看模数是不是 1，最后才给「有效」。报错时也会分别说清是长度问题还是校验位问题，避免只给一句「无效」。

生成器用随机 BBAN，会造出重复号码吗？

理论上可能，但概率极低：德国 BBAN 有 18 位数字，随机空间约 10¹⁸，一次生成 50 条撞号的概率可以忽略。对测试数据而言即使重复也无妨；若你的用例要求全局唯一，生成后按字符串去重即可，本页不做去重是因为那会掩盖生成逻辑本身的正确性。

BigInt 能做吗，为什么本页没用？

能做，BigInt 对任意长度整数都精确。但纯数字逐位取模不需要大整数，几十位以内的取模用 r = (r * 10 + d) % 97 一行就够，且兼容所有浏览器、不引入大整数对象的内存开销。只有在需要做大量大数运算（比如金融精算）时才值得引入 BigInt。

和 SWIFT/BIC 代码是什么关系？

两者是跨境汇款里的两个不同标识：IBAN 标识「收款人的哪一个账户」，通常 15～34 位、含国家码与校验位；BIC（也叫 SWIFT 代码）标识「哪家银行/分行」，固定 8 或 11 位字母数字。一笔汇款常常同时需要两者。本页只管 IBAN，BIC 请用「虚拟SWIFT代码生成器」。

生成的号码能直接拿去测试真实接口吗？

可以用于测试你自己系统的格式校验、界面展示、CSV 导入等环节；但不要把它发给任何真实银行或支付网关当作有效账号。如果对接的是沙箱环境，优先使用该机构官方提供的测试 IBAN（例如 DE89 3704 0044 0532 0130 00 就是广泛使用的公开测试号），因为它们可能与沙箱里的虚拟账户绑定。

IBAN生成器测试