2

我有一些代码（顺便在 .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很长并且不包含a +（或开头00），因此看起来并不像电话号码（至少在我对电话号码的有限理解范围内）。因此，我想知道这是否可能是来自我的电信提供商的消息。

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

有什么方法可以解码这些消息以找出它们的实际含义吗？

（我尝试将主体加载到二进制数组中并将其转储到带有 .jpg 扩展名的磁盘中，以查看它是否是图像，但当然这不起作用）。

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

4

2 回答 2

2

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

我刚刚写了一个关于 UCS-2 字符编码的答案AT+CMGL，以及十六进制编码的情况。从阅读它开始。然后阅读27.005以了解有关<data>格式的详细信息，看看您是否可以弄清楚如何检测它何时是十六进制编码的。

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

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

于 2013-04-06T22:07:34.917 回答
0

我不确定我解决您的问题的正确程度，但我猜您的调制解调器设置不支持您收到消息的格式。为消息启用了哪种格式？文本还是PDU？

AT+CMGF 命令将返回支持的消息格式。AT+CMGF=1 设置为文本格式。

于 2012-09-12T11:27:13.307 回答