excel字符集_当Excel对你说，你看到的，未必就是真相！你会想到什么？-CSDN博客

本文链接：https://blog.csdn.net/weixin_42347739/article/details/112104986

小伙伴们好啊，我是流浪铁匠，咱们又见面了。今天先给大家介绍1个简单的SUM公式：

惊不惊喜，意不意外，据说看到这个公式的第一印象有99%的小伙伴说是PS的。然而，这个公式当然是真的，这个效果是用Excel的字体和格式共同作用实现，并利用了Excel的特殊字符与SUM函数参数性质。今天介绍的就是一些大家以为是假的，但其实是真实结果的公式。 1，LEN函数与LENB函数 很多人对LEN函数与LENB函数的结果差异为： LEN对双字节字符的结果是1，而LENB对双字节字符的结果是2 然而，下面几个公式可能会颠覆你对这两个函数的认识：

第1个公式，原因是₧是一个特殊字符，并不是习惯上的PTS 3个字符，EXCEL里UNICODE字符集上百万个字符你并没有全部见过第2个公式，原因是，你们熟悉的LEN对单字符结果为1，是仅针对UNICODE编码小于65536的字符的，UNICODE编码大于65535的字符，LEN函数结果全部是2 (之所以通常认为LEN结果为1，是一般情况下你们碰不到UNICODE编码大于65535的字符) 第3个公式最常见，因为LEN与LENB的性质差异只在支持DBCS的语言(中文简体/中文繁体/日文/朝鲜文)下才有效，在英文等其他语言下LEN函数与LENB函数是没有差异的，这个截图公式其实就是在默认语言为英文时写的。 2，MID的拆分重组能力 从字符性质来说，MID和LEFT/RIGHT是完全不一样的函数，不信的话看下这2个公式：

(不要纠结字符本身因为我也不认识……) 公式里出现的3个字符都是UNICODE编码大于65535的，那个字符只是很像”二”(我故意找的这个字符误导你们

)

测试证实，MID的提取对UNICODE编码大于65535的字符，其结果为编码并可以实现字符的编码重组，然而LEFT与RIGHT只能按整个字符进行提取。这个结果也间接说明了LEN对UNICODE编码大于65535的字符结果为2的原因，这类字符的编码量是普通字符的2倍。 3，指鹿为马 经常能碰到自称精通VLOOKUP的同学，然后我都会发这个公式出来问原因，然后就没有然后了

。

其实很简单，Excel在忽略大小写性质下认为A2和A4的2个字符是一样的。

这是绝大多数人的一个误区，Excel并不是只有A和A这种英文的大小写在一般判断下被视为相同。

由于Excel所谓大小写性质，能被等号或者支持通配符的函数相互识别的字符组大约有1835组，除了英文字母外很多语种乃至特殊字符与少数汉字都是存在的。在识别大小写的环境下请注意这个性质，因为不同的工具对大小写的识别存在差异。

上图中，C列是针对A列用SQL去重，E列是针对A列用PQ去重二者存在识别差异，PQ严格识别EXCEL环境定义的大小写差异，而SQL并没有识别英文字母的大小写。 4，信不过的等号 很多时候用等号判断2个单元格内容是否相同。上面已经提到了，少数特殊字符用等号判断是相同的，但是，除了上述情况外还有几种情况会造成统计或匹配异常。 1)支持通配符的函数遭遇长字符串支持通配符的函数的局限之一是，字符串长度不能超过255。 2)看不到的浮点数这个性质在之前文章介绍过，不赘述，原因在于EXCEL的浮点精度高于15位。

这种高于15位的数值精度误差需要使用DELTA函数检查，且MATCH/RANK/VLOOKUP/FREQUENCY等函数是能识别这种差异的，重点是这种差异会影响这些函数的结果。

3)极少数特殊字符

这些情况下均会造成等号的比较结果为相同，但公式统计或者查找下结果异常。以上都是因为EXCEL的一些特殊机制造成的特殊结果，大家一般碰不到，但是一旦遭遇都会成为陷阱。当然看到现在很多人等待的是SUM画画的真相。

首先， SUM的参数是忽略引用与数组内的文本型数字的，但会把作为常量的文本型数字(或可被识别的表达式)也进行计算。文章开头的公式里的常量数组内的文本字符串内容无关，整个常量数组结果为0，真正需要的就是后面那段类似乱码的字符(因为那才是SUM函数能识别出来的数字) 整个SUM公式的目的只是为了返回一个指定数值：