Javascript window.atob - > HEX - 予想外の結果

Question

私はBMPイメージを持っていますので、TCP/IPでデバイスに送信する必要があります。私たちは既にCライブラリを持っていますが、それはこれを処理できますが、私はJavaScriptでそれを行う必要があります。残念ながら、私はライブラリのソースコードやデバイスシステムにアクセスすることはできません。

これはサンプル画像（黒&白のチェックマーク）のBase64列である：

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 ==

私はwindow.atobを使用しており、それを16進数でエンコードしています。 、それは私にこの結果を与える

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); 

ほとんど期待される結果：私は、この機能を使用JS

424dbe00000003e0002800020000200001010000080000c4e00c4e00000000000000ffffff0ffffffffffe1ffffffc0ffffff807fffff07ffffe03ffffc03ffff801ffff00fffe00fffc807ff9c07ffbc103ff7e301ff7f781ffbef80ffbcfc07fc3fe07ffffe03fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87

ライブラリが正確を送信します同じイメージが正しく表示されます（デバイスはメッセージを受け入れます）。これは、（ログからコピーされた）のように、それがどのように見えるかです：

be00424dbe000000000000003e000000280000002000000020000000010001000000000080000000c40e0000c40e0000000000000000000000000000ffffff00ffffffffffe1ffffffc0ffffff807fffff007ffffe003ffffc003ffff8001ffff0000fffe0000fffc80007ff9c0007ffbc10101003ff7e3001ff7f7801ffbef800ffbcfc007fc3fe007ffffe003fffff401fffffbf9fffffbfcfffffdfc7ffffefe3ffffeff3fffff7f1fffffbf9fffffdfcfffffefdfffffefdffffff7bffffff87

だからこれは私が私のJavaScriptでBase64から取得するために必要なものです。それも可能ですか？または私は何かを逃していますか？

ライブラリのドキュメントでは、イメージは2Bバイナリデータ（リトルエンディアン）でなければならないと記載されています。私はそれを理解していない。イメージを他の方法でエンコードする必要がありますか？

Answer 1

正しいエンディアンを保証するために、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が含まれています。
00 BEのendianとして読まれたときにBE 00（= 190）であり、それに続く残りのビットマップファイルバイト（合計190バイト）です。これにより合計190バイト+ shortの2バイトとなります。次に、位置114から始まるこれらの2つの不思議な10と10バイトを追加します。合計は194バイトです。

私には...ライブラリーは既にきれいなイメージバイトを壊していますが、デバイスはそれを受け入れると言いますか？
"ほぼ予想通りの結果" 16進バイトも受け入れますか？