另一个区别是在不同大小的整数之间进行转换时。

例如，如果你从字节流中提取一个整数(简单来说就是16位)，使用无符号值，你可以这样做:

i = ((int) b[j]) << 8 | b[j+1]

(可能应该强制转换第二个字节，但我猜编译器会做正确的事情)

对于有符号的值，你必须担心符号扩展，并做:

i = (((int) b[i]) & 0xFF) << 8 | ((int) b[i+1]) & 0xFF

Signed integers in C represent numbers. If a and b are variables of signed integer types, the standard will never require that a compiler make the expression a+=b store into a anything other than the arithmetic sum of their respective values. To be sure, if the arithmetic sum would not fit into a, the processor might not be able to put it there, but the standard would not require the compiler to truncate or wrap the value, or do anything else for that matter if values that exceed the limits for their types. Note that while the standard does not require it, C implementations are allowed to trap arithmetic overflows with signed values.

Unsigned integers in C behave as abstract algebraic rings of integers which are congruent modulo some power of two, except in scenarios involving conversions to, or operations with, larger types. Converting an integer of any size to a 32-bit unsigned type will yield the member corresponding to things which are congruent to that integer mod 4,294,967,296. The reason subtracting 3 from 2 yields 4,294,967,295 is that adding something congruent to 3 to something congruent to 4,294,967,295 will yield something congruent to 2.

Abstract algebraic rings types are often handy things to have; unfortunately, C uses signedness as the deciding factor for whether a type should behave as a ring. Worse, unsigned values are treated as numbers rather than ring members when converted to larger types, and unsigned values smaller than int get converted to numbers when any arithmetic is performed upon them. If v is a uint32_t which equals 4,294,967,294, then v*=v; should make v=4. Unfortunately, if int is 64 bits, then there's no telling what v*=v; could do.

鉴于标准的现状，我建议在需要与代数环相关的行为时使用无符号类型，在需要表示数字时使用有符号类型。不幸的是，C以这种方式进行了区分，但它们就是它们。

在C语言中，有符号值和无符号值之间唯一保证的区别是有符号值可以为负、0或正，而无符号值只能为0或正。问题是C语言没有定义类型的格式(所以你不知道你的整数是2的补数)。严格来说，你提到的前两点是不正确的。

我将在x86上讨论硬件层面的差异。除非您正在编写编译器或使用汇编语言，否则这几乎无关紧要。但很高兴知道。

首先，x86原生支持这两个数字的有符号数的补表示。您可以使用其他表示，但这将需要更多的指令，通常是浪费处理器时间。

我所说的“原生支持”是什么意思?我的意思是，有一组指令用于无符号数，另一组用于有符号数。无符号数可以与有符号数位于相同的寄存器中，实际上，您可以混合有符号和无符号指令，而不用担心处理器。由编译器(或汇编程序员)来跟踪数字是否带符号，并使用适当的指令。

首先，2的补数具有加减法与无符号数相同的性质。这些数字是正还是负没有区别。(所以你只要继续做加法和减法就可以了，不用担心。)

当进行比较时，差异开始显现出来。X86有一种简单的区分方法:上面/下面表示无符号比较，而大于/小于表示有符号比较。(例如，JAE的意思是“高于或等于就跳”，没有符号。)

还有两组乘除指令用于处理有符号整数和无符号整数。

最后:如果你想检查溢出，你可以对有符号数和无符号数做不同的检查。

他只问了签过名和没签过名的。不知道为什么人们要在里面加额外的东西。让我来告诉你答案。

Unsigned:它只包含非负值，即0到255。 Signed:由正负值组成，但格式不同，如 0 ~ +127 -1 ~ -128

这个解释是关于8位数字系统的。

为了完整起见，这里只提几点:

this answer is discussing only integer representations. There may be other answers for floating point; the representation of a negative number can vary. The most common (by far - it's nearly universal today) in use today is two's complement. Other representations include one's complement (quite rare) and signed magnitude (vanishingly rare - probably only used on museum pieces) which is simply using the high bit as a sign indicator with the remain bits representing the absolute value of the number. When using two's complement, the variable can represent a larger range (by one) of negative numbers than positive numbers. This is because zero is included in the 'positive' numbers (since the sign bit is not set for zero), but not the negative numbers. This means that the absolute value of the smallest negative number cannot be represented. when using one's complement or signed magnitude you can have zero represented as either a positive or negative number (which is one of a couple of reasons these representations aren't typically used).