这个问题挺典型的——碰到的应该是发送端自定义的非标准编码规则，不是GSM 03.38或ASCII的直接映射。结合你给出的+6;91<06130→Holvi的样本，我整理几个可落地的排查方向，你可以一步步来：

1. 先从GSM协议的原始PDU数据入手，确认编码来源 #

首先要搞清楚这个奇怪的编码是发送端直接发过来的，还是你的modem/接收脚本在预处理时搞出来的：

• 用AT指令AT+CMGR=<短信索引>读取短信的原始PDU数据，PDU里的发送方ID是TP-OA字段，这个字段的编码是标准的（要么GSM 03.38，要么UCS2）。
• 把PDU的TP-OA字段转成原始字节序列，对比你收到的6;91<06130：
  • 如果字节序列和编码后的字符串完全对应，说明是发送端用了自定义编码；
  • 如果字节序列是正常的ASCII/UTF-8，那问题出在你的modem配置或接收脚本的预处理逻辑（比如误开启了某种字符转义、替换功能）。

2. 收集更多样本，逆向推导映射规则 #

你现在只有一个样本，很难确定规律，但如果能拿到更多编码-明文对（比如其他商家的发送方ID，比如PayPal、Stripe的编码和对应明文），就能快速破解规则：

• 先统计对应关系：你这里5个明文字符对应10个编码字符（去掉+前缀），大概率是每个明文字符对应两个编码字符；
• 把每个明文的ASCII码和对应的双编码字符做对比：
  比如你推测的6;=H、91=o、<0=l、61=v、30=i，把这些字符的ASCII值列出来：

  明文	ASCII	编码	编码字符ASCII
  H	72	6;	54, 59
  o	111	91	57, 49
  l	108	<0	60, 48
  v	118	61	54, 49
  i	105	30	51, 48

  可以尝试计算偏移、异或、组合运算：比如H的72 = (54 - 48)10 + (59 - 48)？610+11=71，差1；或者54 XOR 59 = 13，72 XOR 13=69（E），不对。如果多个样本都这样，可能就是发送端用了一张硬编码的替换表，这种情况下要么靠样本凑全，要么联系发送方要规则。

3. 排查modem配置和脚本的预处理逻辑 #

有时候问题出在自己的接收链路：

• 检查modem的AT指令配置：比如有没有开启AT+CSCS设置的非默认字符集？比如GSM是默认，如果你设成了IRA或者其他，可能会导致字符转换异常；
• 检查接收脚本：有没有对原始数据做过自动转义、字符替换？比如是不是脚本把十六进制的A换成了;，B换成了<？或者有没有误处理了控制字符？

4. 考虑发送端的自定义压缩/编码场景 #

很多支付机构、服务商会为了缩短发送方ID长度（因为短信发送方ID有字符数限制），用自定义编码：

• 比如把每个字母映射成两个可见字符（避免不可打印字符），或者用简单的替换表；
• 你猜的;、<是十六进制A-F的替代符，可以试试把编码里的;换成A，<换成B，得到6A91B06130，拆成字节6A、91、B0、61、30，转成ASCII是j‘°a0，不对，但如果是字节逆序？03160B19A6，转成ASCII也不对。可能是其他替换规则，比如;对应H的某个特征码？

最快捷的方式：联系发送方 #

如果这个发送方是Holvi（你说的正确内容），直接找他们的技术支持询问发送方ID的编码规则，这比自己逆向要快得多——毕竟这是他们自定义的规则，只有他们最清楚。

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