循环中不加0xff 第一个循环出的结果是ffffffc4 ffffffbd ffffffbf ffffffce 41 42 43 ,不是老师讲的前24位都是零,为什么?
循环中不加0xff 第一个循环出的结果是ffffffc4 ffffffbd ffffffbf ffffffce 41 42 43 ,不是老师讲的前24位都是零,为什么?
循环中不加0xff 第一个循环出的结果是ffffffc4 ffffffbd ffffffbf ffffffce 41 42 43 ,不是老师讲的前24位都是零,为什么?
2016-05-27
首先老师讲的有点小错误,不是去掉24个0,是去掉24个【0或1】.为什么呢? 我们以GBK编码的‘慕’为例,如果直接输出Integer.toHexString( b ),不进行&操作。结果是:ffffffc4 ffffffbd.可以看出&操作去掉的是6个f也就是24个1.不应该是24个0吗?我们知道一个字节占8位,可以表示两个16进制数,c4和bd的2进制表示分别为:1100 0100,1011 1101.可以看到他们的第一位都是1.而计算机是以补码形式存储数据。当计算机读取c4时,发现第一位是1,所以c4表示的整数是负数,要得到该负数需要进行取反+1操作得到它表示的正数,然后添加符号位。1100 0100取反+1后是0011 1100,即十进制的60,所以c4表示的是-60。而-60作为一个整形在内存中是以ffffffc4存储的。为了验证这种想法,我们直接输出b,也就是b的整数形式System.out.print( b + " " );结果是:-60 -67.什么时候&的作用是去掉0呢,没错,这个字节的二进制存储中第一位是0,也就是说是个正数。比如'腣'这个字,它的Integer.toHexString( b )结果是ffffffc4 56,第二个字节56在内存中的二进制数是0101 0110,所以当读取56这个十六进制数时,自然当做正数存储,而正数的补码是其本身!
举报