校验和的原理
银行卡号、IBAN、税号和加密货币地址都包含一个或两个隐藏的额外数字，这些数字是根据其他数字计算得出的。只要输错一个字符，算术关系就不再成立——这正是验证器能够即时离线标记输入错误的原因，无需向银行或区块链网络发起请求。
什么是校验和？
校验和（或称校验位）是刻意设置的冗余信息。一个数字在生成时，有一个或多个数字并非随意选定：它们是根据其余数字按照固定配方计算得出的。知晓该配方的人后续可重新计算这些数字并进行比对。若两者一致，说明该数字内部逻辑自洽；若不一致，则表明存在输入错误、读取错误或数据损坏情况。
校验和仅能保证这点而已。它无法说明账户是否存在、归属何人以及包含何种内容——本网站的所有验证器都会反复强调这一点，因为两者极易混淆。
实操示例1——Luhn算法，即银行卡号算法。
Visa、Mastercard及大多数其他支付卡均采用Luhn算法。以经典示例7992 7398 713为例：从最右侧数字开始，每隔一位的数字乘以2；若乘积为两位数，则将其各位数字相加。最后将所有数值求和。
| 数字 | 从右往左的位置 | 翻倍了吗？ | 计为 |
|---|---|---|---|
3 | 校验位 | — | 3 |
1 | 从右往左数第2位 | 1 × 2 = 2 | 2 |
7 | 第3位 | — | 7 |
8 | 第4位 | 8 × 2 = 16 → 1 + 6 | 7 |
9 | 第5位 | — | 9 |
3 | 第6位 | 3 × 2 = 6 | 6 |
7 | 第7位 | — | 7 |
2 | 第8位 | 2 × 2 = 4 | 4 |
9 | 第9位 | — | 9 |
9 | 第10位 | 9 × 2 = 18 → 1 + 8 | 9 |
7 | 第11个 | — | 7 |
右侧那一列的数字相加结果为 3 + 2 + 7 + 7 + 9 + 6 + 7 + 4 + 9 + 9 + 7 = 70。70能被10整除，因此该号码有效。只要改动任意一个数字，总和就不再能被10整除。你可以在信用卡校验上试试——它会在你的设备上执行完全相同的运算。
示例2：加权和算法（ISBN-10）
许多国家身份证号采用加权和算法：将每个数字乘以固定的权重，求和后再检查余数。ISBN-10是最清晰的示例。对于0-306-40615-2而言，权重从10递减到1：
0×10 + 3×9 + 0×8 + 6×7 + 4×6 + 0×5 + 6×4 + 1×3 + 5×2 + 2×1 = 132
132恰好等于11×12，因此模11的余数为零，该ISBN号码有效。巴西的CPF、波兰的PESEL以及数十种其他标识符都采用相同的模式，只是权重和模数有所不同——正因如此，一个批量证件校验能在1秒内校验数千个此类编号。
示例3：IBAN与模97算法
国际银行账号采用ISO 7064模97-10算法，这是一种包含两位校验位的更强校验方案。以标准示例GB82 WEST 1234 5698 7654 32为例：
- 先核对该国家的长度要求：英国IBAN的长度为22个字符。✓
- 将前四个字符移到末尾：
WEST12345698765432GB82。 - 将每个字母替换为两位数字（A=10…Z=35）：W→32，E→14，S→28，T→29，G→16，B→11，最终得到
3214282912345698765432161182。 - 将该数字除以97。余数必须恰好为1——实际情况正是如此。
由于97是质数且大于任意两位数字交换后的值，模97算法能检测出所有单字符错误和字符错位情况；只有约1/97的随机字符串能侥幸通过校验。IBAN 校验会分别展示每一层校验的通过或失败结果。
加密货币地址：基于哈希生成的校验和
比特币和以太坊地址对校验要求极高，因为一旦输入错误，资金会永久无法找回。旧版比特币地址（1…、3…）采用Base58Check算法：将地址内容经过两次SHA-256运算后，取结果的前4个字节作为校验和。只要有一个字符出错，哈希值就会完全改变，因此输入错误能被漏过的概率约为四十亿分之一。较新的bc1…地址采用Bech32或Bech32m算法，这是一种纠错码，能确保检测出涉及最多4个字符的任何错误。以太坊的EIP-55则将校验和隐藏在大小写字母的组合模式中。
方案概览
| 方案 | 应用范围 | 可捕获的错误类型 | 随机错误被漏过的概率 |
|---|---|---|---|
| Luhn算法（模10） | 信用卡与借记卡、IMEI码、多种国家身份证 | 所有个位数错误以及大多数相邻字符互换错误 | 约为十分之一 |
| ISO 7064 模 97-10 | IBAN、部分税号和公司编号 | 所有单个错误及所有字符错位情况 | 大约每97个数据中会有1个出错 |
| 加权求和，取模10或11 | ISBN-10、巴西CPF、波兰PESEL以及众多身份证件编号 | 单个错误及大部分字符错位情况 | 大约每10个或11个数据中会有1个出错 |
| Base58Check（双重SHA-256算法，4字节） | 比特币旧版地址（1…、3…） | 任何拼写错误几乎都会被检测出来 | 大约每40亿个数据中会有1个出错 |
| Bech32 / Bech32m（BCH 编码） | 比特币 SegWit 与 Taproot 地址（bc1…） | 可保证：任何错误最多只会影响 4 个字符 | 低于十亿分之一 |
| EIP-55（keccak-256 大小写规则） | 以太坊地址 | 拼写错误，源于大小写字母的组合规律 | 混合大小写输入时的出错概率极低 |
为何验证器应在你的设备上运行？
上述内容均是对你已有的数字进行的算术运算。验证器没有理由将卡号、税号或钱包地址发送至服务器——而且恰恰有充分理由不这么做。本网站上的所有验证器均在本地运行；离线工具列表对其进行了归类，我们的工具是否上传数据的检查指南则展示了如何在二十秒内确认任意网站是否符合这一要求。
常见问题
校验和有效是否就意味着该号码真实或可用？
并非如此。校验和仅能证明这些数字在内部是一致的——即该号码有可能存在。它无法告诉你账户是否开通、归属何人以及余额是多少。本网站上的所有验证器都会在页面上注明这一点，因为这一区别至关重要。
错误的数字仍能通过校验的可能性有多大？
这取决于具体的校验规则。单个 mod-10 校验位会让大约 1/10 的随机错误通过；IBAN 的 mod 97 校验规则会让约 1/97 的错误通过；4 字节的 Base58Check 校验和则会让约 1/40亿的错误通过。重要的是，常见的人为失误——比如输错一个数字、两个数字顺序颠倒——都能被这些规则检测出来。
为什么有些标识符根本没有校验和？
较旧或更简单的方案是为在注册表中查询而设计的，并非用于离线校验，而且有些编号系统出现的时间早于校验和的应用。针对这类情况，验证器只能检查长度和格式。
把我的卡号或身份证号粘贴到验证器中安全吗？
只有当校验在您的设备上运行时才安全。校验和是针对您已有的数字进行的运算，因此验证器没有正当理由将它们发送到服务器。您可以按照我们《检查工具是否上传您的数据》指南中描述的飞行模式测试方法，确认工具是否在本地运行。
校验和、哈希与加密有什么区别？
校验和是一种用于检测意外输入错误的简短校验位。加密哈希是一种较长的特征码，即便经过刻意修改也能被识别，且无法还原原始数据。加密会将数据转换，只有凭借密钥才能读取。Base58Check 利用哈希来生成校验和，这就是为什么它很难被意外伪造。