為什么我的二進制補碼在 javascript 中給出了完全不同的結果

Question

我目前正在計算每個字節 32 位的字節緩沖區的校驗和，我必須為字節緩沖區的每個組件（某些位置除外）計算兩個校驗和，32 位 unint sum 和 32 位 uint xor。 總和按預期工作，但異或給了我一個奇怪的值。 我從 xor 得到的值是-58679487並且當應用二進制補碼時我得到58679487但是當將它轉換為十六進制值時它是0x037F60BF並且我正在尋找0xFC809F41 。 如果我將初始 xor 值 (-58679487) 放入 rapidtables 並將其從 dec 轉換為 hex，它會以十六進制顯示正確的二進制補碼值。 我究竟做錯了什么？

i=startAddress;
    while(i<buf.length){
        if(i !== chk1 && i!== chk2 && i!== chk3 && i!== chk4){
            file32Sumt += buf.readUint32BE(i);
            file32Xort ^= buf.readUint32BE(i);
                    i+=4;
            }else{
                console.log('cks location.'+ buf.readUint32BE(i).toString(16));
                i+=4;
                }
         }
//two's complement
console.log((~file32Sumt+1).toString(16));
console.log((~file32Xort+1).toString(16));

已經通過使用按位 NOT 運算符 (~) 然后加 1 來完成兩者的補碼，但似乎它不起作用。 還嘗試使用 Math.abs(file32Xort) 但得到了相同的結果。

Answer 1

不要否定。 用這個：

console.log((file32Xort >>> 0).toString(16));

file32Xort已經有正確的值，但是作為帶符號的 32 位 integer。您在這里需要的是相同值的無符號解釋。 number >>> 0是進行重新解釋的簡單方法。

另外，我認為你應該寫

file32Sumt = (file32Sumt + buf.readUint32BE(i)) >>> 0;

.. 或類似的東西，這次使用一些按位運算符（它不一定是無符號右移，但我認為這在這種情況下有意義）以防止總和變得太大（通過將其限制為32 位）並可能表現出浮點舍入。 file32Xort的計算已經使用了按位運算符，因此不需要像這樣的額外運算符，只是在最后將結果重新解釋為無符號。