Re: Erorr In Compile PDU

John Henderson =E5=9C=A8 2008=E5=B9=B43=E6=9C=8826=E6=97=A5 =E6=98=9F=E6=9C=
=9F=E4=B8=89=E4=B8=8A=E5=8D=8810:17:37 [UTC+8] =E7=9A=84=E4=BF=A1=E4=B8=AD=
=E5=AF=AB=E9=81=93=EF=BC=9A
> As I tried to say in a previous post, you can decode this longer
> string as if it were all text, and throw away the first 7
> characters. What remains will be the actual 13-character text
> you want. Doing this will _automatically_ align the decode to
> the correct boundaries.

Hi John,
Thanks for explaining how to decode PDU SMS that UD containing UDH, this co=
nfused me for a long time.

I have a problem here, as you said "throw away the first 7 characters".
Is it because the length of UDH(0500033A0202) is 6 bytes (48bits), so a fil=
l bit needs to be added between UDH and SM to make SM starts from the septe=
t boundary? (the length of UDH now is 7 bytes(49 bits), so the first 7 char=
acters of the whole UD we decode are pseudo characters, meaningless)

If it is, as I know UDH can have different lengths, e.g.
1. 060804F42E0201
2. 080701030003080202
The length of the UDH in the first example is 7 bytes (56 bits), so I can d=
ecode the SM directly, or decode the whole UD and remove the first 8 charac=
ters.
In the second example, UDL is 9 bytes (72 bits), so there are 5 fill bits t=
o make UDH 77bits and then SM can start on septet boundary. So UDH uses 11 =
septets, after decoding the whole UD, I should remove the first 11 characte=
rs to get the real SMS content.

Do i understand correctly?