这是一个普遍的混乱。你做的一切都是正确的。消息长度可以是160个字符(7位GSM 03.38),140个字符(8位拉丁),70个字符(16位UCS-2)。注意:160 * 7 == 140 * 8 == 70 * 16.
当您拆分一条长消息时,像零件总数和零件索引这样的附加信息存储在消息体中,即所谓的用户数据头(UDH )。这头也发生。所以,用UDH就还剩下153个GSM字符(7位),134个字符/字节(8位)的有效负载或67 2字节-unicode字符(16位)
参见http://www.nowsms.com/long-sms-text-messages-and-the-160-character-limit
的UDH Continentated消息8位长度为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 message
0xYY: Number of fragments in the concatenated message
0xZZ: Fragment number/index within the concatenated message
Total message length, bits: 160*7 = 140*8 = 1120
UDH length, bits: 6*8 = 48
Left 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的二进制消息。你应该把这个消息当作二进制。我建议你从结果部分中进行二进制转储并进行调查。