1、无符号和有符号
计算机中用补码表示负数，并且有一定的计算方式；另外，用二进制的最高位表示符号，0表示正数、1表示负数。这种说法本身没错，可是要有一定的解释，不然它就是错的，至少不能解释，为什么字符类型的-1二进制表示是“1111 1111”16进制表示为FF，而不是1000 0001。
在计算机中，可以区分正负的类型，称为有符号类型，无正负的类型，称为无符号类型。
使用二进制中的最高位表示正负
一个字节为8位，按0开始记，那它的最高位就是第7位，2个字节，最高位就是15位，4个字节，最高位是31位，不同长度的类型，最高位虽不同，但总是最左边那位。
无符号和有符号数的范围的区别
无符号数中，所有的位都用于直接表示该值的大小；有符号数中最高位用于表示正负，所以，正值时，该数的最大值就会变小：
无符号数：1111 1111值：255=1*2^7+1*2^6+.....=2^n-1
有符号数：0111 1111值：127
同样一个字节，无符号的最大值是255，有符号的最大值是127，下图是无符号数和有符号数的范围：
一个由符号的数据类型的最大值的计算方法完全和无符号一样，只不过它少了一个最高位，但是在负数范围内，数值的计算方法不能直接使用前面的公式，在计算机种，负数除了最高位为1以外，还采用补码的形式，所以在计算前，需要对补码进行还原。
以10进制的计算经验，1表示正1，-1表示和1相对的负值。那么很容易想到在二进制中，0000 0001表示正1，则高位为1后：1000 0001应该表示-1，不过实际上，计算机中的规定有些相反：
可以发现，1000 0000没有拿来表示-0，而1000 0001也不能拿来直观地表示-1，事实上，-1用1111 1111来表示。从一个角度来理解，-1大还是-128大，当然是-1大，-1是最大的负整数，所以，无论是字符类型或整数类型，也无论这个整数是几个字节，从计算结果上来看也是对的：1111 1111-1=1111 1110，表示-2，这样一直减下去，当减到只身最高位用于表示符号的1以外，其他低位全为0，就是最小的负值，也就是-128：
2、 Java基本数据类型
3、 Java的符号类型
Java的原始类型里没有无符号类型，如果需要某个宽度的无符号类型，可以用>>>，这个是java的无符号右移操作符，或者使用下一个宽度的带符号类型来模拟，例如，需无符号的short，就用int来模拟：
1 int toUnsigned(shorts) {2 return s & 0x0FFFF;3 }
十进制的字面常理只有一个特性，就是所有的十进制字面常量都是正数，如果想写一个负的十进制，则需要在正的十进制字面常量前面加上“-”就好了。
十六进制或者八进制的字面常量就不一定是正数或者负数，如果最高位是1，那么就是负数：
1 System.out.println(0x80);//128
2 //0x81看作是int型，最高位(第32位)为0，所以是正数
3 System.out.println(0x81);//129
4 System.out.println(0x8001);//32769
5 System.out.println(0x70000001);//1879048193
6 //字面量0x80000001为int型，最高位(第32位)为1，所以是负数
7 System.out.println(0x80000001);//-2147483647
8 //字面量0x80000001L强制转为long型，最高位(第64位)为0，所以是正数
9 System.out.println(0x80000001L);//2147483649
10 //最小int型
11 System.out.println(0x80000000);//-2147483648
12 //只要超过32位，就需要在字面常量后加L强转long，否则编译时出错
13 System.out.println(0x8000000000000000L);//-922337203685477
4、 有符号扩展和无符号扩展
System.out.println(Long.toHexString(0x100000000L + 0xcafebabe));// cafebabe
结果为什么不是0x1cafebabe？该程序执行的加法是一个混合类型的计算：左操作数是long型，而右操作数是int类型。为了执行该计算，Java将int类型的数值用拓宽原生类型转换提升为long类型，然后对两个long类型数值相加。因为int是有符号的整数类型，所以这个转换执行的是符号扩展。
这个加法的右操作数0xcafebabe为32位，将被提升为long类型的数值0xffffffffcafebabeL，之后这个数值加上了左操作0x100000000L。当视为int类型时，经过符号扩展之后的右操作数的高32位是-1，而左操作数的第32位是1，两个数
值相加得到了0：
0x ffffffffcafebabeL
+0x 0000000100000000L
-----------------------------
0x 00000000cafebabeL
如果要得到正确的结果0x1cafebabe，则需在第二个操作数组后加上“L”明确看作是正的long型即可，此时相加时拓
展符号位就为0：
1 System.out.println(Long.toHexString(0x100000000L + 0xcafebabeL));//1cafe
5、 窄数据类型提升至宽数据类型时是使用符号位扩展还是零扩展
System.out.println((int)(char)(byte)-1);//65535
结果为什么是65535而不是-1？
窄的整型转换成较宽的整型时符号扩展规则：如果最初的数值类型是有符号的，那么就执行符号扩展(即如果符号位为1，则扩展为1，如果为零，则扩展为0)；如果它是char，那么不管它将要被提升成什么类型，都执行零扩展。
了解上面的规则后，我们再来看看迷题：因为byte是有符号的类型，所以在将byte数值-1(二进制为：11111111)提升到char时，会发生符号位扩展，又符号位为1，所以就补8个1，最后为16个1；然后从char到int的提升时，由于是char型提升到其他类型，所以采用零扩展而不是符号扩展，结果int数值就成了65535。
如果将一个char数值c转型为一个宽度更宽的类型时，只是以零来扩展，但如果清晰表达以零扩展的意图，则可以考虑
使用一个位掩码：
1 int i = c & 0xffff;//实质上等同于：int i = c ;
说明：
至于0xff，这属于java的字面常量，他已经是int了，ff表示为11111111，java对这种字面常量，不把他前面的1看做符号位，虽然也是有符号扩展，但是，扩展成的是00...ff.
“数字字面常量”的类型都是int型，而不管他们是几进制，所以“2147483648”、“0x180000000(十六进制，共33位，所以超过了整数的取值范围)”字面常量是错误的，编译时会报超过int的取值范围了，所以要确定以long来表示“2147483648L”、“0x180000000L”。
System.out.println(0x80000001);//-2147483647 ，已经是32位，最高位是符号位
System.out.println(0xcafebabe);//-889275714
System.out.println(0xffff); //65535 int是32位的，最高位已经是0，相当于0X0000ffff
System.out.println(0xff); //255
如果将一个char数值c转型为一个宽度更宽的整型，并且希望有符号扩展，那么就先将char转型为一个short，它与char上个具有同样的宽度，但是它是有符号的：
2 int i = (short)c;
如果将一个byte数值b转型为一个char，并且不希望有符号扩展，那么必须使用一个位掩码来限制它：
3 char c = (char)(b & 0xff);//char c = (char) b;为有符号扩展
6、 ((byte)0x90==0x90)?
答案是不等的，尽管外表看起来是成立的，但是它却等于false。为了比较byte数值(byte)0x90和int数值0x90，Java
通过拓宽原生类型将byte提升为int，然后比较这两个int数值。因为byte是一个有符号类型，所以这个转换执行的是符号扩展，将负的byte数值提升为了在数字上相等的int值(11111111 11111111 11111111 10010000)。在本例中，该转换将(byte)0x90提升为int数值-112，它不等于int数值的0x90，即+144。
解决办法：使用一个屏蔽码来消除符号扩展的影响，从而将byte转型为int。
1 ((byte)0x90 & 0xff)== 0x90
7、 java中byte转换int时与0xff进行运算的原因
java中byte转换int时为何与0xff进行与运算
在剖析该问题前请看如下代码
public static String bytes2HexString(byte[] b) {
String ret= "";for (int i = 0; i < b.length; i++) {
String hex= Integer.toHexString(b[i] & 0xFF);if (hex.length() == 1) {
hex= '0' +hex;
}
ret+=hex.toUpperCase();
}returnret;
}
上面是将byte[]转化十六进制的字符串,注意这里b[i] & 0xFF将一个byte和0xFF进行了与运算,然后使用Integer.toHexString取得了十六进制字符串,可以看出
b[i] & 0xFF运算后得出的仍然是个int,那么为何要和0xFF进行与运算呢?直接Integer.toHexString(b[i]);,将byte强转为int不行吗?答案是不行的.
其原因在于:
1.byte的大小为8bits而int的大小为32bits
2.java的二进制采用的是补码形式
在这里先温习下计算机基础理论
byte是一个字节保存的，有8个位，即8个0、1。8位的第一个位是符号位，也就是说0000 0001代表的是数字1
1000 0000代表的就是-1所以正数最大位0111 1111，也就是数字127负数最大为1111 1111，也就是数字-128
上面说的是二进制原码，但是在java中采用的是补码的形式，下面介绍下什么是补码
Integer.toHexString的参数是int，如果不进行&0xff，那么当一个byte会转换成int时，由于int是32位，而byte只有8位这时会进行补位，例如补码11111111的十进制数为-1转换为int时变为11111111111111111111111111111111好多1啊，呵呵！即0xffffffff但是这个数是不对的，这种补位就会造成误差。和0xff相与后，高24比特就会被清0了，结果就对了。
补码是有符号数，所以从8位变为int需要有符号扩展，变为11111111111111111111111111111111(最终的值为-1)。
至于0xff，这属于java的字面常量，他已经是int了，ff表示为11111111，java对这种字面常量，不把他前面的1看做符号位，虽然也是有符号扩展，但是，扩展成的是00...ff.
一般在有些编译器中，写ff，会把第一位1认为是符号位，所以可以这么写：0x0ff
8、 DataInputStream
DataInputStream in = newDataInputStream(new BufferedInputStream(fileInputStream));
扫一扫
2291
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
