里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

excel的任何支持都很垃圾，比如我写个1-1他自动给我解析成一月一日，真是无语

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

18位的身份证号都不支持，会变成浮点数

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

你可以试试把身份证那一列拉宽一些，使它宽度足够显示18位？

kwot (¼©) 在 ta 的帖子中提到：

18位的身份证号都不支持，会变成浮点数

也不行，除非设为文本格式

holderoberts (HolderRoberts) 在 ta 的帖子中提到：

你可以试试把身份证那一列拉宽一些，使它宽度足够显示18位？

前面加一个英文单引号

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

你的需求不是Excel该干的，上数据库不好么。其他楼上几个人的问题，明明是自己不会用，不要说excel不好使

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

身份证号难道还需要做运算？

kwot (¼©) 在 ta 的帖子中提到：

18位的身份证号都不支持，会变成浮点数

是啊，要设置成本文才行，不然所有的身份证号后面全是四个0

kwot (¼©) 在 ta 的帖子中提到：

18位的身份证号都不支持，会变成浮点数

所以到底有啥需要参与运算的长整数是excel必须要支持的…不参与运算的它就是个字符串，参与运算的话你都处理这么高精度的整数了还用excel？

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

总是有那么些人，你说某个工具不好用，他说你不应该有这个需求。

用 excel 存身份证号是多正常的需求啊。

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

如果我没理解错的话，这帖子下面吵的架是一种认知范围差异导致的世界的参差

原主题其实想表达的含义从技术上讲并不是真正的长整型支持，而是excel在遇到长数字序列的时候会把它默认判定为数字而且是一种浮点类型，从而产生精度的丢失这个事情不科学。直接存文本不就好了？

楼上另有一位从纯技术角度来理解这个事情，认为excel本来就没必要支持精度特别高的长整数的支持。因为所谓的支持意味着要支持excel里能进行的运算，而要对真正意义上的长整型覆盖所有可能的运算并不是一个非常简单的事情。

本质上讲，这就是一个工具使用面太广之后一定会产生的问题。你以为你是主流用户，但开发者不认为你是主流用户。比如在这个例子里，开发者觉得遇到数字序列通常也不会特别大，就应该是数字类型从而能进行运算才是主流需求；况且其他需求你自己改类型不就好了。而用户觉得我平时日常处理一堆有精确含义的长数字序列数据（比如证件号），你每次都给我丢精度也太愚蠢了，就应该默认文本类型来满足我的需求。

到底谁对，我不好说，因为人的认知从来都是局部的……

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

所以存身份证号这个需求用文本格式无法满足吗？如果你想对身份证号进行运算那确实无法满足w

cloudnine (cloudnine) 在 ta 的帖子中提到：

总是有那么些人，你说某个工具不好用，他说你不应该有这个需求。

用 excel 存身份证号是多正常的需求啊。

记起来当初因为excel的功能，一些基因的名称还特地修改了来着，因为有些缩写会被识别为月份

from (random) 在 ta 的帖子中提到：

里面到底有啥核心技术难点呀，亦或是外国人的使用场景和我们有所不同？？

并没有不支持啊，其实就是不会。

先把身份证存成文本型的。

然后用left和right函数，就能取出来自己想要的部分了，想要地区信息，生日，校验位，都能取到。

取到的这部分信息就可以做运算处理了啊，有什么难的？

Aioi (伸手就扇笑脸人) 在 ta 的帖子中提到：

所以存身份证号这个需求用文本格式无法满足吗？如果你想对身份证号进行运算那确实无法满足w

输入长数字默认成文本了吗？

默认成数字然后对着数字搞一堆自以为是的显式模式真没问题？

用户既有长数字计算的需求，也有长数字文本的需求，那为什么不能把存储的数据类型以及显式方式优化一下呢？改成 int64，有 -2 << 63 到 2 << 63 - 1 的范围，或者直接用 decimal，显式的时候过长的部分直接像素截断，不比现在的强多了？拉一下宽度就变成科学计数法了，身份证号、手机号，还非得手动改成纯文本，不嫌麻烦吗？

Aioi (伸手就扇笑脸人) 在 ta 的帖子中提到：

所以存身份证号这个需求用文本格式无法满足吗？如果你想对身份证号进行运算那确实无法满足w

实际上的用户需求就是，把号码复制进去，里面能按照我复制进去的显式。

excel 如果不为了使用方便而设计，为什么不去用 python？

现在在线云文档那么多，腾讯、飞书、金山之类的，这些云文档的基础使用体验比 word、excel 一类的好太多了。

allgewalt (四金) 在 ta 的帖子中提到：

并没有不支持啊，其实就是不会。

先把身份证存成文本型的。

然后用left和right函数，就能取出来自己想要的部分了，想要地区信息，生日，校验位，都能取到。

……

现在处理文本类型的数字你这样搞，你让那些天天处理10位以上整数的数字的人怎么想？输进去之后还要手动改成数字类型，列宽稍微窄一点就只能看到前几位数字，连两个数字之间谁大谁小都看不出来了

cloudnine (cloudnine) 在 ta 的帖子中提到：

输入长数字默认成文本了吗？

默认成数字然后对着数字搞一堆自以为是的显式模式真没问题？

用户既有长数字计算的需求，也有长数字文本的需求，那为什么不能把存储的数据类型以及显式方式优化一下呢？改成 int64，有 -2 << 63 到 2 << 63 - 1 的范围，或者直接用 decimal，显式的时候过长的部分直接像素截断，不比现在的强多了？拉一下宽度就变成科学计数法了，身份证号、手机号，还非得手动改成纯文本，不嫌麻烦吗？

直接用 decimal，显式原本的数字就行了，别减精度，别自动改成科学计数法。

单元格从左往右显式前面的像素，从高位到低位自然能肉眼看出来，看不出来的也不是文本和数字类型的问题。

Aism (咸蛋皮卡丘流氓猪) 在 ta 的帖子中提到：

现在处理文本类型的数字你这样搞，你让那些天天处理10位以上整数的数字的人怎么想？输进去之后还要手动改成数字类型，列宽稍微窄一点就只能看到前几位数字，连两个数字之间谁大谁小都看不出来了

客户最基础的它支持了，想提高要求用vba，不要说你不会用，只会调库

cloudnine (cloudnine) 在 ta 的帖子中提到：

实际上的用户需求就是，把号码复制进去，里面能按照我复制进去的显式。

excel 如果不为了使用方便而设计，为什么不去用 python？

现在在线云文档那么多，腾讯、飞书、金山之类的，这些云文档的基础使用体验比 word、excel 一类的好太多了。