校验码是怎么算出来的：身份证、统一社会信用代码与条形码

录入一串号码，系统立刻提示「格式有误」——它并没有去数据库查，只是算了一下校验码。身份证末位、统一社会信用代码末位、商品条形码末位，都是这个思路：前面是信息，最后一位是用来防手滑的「验钞水印」。

一、身份证 18 位：最后一位为什么可能是 X

18 位身份证号的结构是：6 位行政区划码 + 8 位出生日期 + 3 位顺序码（其中第 17 位奇数为男、偶数为女）+ 1 位校验码。校验码按 GB 11643 规定的算法生成：

1. 前 17 位分别乘以固定权重：7,9,10,5,8,4,2,1,6,3,7,9,10,5,8,4,2；
2. 乘积求和，再对 11 取模；
3. 按余数 0~10 对照映射 1,0,X,9,8,7,6,5,4,3,2 得到末位。

余数恰好为 2 时末位就是 X——它是罗马数字 10 的写法，为了让号码保持 18 位，不是字母随意替换。所以「X 必须大写、不能写成 x 或 10」是格式校验的常见规则。

这个算法能挡住绝大多数输错一位的情况，但它只验证内部自洽，不能证明号码真实存在、也不能证明归属某人——真伪核验需要权威渠道。

二、统一社会信用代码：18 位里的另一套规则

企业的「身份证」是 18 位统一社会信用代码，按 GB 32100-2015 编码：第 1 位是登记管理部门代码，第 2 位是机构类别，第 3~8 位是行政区划码，第 9~17 位是主体标识号（组织机构代码），第 18 位是校验码。

校验码同样由前 17 位加权求和取模得出，但权重与字符集和身份证不同（使用 31 个数字与大写字母组成的字符集，去掉了容易混淆的 I、O、Z、S、V）。用校验工具核验时，还能顺带解析出登记管理部门、机构类别和行政区划——对账、开票、供应商资料核查前先过一遍，能拦下大量录入错误。

三、条形码与批量格式校验

一维条形码（CODE128、CODE39）也自带校验位。CODE128 用 mod 103 校验：把每个字符的值乘上位置权重求和取模；CODE39 用 mod 43。扫码枪读出的每一位都会参与校验，所以污损、错印导致的误读基本会被直接拒绝，而不是读出一个错号。

日常更常见的需求是「给我一整列数据，告诉我不合法的在哪」。批量格式校验工具一次处理邮箱、手机号、URL、IP、身份证、日期等 8 类常见格式，逐行标出合法与错误行号及原因，还能一键复制有效项或错误清单——比写正则脚本快得多。

四、常见问题

问：校验通过就说明这个号码是真的吗？
不是。校验码只防止录入错误，随便编一个自洽的号码也能通过。真实性要靠权威系统核验。

问：身份证里的 X 输入小写为什么报错？
标准写法是大写 X，多数校验实现严格区分大小写。统一转成大写再验即可。

问：批量校验会上传我的数据吗？
本站工具全部在浏览器本地计算，号码不上传服务器，处理客户名单、员工信息时更放心。

五、一条实用工作流

1. 拿到名单先跑一遍批量格式校验，把错误行号导出发回补录；
2. 身份证、信用代码类字段再做专项校验，顺手核对解析出的地区与日期是否合理；
3. 需要贴标签或资产编号时，用条形码生成器批量生成，扫码即录，减少二次手输。

校验码是成本最低的数据质量防线：一行算法，挡住九成的手滑。把这组工具收进书签，录数据的活儿会轻松很多。