Excel CountIF函数中的错误

我对Excel中的CountIf函数有问题

=COUNTIF(A:A,A2)

A列由以下项目组成：

0107791489614255200011140926107503100513

0107791489614255200011140926107503100457

0107791489614255200011140926107503100518

0107791489614255200011140926107503100503

0107791489614255200011140926107503100519

0107791489614255200011140926107503100444

0107791489614255200011140926107503100521

0107791489614255200011140926107503100438

0107791489614255200011140926107503100449

0107791489614255200011140926107503100443

0107791489614255200011140926107503100501

0107791489614255200011140926107503100455

公式的结果是12，尽管这组字符串实际上并不完全相同。它将这些字符串计算为类似的字符串，我认为这与它的字符串长度有关

---

你们觉得怎么样？我感谢你的帮助

+1，一个好问题。不是一个bug，而是一个特性

这是因为Excel隐式地将输入转换为其内部数字类型，这样做会丢失精度。Excel的内部数字类型是IEEE浮点双精度数字。（尽管它在格式化和错误传播方面做了一些巧妙的事情，所以它似乎得到了像1/3+1/3+1/3这样的正确的总和）

因为它们如此相似，所以它们彼此比较都是平等的

---

一种补救方法是在每个字符串前面加上

”

（单引号），这将阻止转换为数字类型。然后

COUNTIF

值返回1。（至少在我的Excel版本中是这样的；2013）。

在字符串前面加一个撇号并不能纠正这种情况。COUNTIF旨在尽可能地将数据解释为数字，而不考虑所讨论的值的数据类型。这有时是有用的，有时（在这里）不是

SUMPRODUCT不显示此属性：

=SUMPRODUCT(0+($A$1:$A$12=A2))

将根据需要返回1

---

关于

它的版本14.0.7128.5000I强烈建议不要使用只包含数字的ID。正如您所看到的，它们存在一些问题，因为它们经常会进入数值上下文，而它们本不应该进入数值上下文。这不仅在计算中，而且在数据传输中。如果他们以一封信开头，那么这些问题就不会发生。我刚试过，但还是不行。我甚至试图更改格式，使其仅作为文本读取，但仍返回12。在每个字符串前面加上单引号。它将在所有版本的Excel中工作（当然是从Excel97开始）。这整天都在烦我。让我们把数字累加起来。将列表的大小减少到2。将位数减少一半，直到它起作用。然后介绍单引号。看看什么时候休息。请记住，

COUNTIF

中最不可能出现错误。Excel开发人员确实有单元测试和回归测试。它在第19位细分。。我能做些什么吗？+1，关于COUNTIF的好建议-尽管它对Excel2013有效。啊，抱歉。有趣。也许你可以在你的回答中明确这一点？我能问一下你对此的专家意见吗？我使用了SUMPRODUCT函数，其思想是宏用这个SUMPRODUCT函数填充单元格，现在它大大减慢了我的宏。当我试图删除它时，我的宏又变快了。是的。COUNTIF（S）/SUMIF（S）可以接受整列作为参考，而不会对性能造成重大损害，例如，SUMPRODUCT和CSE公式在这种情况下会受到影响。