java - SMPP 提交长消息和消息拆分

Question

我们正在使用 SMPP cloud-hopper 库将长消息发送到 SMS gateway Innovativetxt.com，但当我们将长消息拆分为每个部分 140 字节时，似乎是这样。每条消息的字符数达到134个字符。

然而，行业标准是 GSM 编码长消息的每一部分都应包含 153 个字符。当我们通过 140 字节拆分时，我们只有 134 个字符是不是做错了什么？如果我们尝试提交大于 140 字节的消息，网关提供商会拒绝它，消息正文过大。

应将消息拆分为每条 153 个字符以发送到 SMSC，而不是通过每条 140 字节发送消息。

拆分长消息的最佳方法是什么？按消息大小，即 140 字节或消息字符计数？

任何人都通过 cloudhopper 或其他基于 Java 的库遇到过同样的问题，我们应该怎么做。

Answer 1

这是一个常见的混淆。你做的一切都是对的。消息长度可以是 160 个字符(7 位 GSM 03.38)、140 个字符(8 位拉丁文)、70 个字符(16 位 UCS-2)。注意:160 * 7 == 140 * 8 == 70 * 16。

当您拆分一条长消息时，总部件号和部件索引等附加信息存储在消息正文中，即所谓的用户数据 header (UDH)。这个标题也发生了。因此，对于 UDH，您留下了 153 个 GSM 字符(7 位)、134 个字符/字节(8 位)有效负载或 67 个 2 字节-unicode 字符(16 位)

另见 http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit

在您的情况下，对于 8 位的 Contatenated 消息，UDH 的长度为 6 个字节。

UDH结构

0x05: Length of UDH (5 bytes to follow)0x00: Concatenated message Information Element (8-bit reference number)0x03: Length of Information Element data (3 bytes to follow)0xXX: Reference number for this concatenated message0xYY: Number of fragments in the concatenated message0xZZ: Fragment number/index within the concatenated message

Total message length, bits: 160*7 = 140*8 = 1120UDH length, bits: 6*8 = 48Left payload, bits: 1120-48 = 1072

For GSM 03.38 you get 1072/7 = 153 GSM (7-bit) chars + 1 filling unused bit.For Latin you get 1072/8 = 134 (8-bit) chars.For UCS-2 you get 1072/16 = 67 (16-bit) chars.

如您所见，153 个 GSM 字符等于 134 个字节减去 1 位。可能这 134 个字符就是 Java 报告给您的。但是一旦你拆分了你的长文本消息，你最终会得到一个包含文本和 UDH 的二进制消息。并且您应该将消息视为二进制。我建议您从结果部分制作二进制转储并进行调查。