我有一些代码（偶然在.net但我认为不重要）通过插入Windows 7 PC的USB端口的GSM调制解调器发送和接收SMS消息（使用AT命令发送到虚拟串口）。
它通常很好（因为我可以理解大多数进来的消息）但是当我发出AT+CMGL命令时，我得到的消息不是我期望看到的消息，或者那个消息我可以弄清楚它是什么。
这是一个例子（我已经更改了地址和正文的值，因为我不知道这条消息是否包含我不想公开的任何信息，但我保持值的长度相同并放入指示消息的字符）：
+CMGL: 0,"REC READ","7700000000000000000000",,"12/09/10,10:25:06+08"
0123456789ABCDEF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
+CMGL: 1,"REC READ","7700000000000000000000",,"12/09/10,10:25:07+08"
000000000000000000000000000000000000000000000000000000000000000000000000000000090000000000000000000000000000000000000000
OK
首先让我感到震惊的是address很长并且不包含+（或者从00开始）所以看起来并不像电话号码（至少在我有限的范围内）了解电话号码）。因此，我想知道这是否是来自我的电信提供商的消息。
其次，消息的主体看起来是十六进制值，所以它可能是一些二进制数据。所以，我的问题是......
有什么方法可以解码这些消息来弄清楚它们实际上是什么？
（我尝试将主体加载到二进制数组中并将其转储到带有.jpg扩展名的磁盘上以查看它是否是图像，但当然不起作用）。
这感觉它可能是参数设置 - 是否有某种标题我可以读出来查明是否是这种情况？
答案 0 :(得分：2)
是的，可以解析那些，你怀疑这是十六进制数据也是正确的。这可能是由于字符编码造成的。
我刚刚写了关于UCS-2字符编码的an answer和AT+CMGL，其中十六进制编码将始终如此。从阅读开始。然后阅读27.005以获取有关<data>格式的详细信息，以了解您是否可以弄清楚如何检测它是否为十六进制编码。
如果你没有弄清楚，或者在任何情况下，你可以将字符编码设置为"HEX"以始终获得十六进制编码的数据，尽管这并不会神奇地解决你所有的问题，因为你总是将获得十六进制编码的数据，您仍然需要知道您收到的数据的确切字符编码，如果这可能会有所不同，您必须知道...
所以也许使用UCS-2并不是一个坏主意，因为你知道所有收到的数据都是完全相同的格式和编码。
答案 1 :(得分：0)
我不确定我是如何正确解决您的问题，但我猜您的调制解调器设置不支持您收到消息的格式。为邮件启用了哪种格式？文字或PDU？
AT + CMGF命令将返回支持的消息格式。 AT + CMGF = 1设置为文本格式。