Javascript window.atob - > HEX - 結果與預期不同

Question

我有一個BMP圖像，我需要通過TCP / IP將其發送到設備。 我們公司已經有了C庫，可以處理這個，但我需要在JavaScript中完成。 不幸的是，我無法訪問庫的源代碼，也無法訪問設備系統。

這是樣本圖像的Base64字符串（黑白復選標記）：

Qk2 + AAAAAAAAAD4AAAAoAAAAIAAAACAAAAABAAEAAAAAAIAAAADEDgAAxA4AAAAAAAAAAAAAAAAAAP /// WD ////// + H //// ////甲///的gH WB /// 4AP // // 8AD + AAF // // AAD GAA // yAAH / 5wAB / + 8EAP / fjAB / 394Af +++ AD / vPwAf8P + AH /// GA /// 9AH /// V5 /// 7 / P /// FX /// 7 + P + // / Z / // // 38F + / N /// 38 /// + / F /// V3 /// 97 //// HW ==

我使用window.atob ，我將其編碼為HEX。 我用這個JS函數：

function toHex(str) {
    var result = '';
    for (var i = 0; i < str.length; i++) {
        result += str.charCodeAt(i).toString(16);
    }
    return result;
}
var str = window.atob(base64img);
var result = toHex(str);

它給了我這個結果，這幾乎是預期的結果：

424dbe00000003e0002800020000200001010000080000c4e00c4e00000000000000ffffff0ffffffffffe1ffffffc0ffffff807fffff07ffffe03ffffc03ffff801ffff00fffe00fffc807ff9c07ffbc103ff7e301ff7f781ffbef80ffbcfc07fc3fe07ffffe03fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87

庫正確發送完全相同的圖像（設備接受該消息）。 這是它的樣子（從日志中復制）：

be00424dbe000000000000003e000000280000002000000020000000010001000000000080000000c40e0000c40e0000000000000000000000000000ffffff00ffffffffffe1ffffffc0ffffff807fffff007ffffe003ffffc003ffff8001ffff0000fffe0000fffc80007ff9c0007ffbc10101003ff7e3001ff7f7801ffbef800ffbcfc007fc3fe007ffffe003fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87

所以這就是我在JavaScript中從Base64獲得的東西。 它甚至可能嗎？ 或者我錯過了什么？

該庫的文檔說該圖像必須是2B二進制數據（Little Endian）。 我不明白。 我應該以任何其他方式編碼圖像嗎？

Answer 1

一種選擇是分別對每個字節進行編碼以確保正確的字節序。

 img = "Qk2+AAAAAAAAAD4AAAAoAAAAIAAAACAAAAABAAEAAAAAAIAAAADEDgAAxA4AAAAAAAAAAAAAAAAAAP///wD//////+H////A////gH///wB///4AP//8AD//+AAf//AAD//gAA//yAAH/5wAB/+8EAP/fjAB/394Af+++AD/vPwAf8P+AH///gA///9AH///v5///7/P///fx///7+P//+/z///38f//+/n///38///+/f///v3///97////hw==" str = atob(img) buf = [] function hex(str, pos) { return ('000' + (str.charCodeAt(pos) || 0).toString(16)).substr(-2); } for (var i = 0; i < str.length; i+= 4) { buf.push(hex(str, i+2)); buf.push(hex(str, i+3)); buf.push(hex(str, i+0)); buf.push(hex(str, i+1)); } console.log(buf.join('')) 

這與您想要的輸出完全不符，您確定它對應於給定的base64字符串嗎？

另一方面，您的初始輸出看起來更好， 424d是啟動BMP文件（ BM簽名）的正確字節，而be00則不是。

Answer 2

這是一個樣本圖像的Base64字符串（黑白復選標記）......
它給了我這個結果，這幾乎是預期的結果：

 424dbe00000003e0002800020000200001010000080000c4e00c4e00000000000000ffffff0ffffffffffe1ffffffc0ffffff807fffff07ffffe03ffffc03ffff801ffff00fffe00fffc807ff9c07ffbc103ff7e301ff7f781ffbef80ffbcfc07fc3fe07ffffe03fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87 

什么是“幾乎預期的結果”是什么意思？，這些字節使下面的圖像（另存為.bmp ）。
您預期的"a black&white checkmark"圖片：

PS：

正確的.bmp文件有190個字節。 您的庫版本（從日志中復制）給出了194個字節的結果。

庫的字節版本的文件大小為2字節的short 。
即BE 00 （當讀為00 BE endian時為= 190 ），然后是其余的Bitmap文件字節（總共190個字節）。 這使得總共190個字節+ 2個字節的short 。 然后它從位置114開始添加這兩個神秘的10和10個字節。總共194個字節。

對我來說......庫正在破壞已經很好的圖像字節，但是你說設備接受它了嗎？
它是否也接受“幾乎預期的結果”十六進制字節？