blocks|key|902234|text|我猜在进行转换之前，b是对int进行了符号扩展。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|902235|因此，这可能会像预期的那样工作：|902236|(byte)((0x000000FF+&+b)>>4)|code-block|syntax|javascript|902237|entityMap^0|A|1|D|3|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|U|8|@]|D|@]|E|$K|L]]|$1|M|3|-4|5|6|7|V|8|@]|D|@]|E|$]]]|N|$]]

I'd guess that <code>b</code> is sign extended to <code>int</code> before shifting. 

So this might work as expected:

<pre><code>(byte)((0x000000FF &amp; b)&gt;&gt;4)
</code></pre>

blocks|key|1117039|text|问题是，在进行移位操作之前，所有参数都首先被提升为int：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1117040|byte+b+=+(byte)+0xf1;|code-block|syntax|javascript|1117041|b是带符号的，所以它的值为-15。|1117042|byte+c+=+(byte)+(b+>>+4);|1117043|b首先被符号扩展为整数-15+=+0xfffffff1，然后向右移位为0xffffffff，并通过转换为0xff将其截断为byte。|1117044|byte+d+=+(byte)+(b+>>>+4);|1117045|b首先被符号扩展为整数-15+=+0xfffffff1，然后向右移位为0x0fffffff，并通过转换为0xff将其截断为byte。|1117046|你可以做(b+&+0xff)+>>>+4来得到想要的效果。|1117047|entityMap^0|P|3|0|0|0|1|0|0|0|1|B|G|Z|A|1G|4|1P|4|0|0|0|1|B|G|Z|A|1G|4|1P|4|0|4|G|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@$9|13|A|14|B|C]]|D|@]|E|$]]|$1|M|3|N|5|H|7|15|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]|$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|H|7|1H|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|1I|8|@$9|1J|A|1K|B|C]|$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|U|3|V|5|6|7|1T|8|@$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|W|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]]|X|$]]

The problem is that all arguments are first promoted to <code>int</code> before the shift operation takes place:

<pre><code>byte b = (byte) 0xf1;
</code></pre>

<code>b</code> is signed, so its value is -15. 

<pre><code>byte c = (byte) (b &gt;&gt; 4);
</code></pre>

<code>b</code> is first sign-extended to the integer <code>-15 = 0xfffffff1</code>, then shifted right to <code>0xffffffff</code> and truncated to <code>0xff</code> by the cast to <code>byte</code>.

<pre><code>byte d = (byte) (b &gt;&gt;&gt; 4);
</code></pre>

<code>b</code> is first sign-extended to the integer <code>-15 = 0xfffffff1</code>, then shifted right to <code>0x0fffffff</code> and truncated to <code>0xff</code> by the cast to <code>byte</code>.

You can do <code>(b &amp; 0xff) &gt;&gt;&gt; 4</code> to get the desired effect.

blocks|key|902387|text|Java试图通过定义两个不同的移位操作符来避免显式地支持无符号基本类型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902388|这个问题谈到了无符号右移位，但示例同时做了(有符号和无符号)，并显示了有符号移位的值(>>)。|902389|对于无符号移位(>>>)，您的计算将是正确的。|902390|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Java tries to skimp on having explicit support for unsigned basic types by defining the two different shift operators instead. 

The question talks about unsigned right shift, but the examples does both (signed and unsigned), and shows the value of the signed shift (>>).

Your calculations would be right for unsigned shift (>>>).

blocks|key|902450|text|字节b=(字节)+0xf1；|type|unstyled|depth|inlineStyleRanges|entityRanges|data|902451|if+(b<0)|902452|D=(字节)(b>>1)&(字节)(0x7F))+>>>3)；|902453|否则|902454|D=(字节)(b>>>4)；|902455|首先，检查该值:如果该值为负数。做一次右移位，然后&+0x7F，它将变为正数。然后你就可以很容易地做剩下的右移位(4-1=3)。|902456|如果值是正数，用>>4或>>>4进行右移位。这不会对结果造成任何影响，也不会有任何右移问题。|902457|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

byte b=(byte) 0xf1;

if (b&lt;0)

d = (byte) ((byte) ((byte)(b>>1)&amp;(byte)(0x7F)) >>>3);

else 

d = (byte)(b>>>4);

First, check the value: 
If the value is negative. Make one right shift, then &amp; 0x7F, It will be changed to positive. then you can make the rest of right shift (4-1=3) easily.

If the value is positive, make all right shift with >>4 or >>>4. It does'nt make no difference in result nor any problem of right shift.

Consider the following snip of java code

<pre><code>byte b=(byte) 0xf1;
byte c=(byte)(b&gt;&gt;4);
byte d=(byte) (b&gt;&gt;&gt;4);
</code></pre>

output:

<pre><code>c=0xff
d=0xff
</code></pre>

expected output:

<pre><code>c=0x0f
</code></pre>

how?
as b in binary <code>1111 0001</code>
after unsigned right shift <code>0000 1111</code> hence <code>0x0f</code> but why is it <code>0xff</code> how?

Behaviour of unsigned right shift applied to byte variable

Java

考虑下面的java代码片段byte b=(byte) 0xf1;byte c=(byte)(b>>4);byte d=(byte) (b>>>4);输出：c=0xffd=0xff预期输出：c=0x0f多么?在无符号右移位之后，作为二进制1111 0001中的b，因此是0x0f，但是为什么是0xff？

问应用于字节变量的无符号右移的行为
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问应用于字节变量的无符号右移的行为EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问应用于字节变量的无符号右移的行为
EN