Сегментация SMS: GSM-7, Unicode и реальная длина сообщения

Длина SMS определяется не количеством видимых букв, а кодировкой и числом передаваемых сегментов. Текст из базового алфавита GSM-7 обычно помещается в 160 символов, а сообщение с кириллицей — в 70 символов Unicode. После перехода к составному SMS полезная ёмкость каждого сегмента уменьшается: как правило, до 153 символов GSM-7 или 67 символов Unicode. Поэтому одна кавычка, эмодзи или подставленное имя может изменить число сегментов, стоимость и время прохождения очереди.

Почему символы считаются по-разному

SMS передаёт ограниченный объём данных. Платформа выбирает способ представления текста по набору символов:

• GSM-7 использует базовый семибитный алфавит и подходит прежде всего для латиницы, цифр и части знаков;
• Unicode обычно применяется для кириллицы, национальных алфавитов, многих специальных символов и эмодзи;
• бинарный режим используется для отдельных машинных сценариев и не является обычным текстовым SMS.

Русскоязычный шаблон практически всегда требует Unicode. Это нормально: задача не в том, чтобы любой ценой перейти на латиницу, а в том, чтобы заранее знать итоговое количество сегментов и учитывать его в бюджете и мощности.

Некоторые символы GSM-7 находятся в расширенной таблице и занимают две кодовые позиции. К ним могут относиться фигурные скобки, обратная косая черта, знак евро и другие символы. Визуально строка остаётся короткой, но доступное место расходуется быстрее.

Один сегмент и составное сообщение

Типовые полезные лимиты выглядят так:

Кодировка	Один сегмент	Составное SMS, на сегмент
GSM-7	160 символов	153 символа
Unicode	70 символов	67 символов

В составном сообщении часть ёмкости занимает служебный заголовок UDH. Он сообщает телефону, какие части принадлежат одной последовательности и в каком порядке их нужно собрать. Получатель обычно видит единый текст, но сеть и биллинг учитывают несколько сегментов.

Эти значения — практический ориентир, а не замена расчёту платформы. Конкретный способ кодирования, поддержка длинных сообщений и правила тарификации зависят от маршрута, оператора и договора.

Как незаметно появляется дополнительный сегмент

Риск создаёт не только редакционный текст. Шаблон меняется после подстановки данных:

Заказ 74821 готов. Получение до 18:00 по адресу: {{pickup_address}}

Короткий адрес оставит сообщение в одном сегменте, а длинный адрес, название торгового центра и уточнение входа могут добавить второй или третий. Аналогично работают:

• имя и отчество клиента;
• название компании или товара;
• номер заказа переменной длины;
• дата и часовой пояс;
• длинная ссылка без сокращения;
• типографские кавычки и длинное тире;
• символ из неожиданного алфавита;
• эмодзи, добавленный редактором или CRM.

Считать только статическую часть шаблона недостаточно. Нужны тесты на минимальных, типовых и максимально допустимых значениях каждого поля.

Не считайте длину обычной функцией строки

length в прикладном языке может считать байты, кодовые единицы или пользовательские символы. Ни один из этих вариантов сам по себе не гарантирует совпадения с фактическим SMS-кодированием.

Надёжнее использовать функцию предварительного расчёта, которая возвращает:

• выбранную кодировку;
• число кодовых единиц;
• количество сегментов;
• остаток места в последнем сегменте;
• символы, вызвавшие переход из GSM-7 в Unicode;
• итоговый текст после подстановки и нормализации.

Если такую функцию предоставляет коммуникационная платформа, результат следует получать до постановки сообщения в очередь. При самостоятельном расчёте нужны тестовые наборы для базовой и расширенной таблиц GSM-7, кириллицы, комбинируемых символов и эмодзи.

Нормализация должна быть управляемой

Автоматическая замена символов иногда уменьшает число сегментов: типографскую кавычку можно заменить прямой, неразрывный пробел — обычным, длинное тире — дефисом. Но безусловная нормализация опасна.

Она не должна:

• менять фамилии, адреса, коды и юридически значимые формулировки;
• транслитерировать русский текст без согласованного правила;
• удалять символы, меняющие смысл;
• сокращать критичную инструкцию ради одного сегмента;
• выполняться после подписи или вычисления контрольного значения.

Лучше разделить правила на безопасные технические замены и редакционные изменения, которые проходят проверку владельца шаблона.

Как сегментация влияет на производительность

Если платформа отправляет 1 000 пользовательских уведомлений, а среднее сообщение занимает 2,4 сегмента, через шлюз пройдёт около 2 400 сегментов. Именно это значение влияет на очередь и доступный TPS.

Поэтому пропускную способность SMS нужно планировать по сегментам, а не по числу бизнес-событий. Рост средней сегментации с 1,1 до 1,8 означает примерно такой же рост нагрузки при неизменном количестве уведомлений.

Для каждого класса трафика полезно наблюдать:

• среднее и P95 числа сегментов на сообщение;
• долю одно-, двух- и многосегментных сообщений;
• долю Unicode по шаблонам;
• стоимость на одно бизнес-событие;
• время доставки в зависимости от сегментации;
• шаблоны с резким изменением распределения.

Эти метрики дополняют DLR и показатели задержки: финальная доставка не объясняет, почему очередь внезапно стала проходить медленнее.

Где выполнять проверку

Контроль лучше строить в нескольких слоях.

В редакторе шаблонов

Показывайте текущую кодировку и число сегментов сразу при вводе текста. Для переменных задавайте примеры и максимальную длину. Предупреждение должно объяснять причину, а не просто сообщать «слишком длинно».

Перед отправкой

После подстановки данных повторно вычисляйте кодировку и сегменты. Применяйте лимит по типу сообщения: для OTP он может быть строгим, а для сервисного уведомления — более гибким.

В аналитике

Сохраняйте версию шаблона, итоговую кодировку и количество сегментов рядом с идентификатором сообщения. Это позволяет связать изменение текста с затратами, очередью и доставляемостью.

Что делать с длинным текстом

Не всякое сообщение нужно механически сокращать. Сначала определите его назначение:

1. OTP должен содержать код, срок действия и минимально необходимый контекст.
2. Транзакционное уведомление должно однозначно объяснять событие и следующее действие.
3. Подробную инструкцию можно разместить на доверенной странице, оставив в SMS короткое содержание и понятную ссылку.
4. Маркетинговый текст следует проверять как отдельный шаблон с собственными ограничениями.

Критичные данные нельзя прятать только за ссылкой. Пользователь должен по самому сообщению понимать отправителя и причину обращения.

Чек-лист перед запуском шаблона

• посчитать сегменты после реальных подстановок;
• проверить минимальную и максимальную длину переменных;
• протестировать кириллицу, латиницу, кавычки, тире и эмодзи;
• зафиксировать допустимую нормализацию;
• проверить отображение составного сообщения на нескольких устройствах;
• подтвердить правила тарификации и ограничения маршрута;
• включить метрики кодировки и сегментов;
• настроить предупреждение при изменении распределения;
• провести нагрузочный тест с фактическим средним числом сегментов;
• хранить версию отправленного шаблона для разбора обращений.

При выборе SMS-платформы стоит отдельно проверить наличие предварительного расчёта кодировки, прозрачной статистики по сегментам и одинакового результата для API и SMPP-подключения. Это превращает длину сообщения из неожиданного счёта в управляемый параметр интеграции.