^ = 32背后的想法是什么，将小写字母转换为大写字母，反之亦然？

我正在解决代码部队上的一些问题。通常我首先检查字符是大写还是小写英文字母，然后减去或加上32以将其转换为相应的字母。但是我发现有人会^= 32做同样的事情。这里是：

char foo = 'a';
foo ^= 32;
char bar = 'A';
bar ^= 32;
cout << foo << ' ' << bar << '\n'; // foo is A, and bar is a

我已经搜索了对此的解释，但没有找到。那为什么行得通呢？

让我们看一下二进制的ASCII码表。

A 1000001    a 1100001
B 1000010    b 1100010
C 1000011    c 1100011
...
Z 1011010    z 1111010

而32是0100000小写和大写字母之间的唯一区别。因此，切换该位可切换字母的大小写。

这利用了事实，即真正聪明的人已经选择了ASCII值。

foo ^= 32;

这个翻转第六最低位¹的foo（ASCII排序的大写标志），转化的ASCII上壳体的下壳体和反之亦然。

+---+------------+------------+
|   | Upper case | Lower case |  32 is 00100000
+---+------------+------------+
| A | 01000001   | 01100001   |
| B | 01000010   | 01100010   |
|            ...              |
| Z | 01011010   | 01111010   |
+---+------------+------------+

例

'A' ^ 32

    01000001 'A'
XOR 00100000 32
------------
    01100001 'a'

根据XOR的属性，'a' ^ 32 == 'A'。

注意

不需要C ++使用ASCII表示字符。另一个变体是EBCDIC。此技巧仅在ASCII平台上有效。一个更可移植的解决方案是使用std::tolower和std::toupper，并且所提供的奖金是可感知区域设置的（尽管它不能自动解决所有问题，请参见评论）：

bool case_incensitive_equal(char lhs, char rhs)
{
    return std::tolower(lhs, std::locale{}) == std::tolower(rhs, std::locale{}); // std::locale{} optional, enable locale-awarness
}

assert(case_incensitive_equal('A', 'a'));

^1）由于32是1 << 5（2等于5的幂），因此它翻转了第6位（从1开始计数）。

让我说，这-尽管看起来很聪明-确实是一个非常愚蠢的黑客。如果有人在2019年向您推荐这个，请打他。尽力打他。
当然，如果您知道您绝不会使用除英语以外的任何语言，那么您当然可以在自己的软件中使用它，而您和其他人都不会使用。否则，不去。

大约30-35年前，当计算机并没有真正做很多事情，而是使用ASCII的英语（也许是一两种主要的欧洲语言）时，这种黑客论点就可以了。但是...不再如此。

该hack之所以有效，是因为US-Latin的大写和小写字母彼此完全0x20分开并且以相同的顺序出现，只是一点点差异。实际上，这有点hack。

现在，为西欧以及后来的Unicode联合会创建代码页的人们足够聪明，可以将这种方案保留给德国的Umlauts和法语的元音。ß并非如此（直到有人在2017年说服Unicode联盟，并且一本大型的Fake News印刷杂志对此进行了报道，实际上说服了Duden-对此没有评论）甚至没有（作为转换）（转换为SS） 。现在它的确存在，但两者是0x1DBF分开的，不是0x20。

但是，实现者不够周到，无法继续进行下去。例如，如果您使用某些东欧语言或类似语言（我对西里尔语不了解）来进行黑客攻击，则会感到讨厌。所有那些“柴刀”字符就是这样的例子，小写字母和大写字母是分开的。因此，hack 无法在此处正常运行。

还有更多需要考虑的内容，例如，某些字符根本不会简单地从小写转换为大写（它们被替换为不同的序列），或者它们可能会更改形式（需要不同的代码点）。

甚至不用考虑这种黑客将对泰国或中国这样的东西产生什么影响（它只会使您完全胡说八道）。

节省数百个CPU周期在30年前可能是非常值得的，但如今，确实没有任何借口来正确转换字符串。有用于执行此重要任务的库函数。如今
，正确转换几十千字节文本所花费的时间可以忽略不计。

之所以起作用，是因为ASCII和导出的编码中的“ a”和“ A”之间的差是32，并且32也是第六位的值。因此，使用异或将第6位翻转会在高位和低位之间转换。

字符集的实现很可能是ASCII。如果我们看一下表格：

我们看到，32小写数字和大写数字的值之间确实存在差异。因此，如果我们这样做^= 32（等于切换第6个最低有效位），它将在小写字符和大写字符之间变化。

请注意，它适用于所有符号，而不仅仅是字母。它在第6位不同的各个字符之间切换字符，从而在一对字符之间来回切换。对于字母，相应的大写/小写字符形成这样的一对。A NUL将变为Space，@反之亦然，并使用反引号进行切换。基本上，此图表第一列中的任何字符都将字符切换为一列，第三列和第四列也是如此。

不过，我不会使用此技巧，因为无法保证它可以在任何系统上正常工作。只需使用toupper和tolower代替，然后使用isupper之类的查询。

这里有很多很好的答案，描述了它是如何工作的，但是为什么它如此工作是为了提高性能。按位运算比处理器中的大多数其他运算要快。您只需不看一下确定大小写的位或仅通过翻转该位来将大小写更改为大写/小写就可以快速进行不区分大小写的比较（设计ASCII表的人非常聪明）。

显然，由于处理器和Unicode的速度更快，今天这并不像1960年（当时刚开始研究ASCII时）那样重要，但是仍然有一些低成本的处理器可能会产生重大的变化只要您只能保证ASCII字符。

https://en.wikipedia.org/wiki/Bitwise_operation

在简单的低成本处理器上，按位运算通常比除法快得多，比乘法快几倍，有时甚至比加法快得多。

注意：出于多种原因（可读性，正确性，可移植性等），我建议使用标准库来处理字符串。仅在测量性能后才使用位翻转，这是您的瓶颈。

这就是ASCII的工作原理，仅此而已。

但是，在利用这一点时，您放弃了可移植性，因为C ++并不坚持将ASCII作为编码。

这就是为什么功能std::toupper和std::tolower在C ++标准库中实现-你应该使用这些。

参见http://www.catb.org/esr/faqs/things-every-hacker-once-knew/#_ascii上的第二张表，以及以下注释，转载如下：

键盘上的Control修饰符基本上清除您键入的任何字符的前三位，保留后五位并将其映射到0..31范围。因此，例如Ctrl-SPACE，Ctrl- @和Ctrl-`都具有相同的含义：NUL。

很老的键盘过去仅通过切换32位或16位（取决于键）来进行Shift键；这就是为什么ASCII中的小写字母和大写字母之间的关系是如此规则的原因，而如果斜视一下，数字和符号以及一些符号对之间的关​​系就很规则。ASR-33是一个全大写的终端，甚至可以通过移动16位来生成一些它没有按键的标点字符。因此，例如，Shift-K（0x4B）变成了[（0x5B）

ASCII的设计使得可以在没有太多逻辑（或可能没有任何逻辑）的情况下实现键盘shift和ctrl键盘键ctrl- shift可能只需要几个门。存储有线协议至少和其他任何字符编码一样有意义（不需要软件转换）。

链接的文章还解释了许多奇怪的黑客惯例，例如And control H does a single character and is an old^H^H^H^H^H classic joke.（在此处找到）。

与32异或（二进制的00100000）进行设置或重置第六个位（从右侧开始）。这严格等于或减去32。

%32在ASCII编码系统中，小写字母和大写字母范围都没有越过“对齐”边界。

这就是为什么位0x20是同一字母的大写/小写版本之间唯一的区别。

如果不是这种情况，则您需要添加或减去0x20，而不仅是切换，对于某些字母，可以进行进位来翻转其他更高的位。（而且不会有一个单一的操作可以切换，并且首先检查字母字符会比较困难，因为您不能| = 0x20来强制lcase。）

相关的纯ASCII技巧：您可以通过将小写字母强制为小写c |= 0x20然后检查（unsigned）是否可以检查字母ASCII字符c - 'a' <= ('z'-'a')。因此，只需3个操作：针对常数25的OR + SUB + CMP。当然，编译器知道如何(c>='a' && c<='z') 为您优化成这样的asm，因此，您最多应该c|=0x20自己完成这一部分。自己做所有必要的转换是很不方便的，特别是要解决对signed的默认整数提升int。

unsigned char lcase = y|0x20;
if (lcase - 'a' <= (unsigned)('z'-'a')) {   // lcase-'a' will wrap for characters below 'a'
    // c is alphabetic ASCII
}
// else it's not

另请参见将C ++中的字符串转换为大写（toupper仅SIMD字符串用于ASCII，使用该检查为XOR屏蔽操作数​​。）

以及如何访问char数组并将小写字母更改为大写字母，反之亦然 （带有SIMD内部函数的C，以及字母ASCII字符的标量x86 asm大小写翻转，其他都保持不变。）

仅当在检查char向量中的s 均未设置高位之后，使用SIMD手动优化某些文本处理（例如SSE2或NEON）时，这些技巧才最有用。（因此，所有字节都不是单个字符的多字节UTF-8编码的一部分，该编码可能具有不同的大写/小写倒数）。如果找到任何内容，则可以针对这16个字节的块或字符串的其余部分退回到标量。

甚至在ASCII范围内的某些字符上toupper()或tolower()某些字符上产生的语言区域超出该范围，尤其是土耳其语，即Iı和İi。 在这些语言环境中，您需要进行更复杂的检查，或者可能根本不尝试使用此优化。

但是在某些情况下，允许您使用ASCII而不是UTF-8，例如，带有LANG=C（POSIX语言环境）的Unix实用程序，不是en_CA.UTF-8或不是。

但是，如果可以验证它的安全性，则toupper中等长度的字符串可以比toupper()在循环中调用（例如5x）快得多，最后我使用Boost 1.58进行了测试，其速度比每个字符boost::to_upper_copy<char*, std::string>()都愚蠢得多dynamic_cast。