這可能是這麼簡單的問題，爲什麼我們更喜歡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