AT+CMGL
因此,您正在使用 AT 命令(或AT+CMGR
)读取收到的短信,对吗?我假设您正在以文本模式 ( AT+CMGF=1
) 阅读它。在返回的参数中,如果有的话,您的调制解调器会在前面<data>
插入一个额外的。\r
\n
信息文本响应AT+CMGL
被指定为"\r\n"
围绕消息内容,例如
...<CR><LF><data>[<CR><LF>...
,也许实现\n
者对最后一个单曲感到不舒服,并决定放弃它(或者它可能是一个错误?)。的插入是否\r
发生在 的任何位置\n
?
有趣的是,27.005 没有讨论如果<data>
包含会发生什么<CR><LF>
......在V.250中,如下所述:
5.7.3 测试命令的信息文本格式
一般来说,扩展语法命令返回的信息文本格式应在命令定义中指定。...请注意,DCE 可能会在非常长的信息文本响应中插入中间字符,以避免超出 DTE 接收缓冲区。如果包含中间字符,则DCE不应包含字符序列“0”(3/0、0/13)或“OK”(4/15、4/11、0/13),以免DTE出现错误检测这些信息文本响应的结束。
您的场景似乎不是太长的响应文本,但有趣的是 DCE(又名调制解调器)似乎可以<CR>
在感觉时相对自由地插入。
无论如何,如果我假设您在文本模式下阅读是正确的,我建议您尝试将字符集更改为十六进制 ( AT+CSCS="HEX"
)。这可能会使调制解调器在\r
插入(或可能不是)方面表现不同。如果不是,您可以尝试 UCS-2,它也会强制执行十六进制响应(请参阅此答案)。
如果这些都没有帮助,您可以更改为在 PDU 模式下阅读消息(例如AT+CMGF=0
)。这只是通过空中传输的每一位 SMS 消息的原始转储,如果调制解调器设法在其中插入任何额外的\r
字符,我会感到非常震惊。然后,您最终不得不在收到它之后对其进行解码(这不是微不足道的,寻找一些已经编写好的库),但至少它应该可以工作。