Python 2.7，AT命令响应，奇怪的HEX

Question

通过执行 USD AT 命令，我得到以下响应:

00520030002E00300030002000610069007200740069006D0065002C0020003000200053004D005300200061006E0064002000300020004D00420020006F006600200064006100740061002E0020004400690061006C0020002A003100340031002A0031002300200066006F0072002000640065007400610069006C0073002E00200057006F005700210020005500730065002000520037002000610069007200740069006D006500200074006F00200067006500740020005200350035002B00310030004D0042002E004400690061006C0020002A003100330030002A0035003000310023

产生:

' R 0 . 0 0 a i r t i m e , 0 S M S a n d 0 M B o f d a t a . D i a l * 1 4 1 * 1 # f o r d e t a i l s . W o W ! U s e R 7 a i r t i m e t o g e t R 5 5 + 1 0 M B . D i a l * 1 3 0 * 5 0 1 #'

运行后:

ascii = rawHex.decode("hex")

我发现每个“有效”十六进制数字后面都有一个额外的空字符。因此，它生成的不是 52，而是 5200

我确实设法通过执行以下操作删除每个有效的十六进制数字后面的 00:

rawHex = ''.join( [ rawHex[i:i+2] for i in range(2,len(rawHex),4)] )
ascii = rawHex.decode("hex")

这会产生正确的结果:

'R0.00 airtime, 0 SMS and 0 MB of data. Dial *141*1# for details. WoW! Use R7 airtime to get R55+10MB.Dial *130*501#'

所以我的问题:我不知道为什么这样做，这是一个我还不知道的标准吗？

Answer 1

您似乎有UTF-16 - 编码数据，采用大端顺序，每个字符使用 2 个字节进行编码。对于 Latin-1 范围内的任何内容(Unicode 代码点 U+0000 到 U+00FF)，最高有效字节始终为 00；您的示例数据仅包含 ASCII 范围内的字符，但我不认为情况总是如此。

您可以使用 utf-16-be 编解码器直接对其进行解码，而无需删除空字节:

>>> rawhex = '00520030002E00300030002000610069007200740069006D0065002C0020003000200053004D005300200061006E0064002000300020004D00420020006F006600200064006100740061002E0020004400690061006C0020002A003100340031002A0031002300200066006F0072002000640065007400610069006C0073002E00200057006F005700210020005500730065002000520037002000610069007200740069006D006500200074006F00200067006500740020005200350035002B00310030004D0042002E004400690061006C0020002A003100330030002A0035003000310023'
>>> rawhex.decode('hex')
'\x00R\x000\x00.\x000\x000\x00 \x00a\x00i\x00r\x00t\x00i\x00m\x00e\x00,\x00 \x000\x00 \x00S\x00M\x00S\x00 \x00a\x00n\x00d\x00 \x000\x00 \x00M\x00B\x00 \x00o\x00f\x00 \x00d\x00a\x00t\x00a\x00.\x00 \x00D\x00i\x00a\x00l\x00 \x00*\x001\x004\x001\x00*\x001\x00#\x00 \x00f\x00o\x00r\x00 \x00d\x00e\x00t\x00a\x00i\x00l\x00s\x00.\x00 \x00W\x00o\x00W\x00!\x00 \x00U\x00s\x00e\x00 \x00R\x007\x00 \x00a\x00i\x00r\x00t\x00i\x00m\x00e\x00 \x00t\x00o\x00 \x00g\x00e\x00t\x00 \x00R\x005\x005\x00+\x001\x000\x00M\x00B\x00.\x00D\x00i\x00a\x00l\x00 \x00*\x001\x003\x000\x00*\x005\x000\x001\x00#'
>>> rawhex.decode('hex').decode('utf-16-be')
u'R0.00 airtime, 0 SMS and 0 MB of data. Dial *141*1# for details. WoW! Use R7 airtime to get R55+10MB.Dial *130*501#'

在大多数情况下，UTF-16 编码的数据包括 Byte Order Mark (BOM)一开始，这实际上只是 U+FEFF ZERO WIDTH NO-BREAK SPACE字符，它告诉解码器解码时使用什么字节顺序。打印时，该字符基本上是不可见的。

您可能在这里省略了它，但如果您的数据流以字节 FE FF 开头，那么这肯定会确认您拥有大端 UTF-16 数据。如果流以 FF FE 开头，那么您将拥有 little-endian UTF-16(字节顺序交换)，并且还会在错误的边界处剪切样本。

如果 BOM 存在，那么您不必手动指定字节顺序；使用 utf-16 解码就足够了:

>>> ('FEFF' + rawhex).decode('hex').decode('utf-16')
u'R0.00 airtime, 0 SMS and 0 MB of data. Dial *141*1# for details. WoW! Use R7 airtime to get R55+10MB.Dial *130*501#'