在Java中，我只是將文件讀入ByteBuffer。當我開始檢查以確保ByteBuffer包含正確的字節時，我注意到它有大部分正確的開始和結束字節，除了第三個字節，它有-117，而不是emacs所說的應該是139（以8進制8b -模式）。是什麼賦予了？這與Big/Little Endian有什麼關係..？從文件讀取字節後，大部分都是正確的，除了1是錯誤的和否定的
只要是明確的，根據emacs的前四個字節應該是：
1F：8B：08：00，其等於31 139 8 0
和我的Java得到：
31 -117 8 0
任何想法？
Java byte已簽名，因此它的範圍是-128..127而不是0..255。考慮到這一點，你的字節是正確的。如果該字節的無符號值爲X，則帶符號值爲(X - 256) - 因此，對於139，帶符號值爲139 - 256 = -117。
是否意味着0-127是相同的兩個（一個Java 0 ==其他0），但在128之後的其他所有東西對應於一個負的java字節？ – sepiroth 2009-08-27 22:50:51
是的，確切地說，我編輯了這個問題以詳細說明轉換。請參閱http://en.wikipedia.org/wiki/Two's_complement瞭解更多信息。 – 2009-08-27 22:51:53
Java的整數類型（包括byte）是有符號：它們的範圍從-128到127，而不是像你所期望的那樣從0到255。高位爲1（1 ### ####）的任何數字都是負數。
這是一個有點切的，但如果你試圖用符號字節工作，下面可能是有用的。
由於大多數業務將推動一個Java byte到int —保留符號和幅度—這是很常見的，以掩蓋掉的高位，這樣的：
/* Convert two bytes from an array to a 16-bit, unsigned value. */
int val = (b[idx] & 0xFF) << 8 | (b[idx + 1] & 0xFF);
之前或將&運營商（和大多數其他運營商），byte被擴大到int（或甚至long，取決於上下文）。所以一個有符號的字節值0xFF被轉換爲一個有符號整數值0xFFFFFF。
但通常做位運算的時候，意圖將每個字節爲一個無符號的值，因此byte0xFF（-1）應該只是在int0xFF（255）。與0xFF掩蓋完成此。
代碼請...需要....代碼 – Tom 2009-08-27 22:48:47
下面的人沒有:( – sepiroth 2009-08-27 22:51:25