Char和unsigned Char不能保证在所有平台上都是8位类型——它们保证是8位或更大的类型。一些平台有9位、32位或64位字节。然而，今天最常见的平台(Windows、Mac、Linux x86等)都有8位字节。

就直接值而言，当已知值在CHAR_MIN和CHAR_MAX之间时，使用常规char，而unsigned char在正端提供了两倍的范围。例如，如果CHAR_BIT为8，则常规char的范围只能保证为[0,127](因为它可以是有符号的或无符号的)，而无符号char将是[0,255]，而有符号char将是[-127,127]。

就其用途而言，标准允许将POD(普通旧数据)对象直接转换为unsigned char数组。这允许您检查对象的表示和位模式。对于char或signed char，不存在安全类型双关的相同保证。

Unsigned char只取正值....比如0到255

而

Signed char同时取正负值....比如-128到+127

Unsigned char是所有比特欺骗的核心。在几乎所有平台的所有编译器中，无符号字符只是一个字节和一个无符号整数(通常为8位)，可以被视为一个小整数或一组位。

此外，正如其他人所说，标准并没有定义char的符号。你有三种不同的char类型:，有符号char，无符号char。

例如unsigned char的用法:

Unsigned char经常用于计算机图形，它经常(虽然不总是)为每个颜色组件分配一个字节。通常可以看到RGB(或RGBA)颜色表示为24(或32)位，每个位都是unsigned char。由于unsigned char值落在[0,255]范围内，这些值通常被解释为:

0表示完全缺乏给定的颜色组件。 255表示某一特定色素的100%。

所以你最终会得到RGB红色为(255,0,0)->(100%红，0%绿，0%蓝)。

Why not use a signed char? Arithmetic and bit shifting becomes problematic. As explained already, a signed char's range is essentially shifted by -128. A very simple and naive (mostly unused) method for converting RGB to grayscale is to average all three colour components, but this runs into problems when the values of the colour components are negative. Red (255, 0, 0) averages to (85, 85, 85) when using unsigned char arithmetic. However, if the values were signed chars (127,-128,-128), we would end up with (-99, -99, -99), which would be (29, 29, 29) in our unsigned char space, which is incorrect.

无符号字符使用为常规字符的符号保留的位作为另一个数字。这将范围更改为[0 - 255]，而不是[-128 - 127]。

当你不想要符号时，通常使用无符号字符。这在处理像移位位(移位扩展符号)和其他将字符作为字节处理而不是将其作为数字处理时会产生不同。