根据that site ASCii 的 ü 值为 129，但是当我运行 printf("%d",'ü') 代码时，输出为 -4。这是什么原因？
【问题讨论】：
标签： c++ windows encoding ascii
您获得 -4 的事实基本上纯属偶然，因为这取决于您的环境的语言环境设置和编译器的实现。
其他人已经指出，根据您的平台是否认为 char 是有符号的，将 char 值作为整数打印可能会为 0x80 或更高的值产生负数。
至于编码（请注意，下面的列表绝不是详尽的）：
ü 没有 ASCII 值，因为 (US-) ASCII 仅定义最大为 0x7f (127) 的字符。
IBM Codepage 437 和 850 (DOS) 在 0x81 处具有 ü，根据签名为 -127 或 129。
ISO-8859-1 through -4, -9, -10, and -13 through -16 以及 Windows 代码页 1250 和 1252 在 0xfc (-4 / 252) 处具有 ü。其他 ISO-8859 编码的字符集中没有 ü。
UTF-8 - 每个人都应该使用它而不是过去的那些 8 位编码，用于 reasons 的 variety - 将 ü 编码为两字节序列 0xc3 0xbc。
我整理了一个并排的代码页供个人使用，如果您有兴趣，可以在my homepage 找到它。
一旦您接受了这一点，请注意该标准定义了两个character sets，一个用于表示源代码，一个用于表示可执行代码中的字符串。两者都不包含超出基本 A-Z 范围的任何字符，两者实际上可能不同（想想交叉编译器），并且都没有定义其数字表示 - 即您可能实际上正在查看 EBCDIC，其中字符甚至没有编码连续 值（即assert( 'Z' - 'A' == 26 ) 会失败）。
你觉得这很有趣吗？好吧，基本上你的机器甚至不需要提供像@ 这样的字符，因为那是ASCII，但不是基本字符集的一部分。 ;-)
一般来说，一旦您在源代码中使用非 ASCII 字符，您就会留下明确定义的行为，并且依赖于实现/环境。
【讨论】：
š 的模糊性导致的错误（Windows 中的 0x9a，ISO-8859-15 中的 0xa8，UTF-8 中的 0xc5 0xa1）。太多的人，包括其他熟练的开发人员，不知道、不关心或不时忘记字符编码。文本为 UTF-8，源为 ASCII-7。恕我直言。
在您的系统上 char 是有符号类型。打印前应先转换为无符号类型。
printf("%d", (unsigned char)'ü');
这是否会打印您期望的 129 是另一回事，但它至少会在您的执行字符集中打印 ü 的编码。
【讨论】：
%d 正在打印一个带符号的十进制数，对于一个字节，它将在 -128-127 的范围内打印）。您可能希望使用无符号 (%u) 来输出预期的 0-255。
【讨论】：
printf("%d", (unsigned char)'ü')。负整数不会以直接的方式转换为无符号值。