unsigned char 和 signed char 区别

Posted 2023-04-24

申明 本人初学,不懂就要问

我看到2个表 一个是signed char 等等 有个就是在signed char 前面加了个 un的 加un和不加有什么区别吗?

还有就是 编成里面要用到英文的 一写 语法... 嘿嘿 我能用拼音来代替么 我试过 的出的结果都一样..
主要是英语 没学习好...不想去背单词..每次学习编程还拿那本英语字典 一边写 一边找单词

在C/C++中char型等价于整型数据，占一个字节，8个比特位。在语言中默认的就是signed char ，其范围

对应整数-128~+127，而unsigned char代表的是无符号的字符型，对应的整数范围为0~255.
例如:

#include<iostream>
using namespace std;

int main()

char ch='a';

cout<<(int)ch<<endl;
return 0;



输出的就是97，即小写字母a，对应的十进制数为97，A对应为65。

扩展资料

C++中，有3种不同的字符类型： 
char 

signed char 

unsigned char

如果用于文本，则使用未加限定的char， 类似于 'a', '0', 'abcde' 等。它也可以是一个值，但是是当做无符号还是有符号数没有指定。

如果将字符类型用作数字，那么:

signed char, 范围至少为 [-127 ~ 127] 。 (一般范围是 -128 到 127) 
unsigned char, 范围至少为 [0 ~ 255]。

说“至少”是因为C++标准只指定了对应每一种数据类型值的最小覆盖范围。

如果真的要表示小的整数的话，最好使用 int8_t 和 uint8_t 。

参考技术A

unsigned char 和 signed char 区别：

signed char取值范围是 -128 到 127
unsigned char 取值范围是 0 到 255

ANSI C 提ANSI C 提供了3种字符类型，分别是char、signed char、unsigned char
char相当于signed char或者unsigned char，但是这取决于编译器！

这三种字符类型都是按照1个字节存储的，可以保存256个不同的值。
不同的是取值范围
signed char取值范围是 -128 到 127
unsigned char 取值范围是 0 到 255
signed char的最高位为符号位，因此char能表示-128~127, unsigned char没有符号位，因此能表示0~255。


但是char究竟相当于signed char呢还是相当于unsigned char呢？？
这就是char和int的不同之处！
int＝＝signed int，但是char不能简单以为＝＝signed char

要确定char究竟等同什么要基于不同的编译器做测试
大多数机器使用补码来存储整数，在这些机器中按照整数类型存储的－1的所有位均是1
假设我的机器也是如此存储，就能据此判断char究竟是等于signed char还是unsigned char
在实际使用过程种有什么区别呢？

主要是符号位，但是在普通的赋值，读写文件和网络字节流都没什么区别，反正就是一个字节，不管最高位是什么，最终的读取结果都一样，只是你怎么理解最高位而已，在屏幕上面的显示可能不一样。

但是我们却发现在表示byte时，都用unsigned char，这是因为byte没有符号位之说。

如果是char，那么系统认为最高位是符号位，而int可能是16或者32位，那么会对最高位进行扩展（注意，赋给unsigned int也会扩展），而如果是unsigned char，那么不会扩展。

这就是二者的最大区别。

参考技术B 我的回答只针对C/C++语言，不知道你学的是不是这两种语言。

在C/C++中char型等价于整型数据，占一个字节，8个比特位。在语言中默认的就是signed char ，其范围
对应整数-128~+127，而unsigned char代表的是无符号的字符型，对应的整数范围为0~255.
例如:
#include<iostream>
using namespace std;

int main()

char ch='a';

cout<<(int)ch<<endl;
return 0;



输出的就是97，即小写字母a，对应的十进制数为97.A对应为65.本回答被提问者采纳 参考技术C 我的回答只针对C/C++语言，不知道你学的是不是这两种语言。 在C/C++中char型等价于整型数据，占一个字节，8个比特位。在语言中默认的就是signed char ，其范围 对应整数-128~+127，而unsigned char代表的是无符号的字符型，对应的整数范围为0~255. 例如: #include<iostream> using namespace std; int main() char ch='a'; cout<<(int)ch<<endl; return 0; 输出的就是97，即小写字母a，对应的十进制数为97.A对应为65. 参考技术D unsigned char 等同于 BYTE
signed char 等同于char

将 unsigned char 转换为 signed char 以获得红黑树

【中文标题】将 unsigned char 转换为 signed char 以获得红黑树

【英文标题】：Casting unsigned char to signed char for a red-black tree

【发布时间】：2018-06-06 08:20:56

【问题描述】：

概述

我正在使用 Qt 封装 Windows Shell 功能。我遇到的问题与ABSOLUTE_IDLISTs 和存储数据有关。作为参考，一个 Windows id 列表在内存中是这样的：

//Note that there may be an arbitrary number of cb/abId pairs.
=================================================================
=           =   (cb bytes)  =           =  (cb bytes)   =       =
= USHORT cb =  UCHAR []abID = USHORT cb =  UCHAR []abId = '\0'  =
=================================================================

我使用绝对 ID 作为每个节点的唯一标识符以便快速 恢复。值类型为ShellNodePointer，一个指向ShellNode的共享指针，用于缓存数据。我最初使用 QHash（基本上是 std::unordored_map），但这需要对每次检索的位进行哈希处理（尽管我将哈希键存储在 ShellNode 中）。

//unsigned int is the hash result, ShellNodePointer is a QSharedPointer to a ShellNode
QHash<unsigned int, ShellNodePointer>

相反，我正在考虑使用QMap 的红黑树方法。我的问题是 this：比较两个键的最快方法是将它们存储为QByteArrays，这将允许快速小于比较并将id列表作为原始数据简单地传递给QByteArray构造函数。

ITEMIDLIST_ABSOLUTE *someIdListPointer = ...;
QByteArray ba(someIdListPointer);

问题

不幸的是，QByteArray 采用以空结尾的const char *，没有 指定签名或未签名。由于我在 Windows 上，因此默认为已签名 字符。

问题

我可以转换为[signed] char * 并忽略溢出问题，因为每个负值键都会以同样的方式溢出吗？具体来说，红黑树是否仍能正常工作，因为在使用相同键的两个单独调用中保证生成的数据是一致的？

注意：我知道USHORT cb 将包含在密钥中。这是可以接受的，因为它只是将与两个相同的键匹配的额外数据。

编辑：澄清abId 实际上是一个没有空终止符的数组。

【问题讨论】：

哪些溢出问题？将指针转换为不同的类型意味着您以不同的方式解释字节（就像其他有符号/无符号转换一样）并且不可能溢出。此外，虽然标准不保证有符号整数类型的二进制补码表示，但这是一个非常安全的假设。

我是这么想的，但我想确保在比较密钥时不会遇到问题。

假设您不关心 RB 树中的实际顺序，您可以以任何您想要的方式处理/查看数据字节以进行比较，甚至像 int32_ts (假设列表正确对齐）。那么两者的补码也无关紧要。当只有整个列表以空字符结尾而不是单个键时，QByteArray 采用以空字符结尾的字符序列之间的差异让我更加困惑。但也许这是我的一个误解。

关于空终止：cbID 不是空终止，只有整个结构。

什么是cbID？

【参考方案1】：

我可以转换为 [signed] char * 并忽略溢出问题，因为每个负值键都会以相同的方式溢出吗？具体来说，红黑树是否仍能正常工作，因为在使用相同键的两个单独调用中保证生成的数据是一致的？

是的，像这样的转换只是以不同的方式解释内存中的字节，并且对于相同的机器 + 可执行文件/编译器是一致的。标准没有强制要求有符号整数的字节表示，因此“含义”（即表示的数字）可能不是您所期望的，但这对于只需要总排序的 RB 树来说并不重要。

【讨论】：

感谢您的帮助和耐心，Max。