我正在编写基于所有ETSI GSM文档处理SMS PDU的代码。我需要问一件事。 PDU包含用户数据长度字段，后跟用户数据。根据GSM 03.40，UDL字段是当使用未压缩的GSM默认字母表时用户数据的septets的数量。但是，它还说，当数据被压缩时，UDL就是用户数据的八位字节数。
参见引号：
如果使用TP编码TP用户数据 GSM 7位默认字母表，TP 用户数据长度字段给出 整数表示的数字 TP用户数据中的septets 要跟随的领域。
[...]
如果TP用户数据使用编码 压缩的GSM 7位默认字母表 或压缩的8位数据或压缩 UCS2 [24]数据，TP用户数据 长度字段给出整数 表示八位字节的数量 在TP用户内压缩之后 要遵循的数据字段。
问题在于，当压缩7位数据并且压缩用户数据的八位字节数是7的倍数时，您不知道最后一个八位字节中的最后7位是填充位还是真正的性格。即压缩打开时，7个八位字节可能包含7或8个7位字符。当UDL字段是八位字节的数量时，你怎么知道这7个八位字节是否包含7或8个字符？如果UDL包含septets的数量，一切都会很清楚，对吧？那么我误解了文档还是真的以这种方式工作？
有人可以解释一下它是如何运作的吗？提前谢谢！
答案 0 :(得分：2)
如您所知，创建彩信需要您在短信之前添加UDH。 UDH成为有效负载的一部分，从而减少了每个段可以发送的字符数。
由于它已成为您的有效负载的一部分，因此需要确认您的有效负载数据要求 - 即7位。然而，UDH是8位，这显然使事情变得复杂。
以下面的UDH为例（它是串联消息的UDH）：
050003000302
这总共是6个八位字节 - 相当于48位。这一切都很好，但由于UDH实际上是SMS消息的一部分，您需要做的是添加更多位，以便实际消息在septet边界上开始。 septet边界是每7位，所以在这种情况下，我们将需要再添加1位数据以使UDH为49位，然后我们可以添加标准的GSM-7编码字符。
您可以从Here
了解更多相关信息答案 1 :(得分：1)
所以，问题在于我误解了数据编码方案字节中压缩位的含义。我认为它提到了7位字母表打包方法（其中至少有一个字符存储在一个字节内），但它指的是霍夫曼压缩。
因此，上面的问题有点愚蠢。对不起： - ）。