Javascript window.atob -> HEX - 结果与预期不同答案

【问题标题】：Javascript window.atob -> HEX - different result than expectedJavascript window.atob -> HEX - 结果与预期不同
【发布时间】：2017-06-12 02:25:33
【问题描述】：

我有一个BMP 图像，我需要通过TCP/IP 将其发送到设备。我们公司已经有C 库，可以处理这个问题，但我需要用JavaScript 来做。不幸的是，我无法访问库的源代码，也无法访问设备系统。

这是示例图像的Base64 字符串（黑白复选标记）：

Qk2+AAAAAAAAAD4AAAAoAAAAIAAAAACAAAAABAAEAAAAAAAAAAAADEDgAAxA4AAAAAAAAAAAAAAAAAP///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==

我使用window.atob 并将其编码为十六进制。我使用这个 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 P>

库正确发送完全相同的图像（设备接受消息）。这是它的样子（从日志中复制）：

be00424dbe000000000000003e000000280000002000000020000000010001000000000080000000c40e0000c40e0000000000000000000000000000ffffff00ffffffffffe1ffffffc0ffffff807fffff007ffffe003ffffc003ffff8001ffff0000fffe0000fffc80007ff9c0007ffbc10101003ff7e3001ff7f7801ffbef800ffbcfc007fc3fe007ffffe003fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87 P>

这就是我需要在我的 JavaScript 中从 Base64 获取的内容。甚至可能吗？还是我错过了什么？

该库的文档说图像必须是 2B 二进制数据（Little Endian）。我不明白。我应该以其他方式对图像进行编码吗？

【问题讨论】：

看起来像一个“字节顺序”问题
“库说图像必须是 2B 二进制数据” 这个库叫什么（链接）？以前从未听说过“2B 二进制数据”...

标签： javascript base64 hex byte

【解决方案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 不是。

【讨论】：

【解决方案2】：

这是一个示例图像的 Base64 字符串（黑白复选标记）...
它给了我这个结果，这几乎是预期的结果：

424dbe00000003e0002800020000200001010000080000c4e00c4e00000000000000ffffff0ffffffffffe1ffffffc0ffffff807fffff07ffffe03ffffc03ffff801ffff00fffe00fffc807ff9c07ffbc103ff7e301ff7f781ffbef80ffbcfc07fc3fe07ffffe03fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87

“几乎是预期的结果”是什么意思？，这些字节构成了下面的图像（另存为.bmp）。
您期望的 "a black&white checkmark" 图片：

PS：

正确的 .bmp 文件有 190 个字节。您的库版本（从日志中复制）给出 194 字节的结果。

该库的字节版本有一个开头的 2 字节 short 用于文件大小。
那是 BE 00（= 190 当读取为 00 BE 的字节序时）后跟位图文件字节的其余部分（ 190 总字节）。这使得总共 190 个字节 + short 的 2 个字节。然后它从位置 114 开始添加这两个神秘的 10 和 10 字节。总共 194 个字节。

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

【讨论】：