问为什么char不兼容已签名字符或未签名字符？

EN

根在编译器历史中。在八十年代，基本上有两种C方言：

1. 其中普通字符被签名
2. 其中普通字符未签名

这些C89中的哪一个应该标准化？C89选择两种方法都不标准化，因为它会使C代码中已经编写的大量假设失效--标准人员称之为已安装的基础。因此，C89做了K&R所做的事情:保留普通char实现定义的签名性。如果你需要一个特定的符号，限定你的字符。现代编译器通常允许您选择带有选项的方言(例如。gcc的-funsigned-char)。

如果你忽略(Un)符号字符和普通字符之间的区别，可能会发生“可怕”的事情:如果你做算术和移位而没有考虑到这些细节，那么当你不期望它们时，你可能会得到符号扩展，反之亦然(甚至在移动时没有定义的行为)。

还有一些愚蠢的建议，建议总是使用显式的有符号或无符号的限定符来声明字符。只要您只使用指向这类限定类型的指针，但当您处理字符串和字符串函数时，它就需要丑陋的强制转换，而这些字符串和字符串函数都是在指针到普通字符上操作的，这是赋值不兼容的，没有强制转换。这样的代码突然间被大量丑陋到骨子里的铸型抹黑了。

“宪章”的基本规则是：

• 对字符串使用普通的char，如果需要将指针传递给接受普通字符的函数
• 如果您需要进行位旋转和字节转移，请使用unsigned char
• 如果您需要小的有符号值，请使用signed char，但是如果空格不需要考虑，请考虑使用int

将signed char和unsigned char看作最小的算术、积分类型，就像signed short/unsigned short，以及int、long int、long long int等等。这些类型都有明确的规定.

另一方面，char的用途非常不同:它是I/O的基本类型，也是与系统通信的基本类型。它不是用来计算的，而是数据的单位。这就是为什么在命令行参数、“字符串”定义、FILE*函数和其他读/写类型IO函数中以及在严格混叠规则的例外中使用的FILE*。这种char类型的定义不那么严格，以便允许每个实现使用最“自然”的表示。

这只是一个分离责任的问题。

(不过，char确实是与signed char和unsigned char兼容的布局，因此可以显式地将其中一个转换为另一个和back。)