SMS PDU和用户数据长度
我正在编写基于所有ETSI GSM文档处理SMS PDU的代码。有一件事我需要问一下。 PDU包含用户数据长度字段，然后是用户数据。根据GSM 03.40，UDL字段是使用未压缩GSM缺省字母表时的用户数据的七位字节数。但是，它也表示，当数据被压缩时，UDL是用户数据的八位字节数。SMS PDU和用户数据长度
参见引号：
如果TP用户数据使用 GSM 7位默认字母编码，则TP 用户数据长度字段给出内的七重峰的数目 的 整数表示TP用户数据 字段。
[...]
如果TP用户数据使用 压缩GSM 7位默认字母表 或压缩8位数据或压缩 UCS2 [24]的数据，该TP用户数据 长度字段编码给出一个整数 表示在TP User 数据字段后面的八位字节数 后面的数字字段。
的问题是，当7位数据进行压缩和压缩用户数据的字节数是7的倍数，你不知道在最后一个字节的最后7位是否填写位或一个真实的角色。即打开压缩时，7个字节可能包含7个或8个7位字符。而当UDL字段是八位字节数时，你怎么知道这7个字节是否包含7或8个字符？如果UDL包含septets的数量，那么一切都会很清楚，对吧？那么我是否误解了文档，或者它是否真的以这种方式工作？
任何人都可以请解释我是如何工作的吗？提前致谢！
所以，我误解了Data Coding Scheme字节中压缩位的含义。我认为它提到了7位字母打包方法（其中至少一个字符存储在一个字节内），但它指的是霍夫曼压缩。
因此，上面的问题有点愚蠢。对不起:-)。
正如您已经知道的那样，创建MMS消息需要您在文本消息之前添加UDH。 UDH成为您的有效载荷的一部分，从而减少了您可以发送的每个段的字符数。
由于它已成为您的有效载荷的一部分，它需要确认您的有效载荷数据要求 - 这是7位。然而，UDH是8位，这显然使事情复杂化。
考虑的UDH以下作为一个例子（它是一个级联消息的UDH）：
050003000302
- 05是UDH（随后的5个八位字节）
- 00的长度是IEI
- 03是IEDL（3更多个八位字节）
- 00是基准（这个数目必须在每个级联消息UDH的相同）
- 03是消息的最大数量
- 02是当前消息编号。
这是总共6个八位字节 - 相当于48位。这一切都很好，但由于UDH实际上是SMS消息的一部分，因此您需要做的是添加更多位，以便实际消息从七个边界开始。一个七位边界是每7位，所以在这种情况下，我们将不得不再增加1位数据来使UDH为49位，然后我们可以添加标准的GSM-7编码字符。
您可以从Here更多了解此信息