Why your SMS is garbled or split: GSM 7-bit, UCS-2 and the DCS byte

2026-07-14 · smpp, encoding, sms

Two symptoms, one root cause: a message that arrives as gibberish, or a 90-character message that mysteriously bills as two. Both come down to character encoding and the data_coding (DCS) byte.

GSM 7-bit vs UCS-2

The GSM 03.38 default alphabet packs 160 characters into a single SMS by using 7-bit septets. But it only covers a specific character set. The moment you include a character outside it — many accented letters, most emoji, non-Latin scripts — the whole message switches to UCS-2 (UTF-16), which fits only 70 characters per segment.

That’s the “why did my 90-char message split” surprise: one emoji forced UCS-2, halving your per-segment budget.

The extension table trap

A handful of characters — { } [ ] ~ | \ ^ € — are representable in GSM 7-bit, but each costs two septets because they live in an extension table behind an escape. A message full of curly braces counts against your 160 faster than you’d think.

Read the DCS byte

The data_coding field decides the alphabet. Decode it — the SMPP PDU decoder breaks it down:

• 0x00 — SMSC default (usually GSM 7-bit, but SMSC-specific — the #1 interop ambiguity).
• 0x08 — UCS-2.
• 0x03 — Latin-1.
• The 0xFx group carries a message class (flash SMS = class 0).

When text looks wrong, the usual fix is a mismatch between the DCS the sender set and the alphabet the message was actually encoded in.