有人存身份证号时丢掉最后一位吗

[iseki]

最后一位校验位去掉，剩下的部分按数字存 int64 理论上没问题，有人考虑这么干吗

[oneisall8955]

读出来那还要算一下？查找时候呢

[imicksoft]

按身份证算法，知道前面的，最后一位可以算出来

[IvanLi127]

数字的话，模糊匹配会不会很蛋疼。还有就是，怕领导哪天想着去掉校验，允许存错的可咋整

[wxf666]

其实 int64 可以完全存下，包括校检位在内的，完整身份证号：

1. 用 ⌈ log2(10^17) ⌉ = 57 位来存前 17 位数字
2. 用 ⌈ log2(11) ⌉ = 4 位来存校检位

还剩 64 - 57 - 4 = 3 位空闲


或者，校检位视为两位数（那么身份证就是 19 位），刚好可用 ⌈ log2(10^19) ⌉ = 64 位存下

[eason1874]

别整花里胡哨的，CPU 比硬盘内存贵多了，用空间换时间是最有性价比的

[janus77]

可以但没必要
少一位数字能省多少磁盘啊

[Kinnice]

有没有可能用户输得是错的

[iseki]

@oneisall8955 @IvanLi127 如果是字符串正则查找，那确实是不行了，不过我没见过这种场景；允许存错误的身份证号这就没办法了🤣除非在一开始明确提出我不会考虑这种需求

@wxf666 可以是可以，主要会不直观，如果只是简单去掉最后一位，不影响以十进制方式阅读

@janus77 主要是便于用数值而非字符串类型存储，19+字节变成定长 8 字节吧，我觉得对于某些量大的场景还是很划算的。

@eason1874 只有在系统边界将身份证号类型装换成字符串类型传输的时候才需要计算和补足最后一个校验码，校验算法非常简单，所以应该不会消耗过多的 CPU

[iseki]

话说大家真的有遇到过身份证号模糊匹配的需求吗，这点有些好奇，我确实没见过…

[wxf666]

@iseki

> 可以是可以，主要会不直观，如果只是简单去掉最后一位，不影响以十进制方式阅读

那『校检位视为两位数（那么身份证就是 19 位）』适合你啊。比如：

- 123456789012345678 会存储为：1234567890123456708
- 12345678901234567X 会存储为：1234567890123456710

[iseki]

@wxf666 视为两位十进制数这点我没想到，我光考虑前面那种了🤣

[iseki]

@wxf666 还是不行，很多地方不便于使用 无符号数，那么实际上可用的值最大只有 2^63 ，溢出了

[GuuJiang]

强烈反对这样做，并不是所有看起来由 0-9 组成的东西都是数字，身份证号、银行卡号、学号等本质是“数码”而不是“数字”，对这类“数字”进行数学运算是没有任何意义的，可能存在的运算是作为字符串运算(因为现实当中制定数码时通常会让某一段具备某种含义)，讽刺的是，哪怕微软都在犯这种低级错误

[wxf666]

@iseki 那就正负号代表校检位是否不为 X 呗。。比如：

- 123456789012345678 会存储为：123456789012345678
- 12345678901234567X 会存储为：-123456789012345670

需要使用 1 位符号位 + ⌈ log2(10^18) ⌉ = 1 + 60 = 61 位

[iseki]

@GuuJiang 换一个思考方式会不会好一点：我只是借用了一个 64bit 的数据类型（这个类型很常见）并没有把它当作数值进行计算，实际上这也没有意义；
而所谓的字符串也好，我这种做法也好，实际上都是身份证号的一种编码方式，相对于 144bit 更加节省而已～

[janus77]

@iseki #8 没那么多吧……按你这样算，就算我每个身份证号可以减少 10 个字节，15 亿个也就减少十几个 G ，不知道算对了没？

[iseki]

当然，程序内部往往不存在借用类型的需要，这种情况应该创建一个正常的「身份证号」数据类型，我所谓的「借用」更多时候指在 SQL 数据库中，有些数据库不能方便的创建类型别名或者增加自定义类型

[iseki]

@janus77 的是，其实一共也没多少

[iseki]

得···打错了···的是 -> 是的

[dcsuibian]

身份证号存数字。。。来个模糊搜索看看