SMS encoding reference#

Use this reference to look up SMS character encodings, the number of characters that fit in single and concatenated messages, how each SMS trunk type delivers multipart messages, and how SMS fragments are billed.

GSM-7 and UCS-2#

The encoding of an SMS message determines which characters it can contain and how many characters fit in one message.

Encoding

Description

GSM-7

The standard 7-bit SMS alphabet. It covers Latin letters, digits, and common punctuation, and is used for most SMS.

UCS-2 (Unicode)

A 16-bit encoding required for characters outside the GSM-7 alphabet, such as Chinese, Arabic, or Cyrillic script. UCS-2 reduces the number of characters per message.

When you send SMS through an HTTP OUT trunk, DIDWW selects the encoding automatically. GSM-7 is used when every character in the message is supported by the GSM-7 alphabet. Otherwise, UCS-2 is used. Over SMPP, the data_coding parameter of each message specifies the encoding. See Data Coding Scheme (DCS).

Note

  • A single character outside the GSM-7 alphabet, such as an emoji, makes the whole message use UCS-2.

  • Most emoji are encoded as two 16-bit units (a surrogate pair). Each such emoji counts as two characters toward the UCS-2 limits.

  • Some characters, such as €, [, ], {, }, \, ^, ~, and |, belong to the GSM-7 extension table. Each of them uses the space of two characters.

Single-part and concatenated SMS limits#

A message that exceeds the single-SMS limit is sent as a concatenated (multipart) SMS. A User Data Header (UDH) is added to each part so the recipient’s device can reassemble the message. The header uses part of the space in each fragment, so each part holds fewer characters than a single SMS.

Encoding

Bits per character

Characters in a single SMS

Characters per part of a concatenated SMS

GSM-7

7

160

153

UCS-2 (Unicode)

16

70

67

Up to 255 parts can be combined to form one long message.

Reassembly by transport#

How an inbound multipart message reaches your system depends on the trunk type that delivers it.

Trunk type

Multipart message delivery

HTTP IN

DIDWW reassembles concatenated messages by using the UDH before it delivers them to your endpoint. Information about fragmentation is not transmitted. The maximum size of an inbound SMS message is 64 KB. See Technical details.

SMS to Email

DIDWW reassembles the parts and delivers the message as one email.

SMPP ESME

DIDWW delivers each part in a separate deliver_sm with a UDH in the short_message field. Your application must process the UDH and reassemble the parts. See SMPP message flow.

SMPP SMSC

DIDWW submits each part to your SMSC in a separate submit_sm with a UDH in the short_message field. Your SMSC must process the UDH and reassemble the parts. See SMPP message flow.

Fragment billing#

SMS billing is based on fragments, not on the message as submitted. When a long message is split into several fragments, each fragment is billed separately. Inbound SMS, outbound P2P SMS, and outbound A2P SMS are all charged per message fragment.

The number of fragments depends on the message length and its encoding. The following examples show how messages of different lengths are split and billed:

Example message

Encoding

Fragments (characters per fragment)

Billed as

160 GSM-7 basic-alphabet characters

GSM-7

1

1 SMS

200 GSM-7 basic-alphabet characters

GSM-7

2 (153 + 47)

2 SMS

70 Cyrillic characters

UCS-2

1

1 SMS

100 Cyrillic characters

UCS-2

2 (67 + 33)

2 SMS

To review the fragments of sent messages, see the Billed Fragments and Charged (USD) fields in the Outbound SMS logs, or the fragments_sent attribute of the status callback. For current rates, see Download pricelists.