GSM 03.38, Unicode y SMS concatenados: cómo calcular segmentos antes de enviar

Qué problema resuelve el cálculo de segmentos

En SMS, contar caracteres visibles no basta. El número de segmentos depende del texto efectivamente codificado, del alfabeto seleccionado y, si el contenido supera un segmento, del mecanismo de concatenación. Un carácter visible puede consumir una o dos posiciones en GSM 7-bit y un carácter fuera de las tablas GSM 03.38 puede exigir una estrategia alternativa, como una codificación explícita, conversión a UCS2, sustitución, transformación o rechazo, según la configuración de la plataforma.

La diferencia es operativa. Afecta a la estimación de volumen, al control de coste, a la capacidad que se reserva para una campaña y a la experiencia del destinatario. También puede cambiar después de aprobar una plantilla si una variable, una firma, un enlace o un texto de cumplimiento introduce caracteres distintos o supera un umbral de longitud.

La regla útil es calcular siempre sobre el mensaje final renderizado, no sobre una plantilla abstracta ni sobre un contador genérico de caracteres.

• Conserve el texto exacto que se va a enviar, incluidas variables resueltas.
• Determine la codificación antes de estimar los segmentos.
• Cuente septetos para GSM 7-bit, no solo caracteres mostrables.
• Cuente unidades UCS2 de 16 bits cuando el texto se trate como UCS2.
• Aplique la capacidad correspondiente al método de concatenación configurado.

Las dos codificaciones relevantes: GSM 03.38 y UCS2

Para la planificación práctica de SMS, las dos codificaciones más relevantes son GSM 7-bit, basado en el alfabeto GSM 03.38, y UCS2. GSM 7-bit permite empaquetar hasta 160 septetos en los 140 octetos disponibles para datos de usuario cuando no hay UDH. UCS2 utiliza unidades de 16 bits dentro de un repertorio limitado al Basic Multilingual Plane y permite hasta 70 unidades UCS2 en un mensaje simple.

GSM 7-bit no es un subconjunto visual de Unicode elegido por apariencia. Es un repertorio definido de caracteres básicos y una tabla de extensión. Si cada carácter del texto final pertenece a esas tablas aplicables, el mensaje puede calcularse en septetos GSM. Si aparece un carácter fuera de ese repertorio, se necesita una estrategia alternativa. Muchas plataformas lo codifican o lo convierten a UCS2; otras pueden rechazarlo, sustituirlo o requerir una codificación explícita.

UCS2 no es equivalente a Unicode ni a UTF-16. UCS2 es un repertorio y una codificación de 16 bits limitada al Basic Multilingual Plane. Algunas implementaciones comercialmente denominadas «UCS2» pueden aceptar UTF-16 o aplicar transformaciones propias. Por ello, especialmente para caracteres fuera del Basic Multilingual Plane, valide cómo mide, transforma y segmenta el contenido la implementación y el proveedor de mensajería.

• GSM 7-bit sin UDH: hasta 160 septetos.
• UCS2 sin UDH: hasta 70 unidades UCS2 de 16 bits.
• No elija la codificación por el idioma de la campaña: valídela contra el texto final.
• No suponga que la compatibilidad Unicode del editor equivale a compatibilidad GSM 7-bit.
• Valide el comportamiento de caracteres fuera del Basic Multilingual Plane en su implementación concreta.

Límites prácticos por segmento y efecto de la concatenación

Un mensaje simple puede transportar hasta 160 septetos en GSM 7-bit o hasta 70 unidades UCS2 de 16 bits. Cuando el contenido requiere varios segmentos, cada parte necesita información para que el terminal pueda identificar el conjunto y su orden. Esa información se transporta habitualmente mediante un User Data Header, o UDH, y reduce la carga útil disponible para texto.

Con un IE de concatenación con referencia de 8 bits, el UDH ocupa 6 octetos. Sobre el límite de 140 octetos del TP-UD, quedan 134 octetos para contenido. Esto equivale, como cálculo técnico, a 153 septetos GSM 7-bit por segmento multiparte o 67 unidades UCS2 por segmento multiparte. Con una referencia de 16 bits, el UDH ocupa un octeto más: la capacidad práctica pasa a 152 septetos GSM 7-bit o 66 unidades UCS2 por segmento multiparte.

En GSM 7-bit con UDH, el cálculo debe considerar el relleno y la alineación de septetos conforme a TP-UDHI. Los valores 153 y 152 son capacidades habituales derivadas de los límites de datos de usuario y de las estructuras de concatenación indicadas. La implementación final debe medir el TP-UD construido, especialmente cuando se añaden otros IEs al UDH. El método real de una ruta puede no coincidir con estos supuestos; confirme el método exacto de segmentación, partición y conteo facturable de su SMSC, ruta o proveedor antes de fijarlo como regla contractual o de facturación.

• GSM 7-bit, mensaje simple: 160 septetos.
• UCS2, mensaje simple: 70 unidades UCS2 de 16 bits.
• GSM 7-bit concatenado con referencia de 8 bits: 153 septetos por segmento multiparte.
• UCS2 concatenado con referencia de 8 bits: 67 unidades UCS2 por segmento multiparte.
• GSM 7-bit concatenado con referencia de 16 bits: 152 septetos por segmento multiparte.
• UCS2 concatenado con referencia de 16 bits: 66 unidades UCS2 por segmento multiparte.
• Otros IEs en el UDH pueden reducir aún más la capacidad disponible.

Cómo calcular segmentos de forma auditable

Para GSM 7-bit, clasifique cada carácter del texto final en tabla básica o tabla de extensión. Cada carácter de la tabla básica consume un septeto. Cada carácter de la tabla de extensión consume dos septetos porque se codifica mediante un escape seguido del código de extensión.

La fórmula es: septetos GSM = caracteres de tabla básica + 2 × caracteres de tabla de extensión. Si el resultado cabe en 160 septetos, es un mensaje simple. Si lo supera, divida el total entre la capacidad concatenada aplicable y redondee hacia arriba. Para referencia de 8 bits, la capacidad de planificación habitual es 153 septetos por segmento multiparte; para referencia de 16 bits, 152. En GSM 7-bit con UDH, confirme el resultado a partir del TP-UD construido y ajuste la capacidad si hay otros IEs en el UDH.

Para UCS2, si el texto está formado por caracteres representables en una unidad UCS2 de 16 bits, cuente unidades UCS2. Divida entre 70 si no hay concatenación o entre 67 si se usa un UDH de concatenación de 8 bits, redondeando hacia arriba. Estos resultados expresan unidades UCS2, no caracteres Unicode universales. Si su pila técnica acepta UTF-16, caracteres fuera del Basic Multilingual Plane o aplica transformaciones propias, no reutilice este cálculo sin comprobar cómo mide, transforma y segmenta esos caracteres.

• Fórmula GSM 7-bit: básicos + 2 × extendidos.
• Segmentos GSM simples: 1 si los septetos son 160 o menos.
• Segmentos GSM concatenados: techo de septetos totales dividido entre 153 o 152, según el UDH aplicado y tras validar el TP-UD construido.
• Segmentos UCS2 simples: techo de unidades UCS2 dividido entre 70.
• Segmentos UCS2 concatenados con referencia de 8 bits: techo de unidades UCS2 dividido entre 67.
• Ajuste la capacidad si el UDH contiene otros IEs o la ruta aplica otro método de segmentación.

Caracteres extendidos GSM 03.38: un carácter visible puede ocupar dos septetos

La tabla de extensión GSM 7-bit permite conservar determinados símbolos sin activar UCS2, pero no son gratuitos en capacidad. Entre ellos se encuentran €, ^, {, }, [, ], ~ y la barra invertida. Aunque cada uno se vea como un único carácter, requiere una secuencia de escape y consume dos septetos.

Este detalle importa cerca de los límites. Un texto con 158 caracteres visibles no necesariamente cabe en un SMS GSM 7-bit. Si contiene tres caracteres de extensión, su consumo sería de 161 septetos incluso si todos los demás caracteres pertenecen a la tabla básica. En ese caso, el texto pasa a concatenación.

El cálculo de septetos para estos símbolos se determina por la tabla GSM 03.38. De forma operativa, valide que la implementación y la ruta aplican la codificación esperada. Un contador operativo debe mostrar al menos tres valores: caracteres visibles, número de caracteres extendidos y septetos GSM totales. Mostrar solo la longitud visual puede inducir aprobaciones incorrectas.

• Caracteres extendidos frecuentes: €, ^, {, }, [, ], ~ y barra invertida.
• Cada carácter extendido GSM consume dos septetos.
• Calcule los septetos según la tabla GSM 03.38 y valide la implementación de la ruta.
• Revise especialmente precios, importes, códigos, expresiones técnicas y URLs con símbolos.
• No sustituya automáticamente caracteres sin una política aprobada: una sustitución puede modificar el significado del contenido.

Qué suele activar Unicode y cómo prevenir cambios inesperados

Las comillas tipográficas, los emojis, los alfabetos no latinos y muchos símbolos copiados desde procesadores de texto, hojas de cálculo, herramientas de diseño o sistemas de gestión de contenido pueden no formar parte de GSM 7-bit. No debe decidirse por intuición: el validador debe comparar cada punto de código del contenido contra la tabla básica GSM y su tabla de extensión.

Las comillas rectas y las comillas tipográficas son visualmente parecidas, pero no necesariamente tienen la misma representación. Lo mismo ocurre con guiones, espacios especiales, marcas registradas, iconos y variantes estilizadas de letras o números. El riesgo no es solo aplicar una estrategia distinta de GSM 7-bit, como una conversión a UCS2: una modificación posterior puede aumentar el número de segmentos y alterar la previsión de capacidad.

La medida preventiva más sólida es normalizar el texto de acuerdo con una política documentada, conservar tanto la versión original como la normalizada y volver a calcular la codificación y los segmentos después de cada sustitución dinámica. Cuando se detecte un carácter fuera de GSM 7-bit, la política debe definir si se usa una codificación explícita, se convierte a UCS2, se sustituye, se transforma o se rechaza el contenido.

• Detecte caracteres fuera de GSM 7-bit antes de enviar.
• Revise contenido pegado desde herramientas de edición y bibliotecas de plantillas.
• Valide valores de variables con el mismo motor que valida el cuerpo fijo.
• Conserve texto original y texto normalizado para poder explicar diferencias.
• Exija una nueva aprobación si el texto final cambia de codificación o de tramo de segmentos.

Ejemplos de cálculo

Ejemplo 1, OTP: "Su código de acceso es 482913." Si todos los caracteres pertenecen a la tabla básica GSM, el mensaje se calcula en septetos GSM y queda ampliamente dentro de los 160 de un mensaje simple. La recomendación operativa es ejecutar el cálculo después de insertar el código real y cualquier prefijo o firma que se añada en producción.

Ejemplo 2, notificación transaccional: "Pedido 8742 confirmado. Total: 18€." Este ejemplo presupone que, salvo el símbolo €, el resto de caracteres usados pertenece al repertorio GSM básico aplicable. El símbolo € pertenece a la tabla de extensión GSM. El mensaje puede mantenerse en GSM 7-bit, pero el € consume dos septetos. Para un texto corto no cambia el número de partes, pero debe reflejarse en el contador y en la auditoría.

Ejemplo 3, mensaje promocional consentido: si una campaña aprobada incluye una comilla tipográfica o un emoji, el texto requiere una estrategia alternativa a GSM 7-bit. Según la configuración, puede convertirse a UCS2, requerir una codificación explícita, sustituirse, transformarse o rechazarse. Si se usa UCS2, la capacidad de un mensaje simple baja a 70 unidades UCS2 y la de un segmento multiparte, con referencia de 8 bits, a 67, bajo esos supuestos de UDH. Antes de cambiar el contenido, el responsable debe decidir si mantiene el carácter, adopta una alternativa aprobada compatible con GSM o rediseña el texto para controlar el número de partes.

En los tres casos, no se debe estimar con una longitud genérica de la plantilla. Deben incluirse URL, nombre de marca, variables, textos regulatorios, STOP/HELP cuando correspondan y cualquier texto añadido por el sistema remitente.

• OTP: calcule tras insertar el código final.
• Transaccional con €: si el resto del texto pertenece al repertorio GSM básico aplicable, permanezca en GSM 7-bit, pero sume un septeto adicional frente a un carácter básico.
• Promocional consentido con emoji o comillas tipográficas: aplique la estrategia configurada para caracteres fuera de GSM 7-bit.
• No use ejemplos de texto como sustituto de la validación de cada mensaje renderizado.

Tabla operativa de planificación y aprobación

Una tabla operativa convierte el cálculo técnico en un control repetible. Debe registrarse por plantilla y por versión, y también cuando una variable pueda modificar de forma material la codificación o el número de segmentos. No es necesario tratar estos campos como requisitos normativos; son controles recomendados para poder revisar una decisión y reproducir el envío.

El campo de segmentos previstos debe indicar el supuesto técnico usado. Por ejemplo, no basta con registrar "2 segmentos": conviene registrar "2 GSM 7-bit, UDH de concatenación con referencia de 8 bits, 153 septetos por segmento multiparte". Así se evita que otra integración aplique un método distinto sin detectarlo.

En SMPP, SAR describe un mensaje concatenado mediante parámetros para la referencia del conjunto, el número total de segmentos y la posición de cada fragmento. La especificación SMPP no garantiza de forma general que el SMSC vaya a segmentar automáticamente el mensaje ni que encapsule el contenido en UDH: ese comportamiento depende del SMSC y del acuerdo técnico de la ruta. En redes GSM, SMPP v3.4 indica que no deben combinarse los TLV SAR de concatenación con un UDH de concatenación ya codificado en short_message.

• Identificador y versión de plantilla.
• Texto original y texto tras normalización.
• Ejemplo de texto final renderizado con variables resueltas.
• Codificación prevista: GSM 7-bit o UCS2.
• Caracteres básicos, caracteres extendidos y septetos totales, cuando aplique.
• Unidades UCS2, cuando aplique.
• Segmentos previstos y umbral de capacidad utilizado.
• Tipo de UDH o mecanismo SAR seleccionado para concatenación SMPP, cuando aplique. En redes GSM, no combine los TLV SAR de concatenación con un UDH de concatenación codificado en short_message. Si se codifica un UDH en los datos de usuario, active el indicador UDHI en esm_class conforme a SMPP v3.4.