为什么byte不会在java中占用0xff？ [英] Why will byte not take 0xff in java?

问题描述

为什么java编译器不允许我将 0xff 放入字节， 0xff 是8位长，只是 byte 数据类型的大小。


有人可以解释为什么1有效，为什么有2无效？

Why will java compiler not let me put 0xff into a byte, 0xff is 8 bits long which is just the size of byte datatype.

Can someone explain why 1 works and why 2 does not ?

class a
{
        public static void main(String[] args)
        {
                // 1 :: results in error
                byte a = 0xff;          
                System.out.printf("%x\n",a);

                //2 :: works fine
                byte a = (int)0xff              
                System.out.printf("%x\n",a);
        }
}

编辑我看了回答声称0xff是255，怎么回事？是不是 1111 1111 ，是什么让0xff，-128或255或其他任何事情。为什么它不仅仅将它视为 1111 1111 而不是该字节的8位为1.

EDIT I read the answer claiming that 0xff is 255, how so ? Is it not 1111 1111, What makes 0xff, -128 or 255 or anything for that matter. Why will it not just treat it as 1111 1111 and not the 8 bits of that byte to 1.

推荐答案

Java byte 类型是一个8位有符号整数类型，其值在 -128 到 +127 。文字 0xff 代表 +255 ，超出该范围。

The Java byte type is an 8 bit signed integral type with values in the range -128 to +127. The literal 0xff represents +255 which is outside of that range.

在第一个示例中，您尝试将超出范围的值分配给 byte 。这是一个编译错误。

In the first example, you are attempting to assign a value that is out of range to a byte. That is a compilation error.

在第二个例子中，（byte）强制执行显式缩小转换，删除整数文字的高位...在字节变量中给出值 -127 。

In the second example, the (byte) cast is performing an explicit narrowing conversion, that removes the high order bits of the integer literal ... giving you the value -127 in your byte variable.

事实上，第一个例子的情况比这复杂一点。考虑一下：

In fact, the situation with the first example is a bit more complicated than that. Consider this:

byte a = 1;         // OK
int i = 1;
byte b = i;         // Compilation error
byte c = (byte) i;  // OK

在正常情况下，你不能指定 int 到字节没有强制转换。但是，如果赋值的值是文字，并且文字值在目标类型的范围内，则Java语言允许在不使用转换的情况下分配。文字的值隐含地从 int 缩小到 byte 。

Under normal circumstances, you cannot assign an int to a byte without a cast. However, if the value are assigning is a literal, and the literal value is within the range of the target type, the Java language permits the assignment without a cast. The literal's value is implicitly narrowed from int to byte.

JLS§5.2中对此进行了描述定义了可以在作业中执行的转化：

This is described in JLS §5.2 which defines the conversions that may be performed in an assignment:

如果缩小基元转换，则可以使用变量的类型是byte，short或char，常量表达式的值可以在变量的类型中表示。

正如您所看到的，这不是只是适用于文字。它适用于所有（编译时）常量表达式！

And as you can see, this doesn't just apply to literals. It applies to all (compile-time) constant expressions!

后续行动

我读了声称 0xff 255 ，怎么样？是不是 1111 1111 ，是什么让 0xff ， -128 或 255 或其他任何事情？

I read the answer claiming that 0xff is 255, how so? Is it not 1111 1111, What makes 0xff, -128 or 255 or anything for that matter?

文字 0xff 是类型 int 的整数文字。文字 0xff 的 int 实际上是 0000 0000 0000 0000 0000 0000 1111 1111 二进制或+255十进制。相比之下，文字 -1 的位模式为 1111 1111 1111 1111 1111 1111 1111 1111 。

The literal 0xff is an integer literal of type int. The int value of the literal 0xff is actually 0000 0000 0000 0000 0000 0000 1111 1111 in binary or +255 in decimal. By contrast, the literal -1 has the bit pattern 1111 1111 1111 1111 1111 1111 1111 1111.

为什么不将它视为 1111 1111 而不是该字节的8位1？

Why will it not just treat it as 1111 1111 and not the 8 bits of that byte to 1?

因为 0xff 是一个类型为<$ c $的整数文字C> INT 。它不是8位字面值，因为Java中不存在8位字面值。如JLS§3.10.1说：

Because 0xff is an integer literal with type int. It is not an 8-bit literal, because 8-bit literals do not exist in Java. As JLS §3.10.1 says:

整数文字的类型为 long 如果后缀为ASCII字母 L 或 l （ell）;否则其类型为 int （§4.2.1）。

"An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (§4.2.1)."

这篇关于为什么byte不会在java中占用0xff？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！