在 java 中將 int 轉換為長度為 2 的字節數組的答案存在沖突

Question

我正在嘗試將整數轉換為 2 個字節，但我在網上看到一些相互矛盾的答案：

a[0] = (byte)(theInt & 0xFF);
a[1] = (byte)((theInt >>> 8) & 0xFF);

和

a[0] = (byte)((theInt >>> 8) & 0xFF);
a[1] = (byte)(theInt & 0xFF);

第一個似乎是更常見的答案（ 如何將 integer 拆分為 2 字節二進制？ ）。

但是，就我個人而言，第二個似乎效果更好。 如果我設置theInt = 10000 ，我會得到所需的{27, 10} 。 但是對於第一種方法，我得到了相反的{10, 27} 。

那么我反對流行的答案並使用第一種方法有什么風險嗎？ 我錯過了什么嗎？ 謝謝

Answer 1

如何對多字節數值（例如您在此處轉換的 16 位值）的字節進行排序的概念稱為“字節順序”。

Little Endian 是“首先發送最不重要的數據”的術語，這將是第一個片段。 （先發送“10”，然后發送“27”）。

Big Endian 是“首先發送最重要的數據”的術語，因此是第二個片段。

您會認為 Big Endian 是明智的（例如，它符合我們人類編寫事物的方式，也符合我們對字節內位的看法；128 以位為單位，是“10000000”——首先寫入最重要的數據，然后all)，而 Little Endian 是瘋了，想知道為什么 LE 的概念甚至存在。

主要原因是intel CPU架構是Little Endian，是非常流行的CPU架構。 如果您首先將值為 '1' 的 32 位 int 寫入某個 memory 地址，然后逐個字節地讀取它，那么您將按順序獲得：'1'、'0'、'0' 和 '0 ' out: Little Endian - 首先寫入最低有效字節。 如今，有了管道、微架構，誰知道要求英特爾處理器以 BE 形式寫出它可能並沒有真正慢，但它更多的是機器代碼，當然在過去，速度要慢得多。 因此，如果您試圖在兩台機器之間使用非常快的 pipe 相互通信，並且兩台機器都有英特爾芯片，那么如果您發送小端序，那么 go 會更快：這樣兩個 CPU 都只是復制，僅此而已，而在 BE 中發送則需要發送器芯片為它發送的每個 int 交換字節 1/4 和 2/3，並且接收器芯片應用相同的轉換，浪費周期。

因此，有時您會發現一個協議被定義為 LE。 那是..在這個擁有各種硬件的世界中目光短淺，您最終可能會同時擁有發送器和接收器，例如通過 ARM 芯片，或者更糟糕的是，涉及 10 個芯片（中間有一堆數據包檢查路由器)，可能所有這些都是。 但是現在您知道為什么 LE 作為一個概念確實存在。

由於現代硬件種類繁多，而且大多數其他 CPU 都是大端，幾乎所有的網絡協議通常都被定義為大端。 java 通常也是 Big Endian（大多數 API，例如IntBuffer和 co，讓您選擇您想要的 endian-ness，但是在它不可用的地方，或者在涉及默認值的地方，它是 big endian）。 UTF-8 等格式也被定義為大端。 當有疑問時，Big Endian 比 LE 更有可能成為預期的順序。

運行 android 器件的 ARM 芯片也是大端。

因此：只需使用 Big Endian（第二個片段）。

這只留下了一個謎：為什么您的鏈接問題的公認答案是“奇怪”的答案（Little Endian），為什么即使它沒有突出這一點，它也會得到這么多的支持？ 這個問題甚至專門詢問 Big Endian（它描述了它，沒有使用藝術術語，但是它描述了 BE）。

我不知道。 這是一個帶有復選框和 68 票的愚蠢答案。 神秘。

我盡了自己的一份力量，並否決了它。