hex2bin / bin2hex / pack / unpack 的理解及应用

文本文件 / 二进制文件 / 二进制bit流

计算机在存储或传输数据时都是以 bit 流的形式(二进制),文本文件和二进制文件的主要区别就是在于文本文件是有字符集的,ascii/utf8/utf16 等,读取时会将二进制流解码成对应的字符集字符。而二进制文件则简单的将数据作为二进制流处理,使用文本编辑器打开时,ascii解码,1byte 1byte 的处理并,有的落在ascii可打印字符中的就显示,没有落在其中的就是我们看到的乱码了。

例如

存储

ascii 文本数据 hello 存储的二进制流如下
存储的是每个字符的 ASCII 码
01101000 01100101 01101100 01101100 01101111

读取

按 ascii 文本文件读取
会依次读取 1byte 然后输出 ascii 码表对应的字符
为了便于比较我们这里读取 4byte 的数据
01101000 01100101 01101100 01101100
h--------e--------l--------l-------
按二进制流文件读取

可以读取 4byte 作为 uint 解析
二进制:01101000 01100101 01101100 01101100
十进制:|------------1751477356-----------|

可以读取 2byte 作为 usint 解析
二进制:01101000 01100101 01101100 01101100
十进制:|-----26725-----| |-----27756-----|

所以,文本文件和二进制文件的不同之处是解析方式不同,文本文件需要按照自身字符集,截取相应的字节长度读取,ascii 1byte, utf8 英文 1byte/中文 3byte, unicode 2byte 的方式去一段段的读取解析,二进制文件的话并没有表征性的字符集,你可以按自己的需要解析,比如第1 byte位代表的什么(unsigned short int / short int / ascii?),第2~3 byte位代表的什么,第n~k byte位代表的什么。

因为 ascii 的 char 和 int 的存储方式本质一致的(C语言里 char 类型本质就是 int),所以用多字节可能更好理解。

 $chr) {
    echo sprintf("%08d", decbin(ord($char))) . ' ';
}
// result
11100110 10001000 10010001

所以,如果我们使用 utf8 字符集处理 11100110 10001000 10010001时,我们得到的是 “我”。

如果我们将其作为二进制文件处理的话得到的结果是int(15108241)数值。

hex2bin / bin2hex

其实这俩货让我迷惑了很久,很长一段时间我都不明白他俩到底有什么用,输出结果不难理解,还被同事的代码带过节奏,因为我看到他经常在发送数据前通过 bin2hex 转化一下再发送,我惯性的认为难不成可以压缩数据量?

而这一次,我很刻意的将 hex2bin写在了 bin2hex的前面。

hex2bin 打包

hex2bin(hexString)的作用是将字符串作为十六进制的模式进行处理,如何处理,"68656c6c6f"会被处理成"68" "65" "6c" "6c" "6f",然后转换成对应的二进制数据(注意:是二进制数据,不是二进制数据对应的二进制字符串,decbin 方法提供这一功能,将数据转换成二进制对应的字符串),"68"(注意是字符串 2bytes)转为二进制数值是 01101000(注意是数值 1byte),输出至终端其实就是h(1bytes)的,依次处理后,我们成功的将10bytes的字符串"68656c6c6f"转换成了5bytes的字符串"hello",只不过"hello"并不是我们真正需要的数据,虽然你对它很亲切。

不要被"hello"迷惑了,最初我看到它时很难把它和bin联系到一起。"hello"是你的编辑器对hex2bin后的二进制流进行处理时,把二进制流当做文本处理(它们是文本编辑器,自然会把数据作为文本处理),恰好能对应上可打印字符的ascii码,就显示了"hello",所以说文本和二进制文件底层都是bit流,看怎么处理了。

bin2hex 解包

bin2hex(binString)则是将待处理的数据的二进制bit串进行16进制转换,并返回相应的16进制形式的字符串,这里的bin是说会将其作为二进制流,转换成对应的十六进制流,然后再以对应的字符串方式返回。比如"h"二进制bit串01101000,对应的十六进制是 0x68,相应的字符串形式是"68",依次继续解包处理 "e" "l" "l" "o" 后得到的字符串就是"68656c6c6f"

所以我们如果想传输字符集在'0-9a-f'内的数据,可以使用 hex2bin打包数据至二进制流节省空间,然后传输完成后再通过bin2hex解包获得源数据。

hex2bin(hexString)/bin2hex(binString) 对应 pack("H*", hexString)/unpack("H*", binString)

pack/unpack

只要提供了socket编程的语言,肯定也同时提供了 pack/unpackpack/unpack的主要作用是方便我们将数据打包至二进制流,然后以二进制流的方式解包。

H 十六进制

将十六进制的字符串打包至二进制流字符串,这里有个很微妙的理解,比如字符串"68" 2bytes,如果作为十六进制则其对应的二进制是00110110,对应的ascii文本字符是"h" 1byte,传输后我们对h进行解包转为十六进制得到"68",这种打包-传输-解包的方式节省了一半的传输量。

比如我们有一串字符串数据"68656c6c6f",如果直接传输的话需要strlen("68656c6c6f") = 10 byte,你会发现这串数据完全符合十六进制模式,如果进行如下处理我们可以节省了一半的传输数据量。

以上功能可以用 hex2bin/bin2hex实现

其实你会发现作为打包传输的数据是hello,这里可能有些反客为主的惯性思维,因为大部分时间对我们有意义的数据是hello而不是 68656c6c6f,但在这里68656c6c6f才是我们需要的数据,打包后得到的hello反而是压缩传输的中间数据。

n 无符号16位整形大端序 / N 无符号32位整形大端序

n是无符号短整型,固定2bytes,可以将0 ~ 65536内的数值用固定2bytes表示,比如 "65536"用字符串表示需要5bytes,以 n 模式打包至二进制后只需要 2bytes,节省了传输空间。

N是无符号整形,固定4bytes,可以将0~4294967296内的数值用固定4bytes表示。

当然,可能你的数值字符串是"0~99"的时候节省空间的优点并不明显,但另一个优点一直存在,那就是长度固定,在一些协议传输时dataLen . data的包结构是很需要dataLen是固定字节的数据。

比如

// package struct
00000000 00000001 00110110
|---dataLen 1---| |data h|

我们取数据包 package 的前2bytes解包后得到的数值就是数据包消息体的长度,如上所示长度为 1,后面的data即为1bytes 'h'

tcp流式数据时是很必须的,因为如果没有包长度声明,发送端连续发送多条消息,可能会导致粘包,接收端没办法正确的拆分消息:msg1msg2msg3 可能会被拆分成 "msg" "1msg2ms" "g3"

而声明了包长度后,我们可以先读取固定长度的字节获取到消息体长度,再读取相应长度的消息体内容。

这样就可以灵活的解析流数据,在一些情况下还节省了空间。

其他模式大家可以参考: pack / unpack 参数详解

你可能感兴趣的:(粘包,打包,pack)