听起来你遇到的是典型的字符编码不匹配问题，尤其是终端设备发送的短信很容易出现这类情况——毕竟不同设备/应用的默认编码设置五花八门。结合你说的「每个字符间插入奇怪字符」，大概率是UTF-16编码的内容被当成UTF-8解析了（比如UTF-16每个字符占2字节，UTF-8解析时会把高字节的\x00当成空字符显示出来）。下面给你一步步的排查和解决思路：

第一步：确认异常编码的类型 #

先拿到出问题的消息原始字节流（不要直接用解析后的字符串），可以用十六进制查看工具检查：

• 如果看到类似 48 00 65 00 6C 00 6C 00 这样的字节（对应"Hello"的UTF-16LE编码），那就是UTF-16被错误解析成UTF-8了；
• 如果是 00 48 00 65 00 6C 00 6C，则是UTF-16BE编码。

另外，也可以直接在你的接收代码里打印原始请求的字节内容，这是最准确的判断方式。

第二步：修复接收端的编码解析逻辑 #

原来的代码可能是硬编码使用UTF-8解码，没有考虑其他编码的情况。你可以修改逻辑，优先检测编码再解码：

示例（Python）： #

import chardet

def parse_sms_content(raw_bytes):
    # 自动检测编码
    detected = chardet.detect(raw_bytes)
    encoding = detected['encoding'] or 'utf-8'
    # 解码时忽略无法解析的字符，避免崩溃
    return raw_bytes.decode(encoding, errors='replace')

如果是Java环境，可以使用ICU4J库的CharsetDetector类做编码检测，逻辑类似。

第三步：验证Clickatell的显示问题 #

既然Clickatell的报告里也显示异常，说明终端用户发送的原始消息编码就不是标准的GSM-7或UTF-8（这两种是短信服务常用的编码）。你可以建议终端用户做以下检查：

• 检查手机的短信设置：有些设备可以手动选择短信编码，比如不小心改成了「UTF-16」而不是「自动」或「GSM」；
• 排查第三方短信应用：如果用户用的不是系统自带短信APP，可能是应用本身的编码处理有Bug；
• 特殊字符影响：如果消息里包含emoji或特殊符号，有些设备会自动切换编码，但切换过程中可能出现错误。

额外提示 #

如果你的服务需要兼容各种终端设备，最好在接收时同时支持GSM-7、UTF-8、UTF-16这几种常见编码，并且设置合理的错误处理策略（比如用replace代替默认的strict，避免因为编码错误导致整个插入数据库的流程失败）。

内容的提问来源于stack exchange，提问作者Brian Kleinfall