最近在做编码转换时,发现一段别人写的代码:
public static String byte2hexString(byte[] bytes) {
StringBuffer buf = new StringBuffer(bytes.length * 2);
for (int i = 0; i < bytes.length; i++) {
int c = bytes[i] & 0xFF;
if (c < 0x10) { // 等价于c < 16
buf.append("0");
}
buf.append(Long.toString((int) bytes[i] & 0xFF, 16));
}
return buf.toString();
}
为什么要将bytes[i]&0xFF再复制给int类型呢?为此,我们先来了解一下原码、反码、补码的基本知识。
在32位的电脑中数字都是以32格式存放的,如果是一个byte(8位)类型的数字,他的高24位里面都是随机数字,低8位才是实际的数据。java.lang.Integer.toHexString() 方法的参数是int(32位)类型,如果输入一个byte(8位)类型的数字,这个方法会把这个数字的高24为也看作有效位,这就必然导致错误,使用& 0XFF操作,可以把高24位置0以避免这样错误的发生。
在学习原码, 反码和补码之前, 需要先了解机器数和真值的概念.
一个数在计算机中的二进制表示形式, 叫做这个数的机器数。机器数是带符号的,在计算机用一个数的最高位存放符号, 正数为0, 负数为1(Java没有无符号数,全部都是有符号数,需要用最高位表示正负;但C语言中有无符号数).
比如,十进制中的数 +3 ,计算机字长为8位,转换成二进制就是00000011。如果是 -3 ,就是 10000011 。
那么,这里的 00000011 和 10000011 就是机器数。
因为第一位是符号位,所以机器数的形式值就不等于真正的数值。例如上面的有符号数 10000011,其最高位1代表负,其真正数值是 -3 而不是形式值131(10000011转换成十进制等于131)。所以,为区别起见,将带符号位的机器数对应的真正数值称为机器数的真值。
例:0000 0001的真值 = +000 0001 = +1,1000 0001的真值 = –000 0001 = –1
在探求为何机器要使用补码之前, 让我们先了解原码, 反码和补码的概念.对于一个数, 计算机要使用一定的编码方式进行存储. 原码, 反码, 补码是机器存储一个具体数字的编码方式.
原码就是符号位加上真值的绝对值, 即用第一位表示符号, 其余位表示值. 比如如果是8位二进制:
[+1]原 = 0000 0001
[-1]原 = 1000 0001
第一位是符号位. 因为第一位是符号位, 所以8位二进制数的取值范围就是:
[1111 1111 , 0111 1111]
即
[-127 , 127]
原码是人脑最容易理解和计算的表示方式.
反码的表示方法是:
正数的反码是其本身
负数的反码是在其原码的基础上, 符号位不变,其余各个位取反.
[+1] = [00000001]原 = [00000001]反
[-1] = [10000001]原 = [11111110]反
可见如果一个反码表示的是负数, 人脑无法直观的看出来它的数值. 通常要将其转换成原码再计算.
补码的表示方法是:
正数的补码就是其本身
负数的补码是在其原码的基础上, 符号位不变, 其余各位取反, 最后+1. (即在反码的基础上+1)
[+1] = [00000001]原 = [00000001]反 = [00000001]补
[-1] = [10000001]原 = [11111110]反 = [11111111]补
对于负数, 补码表示方式也是人脑无法直观看出其数值的. 通常也需要转换成原码,再计算其数值.
在开始深入学习前, 我的学习建议是先"死记硬背"上面的原码, 反码和补码的表示方式以及计算方法.
现在我们知道了计算机可以有三种编码方式表示一个数. 对于正数因为三种编码方式的结果都相同:
[+1] = [00000001]原 = [00000001]反 = [00000001]补
所以不需要过多解释. 但是对于负数:
[-1] = [10000001]原 = [11111110]反 = [11111111]补
可见原码、反码和补码是完全不同的. 既然原码才是被人脑直接识别并用于计算表示方式, 为何还会有反码和补码呢?
首先, 因为人脑可以知道第一位是符号位, 在计算的时候我们会根据符号位, 选择对真值区域的加减. (真值的概念在本文最开头). 但是对于计算机, 加减乘数已经是最基础的运算, 要设计的尽量简单.计算机辨别"符号位"显然会让计算机的基础电路设计变得十分复杂!于是人们想出了将符号位也参与运算的方法. 我们知道, 根据运算法则减去一个正数等于加上一个负数, 即: 1-1 = 1 + (-1) = 0 ,所以机器只有加法而没有减法, 这样计算机运算的设计就更简单了.
于是人们开始探索 将符号位参与运算, 并且只保留加法的方法. 首先来看原码:
计算十进制的表达式: 1-1=0
1 - 1 = 1 + (-1) = [00000001]原 + [10000001]原 = [10000010]原 = -2
如果用原码表示, 让符号位也参与计算, 显然对于减法来说, 结果是不正确的.这也就是为何计算机内部不使用原码表示一个数.
为了解决原码做减法的问题, 出现了反码:
计算十进制的表达式: 1-1=0
1 - 1 = 1 + (-1) = [0000 0001]原 + [1000 0001]原= [0000 0001]反 + [1111 1110]反 = [1111 1111]反 = [1000 0000]原= -0
发现用反码计算减法, 结果的真值部分是正确的. 而唯一的问题其实就出现在"0"这个特殊的数值上. 虽然人们理解上+0和-0是一样的, 但是0带符号是没有任何意义的. 而且会有[0000 0000]原和[1000 0000]原两个编码表示0.
于是补码的出现, 解决了0的符号以及两个编码的问题:
1-1 = 1 + (-1) = [0000 0001]原 + [1000 0001]原 = [0000 0001]补 + [1111 1111]补 = [0000 0000]补=[0000 0000]原
这样0用[0000 0000]表示, 而以前出现问题的-0则不存在了.而且可以用[1000 0000]表示-128
(-1) + (-127) = [1000 0001]原 + [1111 1111]原 = [1111 1111]补 + [1000 0001]补 = [1000 0000]补
-1-127的结果应该是-128, 在用补码运算的结果中, [1000 0000]补 就是-128. 但是注意因为实际上是使用以前的-0的补码来表示-128, 所以-128并没有原码和反码表示.(对-128的补码表示[1000 0000]补算出来的原码是[0000 0000]原, 这是不正确的)
使用补码, 不仅仅修复了0的符号以及存在两个编码的问题, 而且还能够多表示一个最低数. 这就是为什么8位二进制, 使用原码或反码表示的范围为[-127, +127], 而使用补码表示的范围为[-128, 127].
因为机器使用补码, 所以对于编程中常用到的32位int类型, 可以表示范围是: [-231, 231-1] 因为第一位表示的是符号位.而使用补码表示时又可以多保存一个最小值.
首先八位二进制数0000 0000 ~1111 1111,一共可以表示2^8=256位数,如果表示无符号整数可以表示0~255。计算方法就是二进制与十进制之间的转换。
11111111
2^7 = 128
2^6 = 64
2^5 = 32
2^4 = 16
2^3 = 8
2^2 = 4
2^1 = 2
2^0 = 1
128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255
64 + 32 + 16 + 8 + 4 + 2 + 1 = 127
如果想要表示有符号整数,就要将最前面一个二进制位作为符号位,即0代表正数,1代表负数,后面7位为数值域,这就是原码定义。这样在现实生活中完全没有问题,但在计算机中就出现了问题。
先解决第一个问题,引入补码是为了解决计算机中数的表示和数的运算问题,使用补码,可以将符号位和数值域统一处理,即引用了模运算在数理上对符号位的自动处理,利用模的自动丢弃实现了符号位的自然处理,仅仅通过编码的改变就可以在不更改机器物理架构的基础上完成的预期的要求。
要解决第二个问题同时理解补码,首先要理解“模”,模的概念可以帮助理解补数和补码。
“模”是指一个计量系统的计数范围。如时钟、计算机也可以看成一个计量机器,它也有一个计量范围,即都存在一个“模”。例如: 时钟的计量范围是0~11,模=12。表示n位的计算机计量范围是0~2^(n)-1,模=2^(n)。
“模”实质上是计量器产生“溢出”的量,它的值在计量器上表示不出来,计量器上只能表示出模的余数。任何有模的计量器,均可化减法为加法运算。
例如:假设当前时针指向10点,而准确时间是6点,调整时间可有以下两种拨法:一种是倒拨4小时,即:10-4=6;另一种是顺拨8小时:10+8=12+6=6
在以12模的系统中,加8和减4效果是一样的,因此凡是减4运算,都可以用加8来代替。对“模”而言,8和4互为补数。实际上以12模的系统中,11和1,10和2,9和3,7和5,6和6都有这个特性。共同的特点是两者相加等于模。
对于计算机,其概念和方法完全一样。n位计算机,设n=8, 所能表示的最大数是11111111,若再加1成为100000000(9位),但因只有8位,最高位1自然丢失。又回了00000000,所以8位二进制系统的模为2^8。在这样的系统中减法问题也可以化成加法问题,只需把减数用相应的补数表示就可以了。把补数用到计算机对数的处理上,就是补码。
对一个正数的原码取反加一,得到这个正数对应负数的补码。例如~6=-7,而且加一之后会多出一个八进制补码1000 0000,而这个补码就对应着原码1000 0000,数字位同时当做符号位即-128。
根据以上内容我们就可以来解释八位二进制数的表示范围
八位二进制正数的补码范围是0000 0000 -> 0111 1111 即0 -> 127,
负数的补码范围是正数的原码0000 0000 -> 0111 1111 取反加一(也可以理解为负数1000 0000 -> 1111 1111化为反码末尾再加一)。
所以得到 1 0000 0000 -> 1000 0001,1000 0001作为补码,其原码是1111 1111(-127),依次往前推,可得到-1的补码为1111 1111,那么补码0000 0000的原码是1000 0000符号位同时也可以看做数字位即表示-128,
这也解释了为什么127(0111 1111)+1(0000 0001)=-128(0000 0000)。
在计算机中数据用补码表示,利用补码统一了符号位与数值位的运算,同时解决了+0、-0问题,将空出来的二进制原码1000 0000表示为-128,这也符合自身逻辑意义的完整性。因此八位二进制数表示范围为-128~+127。
回到最初的问题,为什么要&0xFF
拿到的文件流转成byte数组,难道我们关心的是byte数组的十进制的值是多少吗?我们关心的是其背后二进制存储的补码吧
所以大家应该能猜到为什么byte类型的数字要&0xff再赋值给int类型,其本质原因就是想保持二进制补码的一致性。
当byte要转化为int的时候,高的24位必然会补1,这样,其二进制补码其实已经不一致了,&0xff可以将高的24位置为0,低8位保持原样(32位系统编译器,int占4个字节)。这样做的目的就是为了保证二进制数据的一致性。
当然,保证了二进制数据性的同时,如果二进制被分别当作byte和int来解读,其10进制的值必然是不同的,因为符号位位置已经发生了变化。
public static void main(String[] args) {
byte[] a = new byte[10];
a[0]= -127;
System.out.println(a[0]);
int c = a[0]&0xff;
System.out.println(c);
}
a[0] & 0xff = 1_11111111_11111111_11111111_10000001 & 1_1111111 = 00000000_00000000_0000000010000001,这个值就是129,所以c的输出的值就是129。
有人问为什么a[0]不是8位而是32位,因为当系统检测到byte转化成int时,会将byte的内存空间高位补1(也就是按符号位补位)扩充到32位,再参与运算。上面的0xff其实是int类型的字面量值,所以可以说byte与int进行运算。
左移运算符<<使指定值的所有位都左移规定的次数。
1)它的通用格式如下所示: value << num
num 指定要移位值value 移动的位数。左移的规则只记住一点:丢弃最高位,0补最低位如果移动的位数超过了该类型的最大位数,那么编译器会对移动的位数取模。如对int型移动33位,实际上只移动了33%32=1位。
2)运算规则
按二进制形式把所有的数字向左移动对应的位数,高位移出(舍弃),低位的空位补零。 当左移的运算数是int 类型时,每移动1位它的第31位就要被移出并且丢弃; 当左移的运算数是long 类型时,每移动1位它的第63位就要被移出并且丢弃。 当左移的运算数是byte 和short类型时,将自动把这些类型扩大为 int 型。
3) 数学意义
在数字没有溢出的前提下,对于正数和负数,左移一位都相当于乘以2的1次方,左移n位就相当于乘以2的n次方
4)计算过程:
例如:3 <<2(3为int型)1)把3转换为二进制数字0000 0000 0000 0000 0000 0000 0000 0011,
2)把该数字高位(左侧)的两个零移出,其他的数字都朝左平移2位, 3)在低位(右侧)的两个空位补零。则得到的最终结果是0000 0000 0000 0000 0000 0000 0000 1100,
转换为十进制是12。移动的位数超过了该类型的最大位数,如果移进高阶位(31或63位),那么该值将变为负值。下面的程序说明了这一点: Java代码// Left shifting as a quick way to multiply by 2. public class MultByTwo {public static void main(String args[]) { int i;int num = 0xFFFFFFE; for(i=0; i<4; i++) { num = num << 1;System.out.println(num); } } }该程序的输出如下所示:536870908 1073741816 2147483632 -32注:n位二进制,最高位为符号位,因此表示的数值范围-2^(n-1) ——2^(n-1) -1,所以模为2^(n-1)。
五、 右移运算符
右移运算符<<使指定值的所有位都右移规定的次数。
1)它的通用格式如下所示: value >> num
num 指定要移位值value 移动的位数。右移的规则只记住一点:符号位不变,左边补上符号位
2)运算规则:
按二进制形式把所有的数字向右移动对应的位数,低位移出(舍弃),高位的空位补符号位,即正数补零,负数补1当右移的运算数是byte 和short类型时,将自动把这些类型扩大为 int 型。例如,如果要移走的值为负数,每一次右移都在左边补1,如果要移走的值为正数,每一次右移都在左边补0,这叫做符号位扩展(保留符号位)(sign extension ),在进行右移操作时用来保持负数的符号。
3) 数学意义
右移一位相当于除2,右移n位相当于除以2的n次方。
4)计算过程
11 >>2(11为int型)1)11的二进制形式为:0000 0000 0000 0000 0000 0000 0000 1011
2)把低位的最后两个数字移出,因为该数字是正数,所以在高位补零。
3)最终结果是0000 0000 0000 0000 0000 0000 0000 0010。 转换为十进制是3。
35 >> 2(35为int型)35转换为二进制:0000 0000 0000 0000 0000 0000 0010 0011把低位的最后两个数字移出:0000 0000 0000 0000 0000 0000 0000 1000 转换为十进制: 8
5)在右移时不保留符号的出来
右移后的值与0x0f进行按位与运算,这样可以舍弃任何的符号位扩展,以便得到的值可以作为定义数组的下标,从而得到对应数组元素代表的十六进制字符。 例如Java代码public class HexByte {public static public void main(String args[]) { char hex[] = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'' };byte b = (byte) 0xf1;System.out.println("b = 0x" + hex[(b >> 4) & 0x0f] + hex[b & 0x0f]); } }(b >> 4) & 0x0f的运算过程: b的二进制形式为:1111 0001 4位数字被移出:0000 1111 按位与运算:0000 1111 转为10进制形式为:15b & 0x0f的运算过程:b的二进制形式为:1111 0001 0x0f的二进制形式为:0000 1111 按位与运算:0000 0001 转为10进制形式为:1 所以,该程序的输出如下: b = 0xf1
无符号右移运算符>>> 它的通用格式如下所示: value >>> num
num 指定要移位值value 移动的位数。
无符号右移的规则只记住一点:忽略了符号位扩展,0补最高位 无符号右移运算符>>> 只是对32位和64位的值有意义
3. 一个简单大家都知道的事实!
trubo C的int是2字节
vc的int是4字节
再看java编译器,无论在什么机器上,int都是那么大
所谓跟平台无关,就是跟机器和操作系统没有关系!
4. 机器第一作用,编译器第二作用.
现在新出的机器开始有64位的,编译器也逐渐的要适应这个改变,由32位向64位过渡.
如果机器是16位的,编译器强制为32位的话,效率及其低下,没那家厂商会做如此SB的事情,
我们现在的机器一般都是32位的,编译器所以一般也是32位,但也支持64位的,
__int64 就是64字节的,
总之int 只是一个类型,没有太大的意义,机器的位数才是关键所在!
离开机器,说有编译器决定的人,实在不敢恭维.
难道要在8位机上实现64bit的编译器?
机器进步了,编译器跟不上,就要被淘汰,
编译器超前了,效率低下,也不会有市场,
所以不要单纯的讨论编译器或者机器了。
OVER!
参考:
http://www.cnblogs.com/zhangziqiu/archive/2011/03/30/ComputerCode.html
http://www.cnblogs.com/think-in-java/p/5527389.html
http://www.cnblogs.com/minggeqiuzhi/archive/2014/07/10/3835883.html
http://blog.csdn.net/zimo2013/article/details/40047695
http://blog.csdn.net/fenzang/article/details/53500852