Java _signed_ byte 基元类型在现实生活中有什么用途吗？

Question

由于某些莫名其妙的原因，byte 基元类型在 Java 中是有符号的。这意味着有效值为 -128..127，而不是通常的 0..255 范围，表示一个字节中的 8 个有效位（没有符号位）。

这意味着所有字节操作代码通常都会进行整数计算并最终屏蔽掉最后 8 位。

我想知道在现实生活中是否存在 Java byte 基元类型完全适合的场景，或者这只是一个完全无用的设计决策？

---

编辑：唯一的实际用例是本机代码的单字节占位符。换句话说，不能在 Java 代码中作为字节进行操作。

---

编辑：我现在看到一个地方，内部紧密循环需要除以 7（数字 0..32），因此可以使用字节作为数据类型来完成查找表，这样考虑到 L1 缓存使用情况，内存使用量可以保持较低水平。这不是指有符号/无符号，而是实际使用的情况。

Answer 1

Josh Bloch 最近在演示中提到这是该语言中的错误之一。

我认为这背后的原因是java没有无符号数字类型，而byte应该符合该规则。 （注意：char是无符号的，但不代表数字）

至于特定问题：我想不出任何例子。即使有示例，它们也会比 0..255 的示例少，并且可以使用掩码（而不是大多数）来实现

Answer 2

byte、short、char 类型大多无用，除非在数组中使用以节省空间。

Java 或 JVM 都没有对它们提供任何真正的支持。几乎所有对它们的操作都会首先将它们提升为 int 或 long。我们甚至无法编写类似的内容

short a=1, b=2;
a = a + b;  // illegal
a = a << 1; // illegal

那么为什么还要费心在 byte、short、char 类型上定义操作呢？

他们所做的只是偷偷地扩大转换，这会让程序员感到惊讶。

Answer 3

令人惊讶的是，我上周刚刚在 Java 中第一次使用了 byte，所以我确实有一个（尽管不寻常的）用例。我正在编写一个 本机 Java 函数，它可以让您在库中实现一个可以调用的函数通过Java。 Java 类型需要转换为本机语言中的类型，在本例中，C

函数需要采用字节数组，但是（当时完全忘记了 byte 类型）我让它采用了一个char[]。 Java 为 C 函数生成的签名将该参数的类型指定为 jcharArray，它可以转换为一堆 jchar，并在 中进行类型定义>jni.h 到 无符号短。当然，这不是相同的大小——它是 2 个字节而不是 1 个字节。这导致了底层代码的各种问题。将 Java 类型 byte[] 生成 jbyteArray，Linux 上的 jbyte 被 typedef 为 signed char >，这是正确的尺寸

Answer 4

对我来说，带有 8 位签名样本的数字化声音（或任何其他信号）似乎是唯一合理的例子。当然，处理此类信号并不需要有符号字节，并且可以争论 Java 字节是否“完美适合”。

我个人认为没有未签名是一个错误。不仅因为无符号字节/整数有更多用途，而且因为我更喜欢更强大的类型系统。如果能够指定负数无效并允许编译器检查和运行时异常以检查违规情况，那就太好了。

Answer 5

byte 在 Java Card 的 applet 开发中有着广泛的用途。由于卡片的资源有限，每一点记忆都非常宝贵。顺便说一句，卡处理器在处理整数值方面有限制。 int 类型支持是可选的，不支持 java.lang.String，因此所有整数操作和数据存储都是通过 byte 和 完成的短变量和数组。由于整数文字是 int 类型，因此应在整个代码中将它们显式转换为 byte 或 short 。与卡的通信通过 APDU 命令进行，该命令作为字节数组传递给小程序，该数组应分解为字节以解码命令类、指令和参数。查看以下代码，您会发现 byte 和 short 类型对于 Java Card 开发有多重要：

package somepackage.SomeApplet;

import javacard.framework.*;
import org.globalplatform.GPSystem;
import org.globalplatform.SecureChannel;

public class SomeApplet extends Applet {

    // Card status
    private final static byte ST_UNINITIALIZED     = (byte) 0x01;
    private final static byte ST_INITIALIZED       = (byte) 0x02;

    // Instructions & Classes
    private final static byte PROP_CLASS           = (byte) 0x80;     

    private final static byte INS_INIT_UPDATE      = (byte) 0x50;
    private final static byte INS_EXT_AUTH         = (byte) 0x82;

    private final static byte INS_PUT_DATA         = (byte) 0xDA;
    private final static byte INS_GET_RESPONSE     = (byte) 0xC0;
    private final static byte INS_GET_DATA         = (byte) 0xCA;


    private final static short SW_CARD_NOT_INITIALIZED       = (short) 0x9101;  
    private final static short SW_CARD_ALREADY_INITIALIZED   = (short) 0x9102;  

    private final static byte OFFSET_SENT = 0x00;
    private final static byte OFFSET_RECV = 0x01;
    private static short[] offset;

    private static byte[] fileBuffer;
    private static short fileSize = 0;

    public static void install(byte[] bArray, short bOffset, byte bLength) {
        new SomeApplet( bArray, bOffset, bLength);
    }

    public RECSApplet(byte[] bArray, short bOffset, byte bLength) {
        offset = JCSystem.makeTransientShortArray((short) 2, JCSystem.CLEAR_ON_RESET);
        fileBuffer = new byte[FILE_SIZE];

        byte aidLen = bArray[bOffset];
        if (aidLen== (byte)0){
            register();
        } else {
            register(bArray, (short)(bOffset+1), aidLen);
        }
    }

    public void process(APDU apdu) {
        if (selectingApplet()) {
            return;
        }
        byte[] buffer = apdu.getBuffer();
        short len = apdu.setIncomingAndReceive(); 

        byte cla = buffer[ISO7816.OFFSET_CLA];
        byte ins = buffer[ISO7816.OFFSET_INS];
        short lc = (short) (buffer[ISO7816.OFFSET_LC] & 0x00ff); 

        while (len < lc) {
            len += apdu.receiveBytes(len);
        }

        SecureChannel sc = GPSystem.getSecureChannel();
        if ((short)(cla & (short)0x80) == ISO7816.CLA_ISO7816) {
            switch (ins) {
                case INS_PUT_DATA:
                    putData(buffer, ISO7816.OFFSET_CDATA, offset[OFFSET_RECV], len);

                    if ((cla & 0x10) != 0x00) {
                        offset[OFFSET_RECV] += len;
                    } else {
                        fileSize = (short) (offset[OFFSET_RECV] + len);
                        offset[OFFSET_RECV] = 0;
                    }
                    return;

                case INS_GET_DATA:
                case INS_GET_RESPONSE:
                    sendData(apdu);
                    return;
                default:
                    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
            }

        }
        else if ((byte) (cla & PROP_CLASS) == PROP_CLASS) {
            switch (ins) {
                case INS_INIT_UPDATE:
                case INS_EXT_AUTH:
                    apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, sc.processSecurity(apdu));
                    return;
                default:
                    ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);
            }
        } else
            ISOException.throwIt(ISO7816.SW_CLA_NOT_SUPPORTED);
    }

    // Some code omitted

}

Answer 6

我认为是为了与short和int保持一致而进行签名的。

至于它是否被大量使用，它使“字节数组”的概念成为一种构造而不是原语。

这就是我所拥有的一切。 :)

Answer 7

在字数大于 8 位的机器上，如果您希望将大量适合 8 位范围的值存储到单个数组中，那么它会很有用，但通常使用它们并不是一个好主意，因为字节实际上是与 int 相比，要付出更多努力才能摆脱内存。

请记住，Java 是为非常小的消费设备（机顶电视盒）设计的。我预计如果它在小型 8 位微处理器上以这种方式使用，它会更有用，因为它完全适合字长，并且可以用于非常小规模的一般“数学”运算。

我认为使其签名的唯一原因是，与 int 交互的无符号字节可能有点令人困惑 - 但我不相信它比签名字节更令人困惑！

Answer 8

字节的大小是8位。字节大小有助于在执行写入文件或从文件读取等功能时处理输入和输出。考虑一个场景，您想要从键盘或任何文件读取输入。如果您使用“字节”数据结构，您就知道一次接收一个字符，因为大小为 8 位。因此，每次收到输入流时，您都知道您实际上一次收到一个字符。

Answer 9

当我为 J2ME 编写软件和游戏时，我经常使用它。在大多数 J2ME 设备上，资源有限，因此将关卡映射存储在字节数组中比将其存储在 int 数组中占用的资源更少。