号码校验

功能

• ⚠️ 页面第一行就写明「校验位通过 ≠ 号真实存在」，每一行结论也只说「校验位通过」而不是「有效」
• Damm 与 Verhoeff 两种算法（可选开启）—— 它们能挡住 Luhn 挡不住的相邻换位
• 中国公民身份号码（ISO 7064 MOD 11-2，末位可为 X）
• EU VAT 格式校验，覆盖 27 个成员国；⚠️ 只查格式，查不了「这个号存不存在」
• 银行卡：Luhn 校验位 + 按 IIN 号段识别卡组织，号段与长度不符时单独标出来
• IBAN：ISO 7064 MOD 97-10，容忍空格与小写；各国长度不同（挪威 15 位、马耳他 31 位）都能处理
• ISBN-10（末位 X 记作 10）、ISBN-13 / EAN-13、UPC-A，并标出 978/979 前缀是图书
• ABA 路由号（加权 3-7-1），并注明「通过只说明符合算法，不说明是某个真实的银行号」
• BIC / SWIFT：只有格式可查 —— 它没有校验位，这一点在结论里写明
• 比特币地址分四类判定：Legacy（`1` 开头，P2PKH）、P2SH（`3` 开头，多签 / 嵌套 SegWit）、SegWit v0（`bc1q`）与 Taproot（`bc1p`），并说明这几类不能混用
• 比特币的 Bech32 与 Bech32m 两套常量分别试，报出用的是哪一个；校验和错的那一版会被判不通过
• 以太坊：EIP-55 大小写校验和，用 Keccak-256；全小写或全大写时明确说「无法校验」而不是「不通过」
• ⚠️ 一个输入可能同时属于多种（9 位数字、13 位数字都如此），所以给的是列表而不是一个断定
• 一次贴多行，按行分组

使用方法

1. 把要校验的号码粘进去，一行一个
2. 看「结论」那一行：通过 / 不通过 / 只核对了格式 / 无法校验
3. 看「依据」了解它是按哪一套算法判的

常见问题

校验通过了，说明这个卡号是真的吗？

不说明。 校验位是用来挡录入错误的：少打一位、两位数写反、按错键，这些有九成会被 Luhn 抓出来。但它完全挡不住编造 —— 骗子编卡号时会把 Luhn 算对，这是一步除法的事。所以「通过」只等于「这一串没有明显的抄写错误」，与这张卡是否存在、属于谁、能不能用都无关。

为什么以太坊地址要用 Keccak-256 而不是 SHA3-256？

因为以太坊早于 SHA-3 标准化。它们只差填充的第一个字节（Keccak 原版是 `0x01`，NIST 的 SHA-3 是 `0x06`），但输出的每一位都不同。用 SHA3-256 去算 EIP-55 的校验和，结果是每一个正确的地址都验不过 —— 而两者看起来都是「哈希」，不会有任何报错。测试里用 EIP-55 规范给出的三个样例地址钉住了这一条。

为什么全小写的以太坊地址「无法校验」？

因为 EIP-55 的校验和就藏在大小写里：算出 Keccak-256 之后，哈希对应位 ≥ 8 就把地址那一位大写，否则小写。所以全小写或全大写的地址根本没有携带校验信息 —— 而这两种写法在 EIP-55 之前都是合法的，很多工具至今这么输出。报「不通过」会让你以为地址是错的；报「无法校验」才是实话。

BIC 为什么只给「格式正确」？

因为 BIC 没有校验位。它由 4 位机构码、2 位国家码、2 位地区码和可选的 3 位分行码组成，全都是查表得到的字母数字，没有任何用于自检的位。所以工具只能核对「长度对不对、各国码是不是字母」，核对不了这个码存不存在 —— 结论里写明了这一点，免得「格式正确」被当成「验过了」。

比特币地址的 `1`、`3`、`bc1q`、`bc1p` 有什么区别？能混用吗？

它们是四代不同的地址格式，签名方式不同、互不兼容。`1` 开头是 Legacy（P2PKH），最早的一代；`3` 开头是 P2SH（脚本哈希，常见于多签与嵌套 SegWit）；`bc1q` 开头是 SegWit v0（P2WPKH / P2WSH）；`bc1p` 开头是 Taproot（SegWit v1）。它们都通过各自的校验和校验 —— Base58 那两类靠版本字节（`0x00` / `0x05`）加双 SHA-256 的 4 字节校验和，bech32 那两类靠 Bech32 / Bech32m 校验和（两者只差最后异或的常量）。⚠️ 不能混用：把 `1` 或 `3` 开头的地址交给只认 bech32 的交易所会直接判为无效，反之亦然 —— 收款前要用对方支持的那一代格式。