这个问题源自于我一年前做加解密的时候遇到的问题，结果最近IOS同学在做加解密时竟然遇到同样的问题，特记录一下也给各位普及一下，防止进入死胡同出不来。
一般我们在处理二进制数据时会直接读到二进制数据，自然也不会考虑到编码的问题，但在Web的海洋当中二进制传输发展较慢（主要是二进制数据处理支持较慢），所以在传输数据时习惯采用俗称的编码方式传输，这块就会出现一个问题：编码成什么样的内容？无非就是编码成字符串形式，这样就形成了字符串与二进制数据的一个对应关系，但其中有一种比较蛋疼的编码方式是直接将二进制数据本身使用字符串进行表示，比如00100011B=>23H=>”23″,11001101B=>ABH=>”AB”; WTF，这种很容易误导，以为将字符串直接转换成二进制就可以，比如前端同学会采用：

let someone = new Blob("AB", {type: "application/octet-binary"});
const fr = new FileReader();
fr.addEventListener('load',(e)=>{
    console.log(e.target.result);//retulr is ArrayBuffer
    //...do something
});
fr.readAsArrayBuffer(someone);

IOS同学可能会用：

NSData * data; 
NSString *result = [[NSString alloc] initWithData:data  encoding:NSUTF8StringEncoding]; 

直接坑死，关键地方在于这两种处理方式都是采用了字符串编码方式处理，读取的是编码后的二进制数据，也就是说是原始二进制存储数据。这种存储方式其实就和编码关系很大，如果给你传递的是GBK方式的字符串，那对应的数据又不一样了，这种直接处理的思维很容易让人陷在其中无法走出，只需要将字符串当成十六进制的数字处理，这个问题就直接解决了：

//”AB”=>ABH=>11001101B