前言
翻了下，确实没有
VB/VBA提供了诸多大小写功能，但唯独没提供翻转大小写，这是为何呢？因为使用场景太稀薄。但翻转大小写，对于字符而言，并不会丢失信息，但数据却变了（当然是针对英文字符），因此在编码领域，比如加解密，还是很有用处的。
既然VB/VBA没有提供现成货，那就只有自己实现了。这时候，Mid，Chr和连字符（&）组合拳就是必不可少的了。
一、现有组合拳实现
和网上或AI写的，还是有明显的质量优势
一般情况下，也就这么个思路，功能上绝对没问题。但是，前面《VB/VBA的连字符&明明是最快的，却背了最慢的锅！》中给大家讲了，虽然连字符&拼接字符串很快，但是“=”暗含的数据深拷贝，将这一优势给完全遮盖了。
更何况《VB/VBA中，Asc虽好但并非没有代价，最终还得另寻他法！》中也测试了Mid这类字符串函数，一样存在"="的问题。功能上尽管可以实现，但性能却差强人意，难堪写算法用的“砖石”大任。这一点，在后面的性能比较时，可以体现得非常明显。当然，就低频用用，就无所谓了。
二、用扩展运行时中的“材料”来实现
在《内置VB/VBA字符指针函数，让字符处理快到飞起！》中，给大家介绍了字符指针函数，StrByte和StrInt。它不像Mid函数，只能读，不能写。所以，就避免了字符串数据的叠罗汉，从而大幅提高性能。
扩展运行时，可以自举
扩展运行时中，有上千例类似StrInt这样的高效函数，用户完全可以用它们构建高性能VB/VBA专用COM库，当然也可以给其他语言，比如vbs，JScript，JSA，Python等提供高性能库。
下面来比较二者实现的效率：
传统方法慢不慢，得看比较
比较下，扩展运行时的性能效果就出来了
从测试来看，扩展运行时的实现性能几乎是传统方法的10倍了。因此使用扩展运行时来构建VB/VBA代码，性能提速几倍则是轻轻松松。
VB/VBA本身提供的功能，性能也并不差，很多都是接近C/C++的70%-90%左右。而扩展运行时，是GASM对象（详见《VB/VBA扩展运行时的进展介绍》）用汇编自举，在接入大模型AI提供的优化方案后，很多都比肩甚至超越了非精通C/C++人士用C/C++实现的库。
因而，扩展运行时，完全可以胜任VB/VBA写算法实现程序。并用于实现小而精悍的各类应用，在AI加持下（后续文章会介绍），有广阔的应用前景。这在其他动辄上x个G环境大小的今天，VBA的开箱即用和VB6的小巧，着实算是一股清流了。
三、用户可直接用GASM对象扩展性能更强悍的功能
用扩展运行时的GASM对象直接用汇编实现上述功能，并给予CaseRev标签，类似于函数名(持久化为二进制代码后就会变成全局函数名)，因具体内容涉及汇编，就不细说了，直接看测试过程和结果：
看，性能还能翻，是传统方法的20倍以上
这个性能够恐怖了吧，这还是在i5第1代低电压CPU上的表现（本本已经快10年工龄了）。所以说，对于一个Native语言，不要轻浮地说它这也不行那也不行，否则终归是自己不行！VB/VBA有GASM的加持，就已经跟语言无关了，再配合GTLB对象（可接管内存中的类型系统），那感觉真是妙啊！