parsing - AT+CMGL指令异常消息如何处理

Question

我有一些代码(顺便说一句，在 .net 中，但我认为这不重要)通过插入 Windows 7 PC 的 USB 端口的 GSM 调制解调器发送和接收 SMS 消息(使用 AT 命令发送到虚拟串行端口)。

它通常工作正常(因为我可以理解大部分传入的消息)但是当我发出 AT+CMGL 命令时，我经常收到一条不是我期望的消息看看，或者我可以弄清楚它是什么。

这是一个例子(我改变了 address 和 body 的值，因为我不知道这条消息是否包含任何我不想公开的信息，但我保持值的长度相同并放入指示消息的字符):

+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 开头)所以看起来不像电话号码(至少在我对电话号码的有限理解范围内)。因此，我想知道这是否是来 self 的电信提供商的消息。

其次，消息的正文看起来是十六进制值，所以它可能是一些二进制数据。所以，我的问题是……

有什么方法可以解码这些消息以弄清它们到底是什么？

(我试过将正文加载到一个二进制数组中，然后将其转储到带有 .jpg 扩展名的磁盘上，以查看它是否是图像，但当然这没有用)。

感觉这可能是参数设置问题 - 是否有某种标题可供我阅读以了解是否可能是这种情况？

Answer 1

是的，可以解析这些数据，您对这是十六进制数据的怀疑也是正确的。这可能是由于字符编码造成的。

我刚刚写了an answer关于 UCS-2 字符编码和 AT+CMGL十六进制编码将始终如此。从阅读开始。然后阅读 27.005有关 <data> 的详细信息格式，看看您是否能弄清楚如何检测它何时是十六进制编码。

如果您无法弄清楚，或者无论如何，您可以将字符编码设置为 "HEX"始终获取十六进制编码的数据，尽管这并不能神奇地解决您的所有问题，因为仅仅因为您总是会获取十六进制编码的数据，您仍然需要知道您收到的数据的确切字符编码，如果这可以改变您必须知道什么时候...

所以也许使用 UCS-2 不是一个坏主意，因为这样您就知道所有接收到的数据都将采用完全相同的格式和编码。