> ## Documentation Index
> Fetch the complete documentation index at: https://docs.beem.africa/llms.txt
> Use this file to discover all available pages before exploring further.

# Message encoding

> GSM text encoding, UCS2, binary messages, URL encoding, and address formatting.

This page covers how messages and addresses must be formatted before sending them to the Messaging Platform.

***

## Encoding types

| Encoding                | `CHARCODE`                | Max chars per SMS                            | Use case                                                          |
| ----------------------- | ------------------------- | -------------------------------------------- | ----------------------------------------------------------------- |
| **GSM 7-bit (default)** | `0`                       | 160 (single); 153 per part when concatenated | Standard Latin text, numbers, and GSM default alphabet            |
| **UCS2 (Unicode)**      | *(via platform handling)* | **70** per part                              | Non-Latin scripts, emoji, and characters outside the GSM alphabet |
| **Binary (8-bit)**      | `2`                       | 140 bytes per part                           | WAP Push, ringtones, logos, and other binary payloads             |

### GSM 7-bit (IA5 / GSM 03.38)

SMS text messages are usually encoded using the **GSM 7-bit default character set** (GSM 03.38 / IA5). The platform applies standard GSM encoding rules for most Latin-script messages.

### UCS2

When sending messages that require **UCS2** (Unicode), each SMS part can contain a maximum of **70 characters**. Longer messages are split into multiple parts automatically. Use UCS2 when your content includes characters not supported by the GSM 7-bit alphabet.

### Binary

Set `CHARCODE=2` and provide message content in **hex format** (for example `0x41 0x42 0x43`). Binary messages can include a [User Data Header (UDH)](#user-data-header-udh) for WAP Push and similar services.

<Info>
  Encoding is applied at the **SMSC/platform level**, not per account. The destination SMSC or mobile network operator (MNO) may also determine how messages are encoded for delivery.

  By default, the platform uses standard GSM 7-bit encoding rules. Contact your account manager if you need guidance on encoding for a specific destination country.
</Info>

***

## URL encoding

All requests must be properly URL encoded as per **RFC 1738**. Since URLs can only include a limited set of characters (`A–Z`, `a–z`, `0–9`, `$-_.+!*'(),`), all other characters must be escaped.

Most programming languages provide utility classes for URL encoding, including Java, Perl, PHP, and .NET.

<Warning>
  Source and destination addresses must **never** include a leading `+` character. In a URL, `+` represents an escaped space — not a plus sign.
</Warning>

***

## Addresses

Source and destination addresses (senders and recipients) are usually numeric international GSM numbers starting with the country code, **without leading zeros or plus signs**.

**Example destination:** `255650000001`

It is also possible to use **alphanumeric source addresses**, which can be a maximum of **11 characters** in the GSM network. For best results, use only characters `A–Z`, `a–z`, `0–9`, and spaces.

Use `SOURCEADDRTON` to specify the type of number for the source address:

| Value | Description             |
| ----- | ----------------------- |
| `0`   | Unknown                 |
| `1`   | International (default) |
| `5`   | Alphanumeric            |

***

## User Data Header (UDH)

Binary messages can include a User Data Header for features such as WAP Push. Set `UDHI` to a non-zero value when UDH is present in the message body, and provide the UDH bytes in the `UDH` parameter.

**Example WAP Push UDH:** `0x06 0x05 0x04 0x0b 0x84 0x23 0xf0`