这可能是这么简单的问题，为什么我们更喜欢byte []对int []或long []？
我知道byte是java基本类型，属于integer家庭和需要的内存空间1 byte。当我们处理二进制数据时（例如当我们读/写文件时），我们将数据存储到byte array并且我们进行操作，这里我的疑问是当我们有其他基本类型时，如short,int为什么我们更喜欢byte[]？任何人都可以澄清
在此先感谢。
实际上，使用字节数组（实际上忽略无法使用8位数据块的计算机;我甚至不知道这些日子在实际使用中是否存在这样的计算机），保证始终表示数据字节相同的顺序，而不管平台，编程语言或框架。鉴于存储或传输格式的知识，您可以将其转换为您当前平台等使用的任何内部格式。例如，我不相信在Alpha CPU上运行的用C++编写的应用程序将以与运行在Intel上的.NET应用程序一样写出UInt32（更不用说Java如何）的相同方式写出unsigned long在IBM z10上运行可能会处理64位long的较低32位，或者PIC程序集可能会处理在I/O端口抛出一个32位值）。如果你使用纯字节进行工作，这就成了一个不必要的问题：无论你读或写的字节序列，你都必须翻译字节序列，但是你会知道如何做到这一点。它是明确定义的。
如果您通过套接字发送数据，将其保存到文件中，或以其他方式在空间或时间上传输它，请使用字节数组保证接收者完全看到发送或保留的内容。然后由接收者决定（注意“收件人”可能是你自己的应用程序的文件“加载”代码，而“发件人”可能是“保存”到文件的代码）对字节序列做一些有用的事情发件人是从其原生格式发生的。
如果您使用的是非字节类型，则需要通过其他方式保证字节顺序，因为根据平台等等的不同，字节可能会以不同的顺序进行解释。例如，您需要指定（无论是您自己还是通过引用框架的规范）持久化多字节整数形式是使用大端还是小端。
流如文件和套接字被建模为字节，即byte []。有一些文件格式实际上是16位值或32位值等，但这些是本地只是字节。
常见用法中
许多类型的应用程序中使用的信息可表示在八个或更少的位，并且处理器设计者优化这个常见的用法。主流商业计算体系结构的普及有助于无处不在地接受8位大小。
引用如果你有一个100MB的文件，并读入的int数组，你需要的内存400MB（如果你读一个字节到每一个元素 - 你能包4个字节整合到一个int中，但以这种方式处理单个字节将非常困难）。因此，直接存储效率是我说的一个原因，因为字节是当今几乎所有计算机系统的基本最小可寻址内存单元。
为什么你需要400 MB的内存来读取100 MB的文件作为一组'int'？假设一个32位的int，只需要在每个int中读取四个字节。内存使用率然后出来相同。当然，如果你将每个* byte *读入一个'int'，这是一个不同的问题，但是你仍然在处理字节，只是在内部将它们放在更宽的类型中。 –
是的，我刚刚编辑。如果你将4个字节打包到一个int中，那么使用单个字节会变得有点头疼？ :) –
@WayneUroda你的意思是我们甚至可以使用int []和long []。如果存储不是问题？ – MaheshVarma
字节是二进制传输大小的度量单位。如果你不使用字节，那么，例如，哟不能可靠地发送1字节的消息，读取3字节的文件等。
另一个因素是像utf8这样的协议，其中数据序列未在固定大小的字节边界。
不可否认，UTF-8不再是一个协议，而是SMTP是数据编码还是WWW是操作系统。 :) –
我不明白如何使用字节[]有助于如果你需要发送一个'int'或'double'你只需要自己做字节顺序，并且你有同样的问题。 –
@PeterLawrey如果您可以限制自己指定字节顺序，并让任何使用不同字节顺序的人执行所有移位操作，则不是问题。字节顺序规范可以是隐式的（参考框架等）或明确的，但它需要在那里。如果在将数据写入到任何地方之前将其转换为byte []，并且性能并不重要（因为承认这样做需要非零时间），那么您确切知道字节顺序只是查看代码写出来。如果你需要架构之间的兼容性，这可能是一个重点。 –
@MichaelKjörling你的意思是除了字节，所有其他的原始类型都被转换（修改字节格式）为框架特定的字节格式？ – MaheshVarma