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个字节。

对我来说......库正在破坏已经很好的图像字节，但是你说设备接受它了吗？
它是否也接受“几乎预期的结果”十六进制字节？