GSM 03.38, Unicode e SMS concatenados: como calcular segmentos antes de enviar

Que problema o cálculo de segmentos resolve

Em SMS, contar caracteres visíveis não é suficiente. O número de segmentos depende do texto efetivamente codificado, do alfabeto selecionado e, caso o conteúdo ultrapasse um segmento, do mecanismo de concatenação. Um caráter visível pode consumir uma ou duas posições em GSM de 7 bits, e um caráter fora das tabelas GSM 03.38 pode exigir uma estratégia alternativa, como codificação explícita, conversão para UCS2, substituição, transformação ou rejeição, consoante a configuração da plataforma.

A diferença é operacional. Afeta a estimativa de volume, o controlo de custos, a capacidade reservada para uma campanha e a experiência do destinatário. Também pode mudar após a aprovação de um modelo se uma variável, uma assinatura, uma ligação ou um texto de conformidade introduzir caracteres diferentes ou ultrapassar um limite de comprimento.

A regra útil é calcular sempre com base na mensagem final renderizada, e não num modelo abstrato nem num contador genérico de caracteres.

• Guarde o texto exato que será enviado, incluindo as variáveis resolvidas.
• Determine a codificação antes de estimar os segmentos.
• Conte septetos para GSM de 7 bits, e não apenas caracteres visíveis.
• Conte unidades UCS2 de 16 bits quando o texto for tratado como UCS2.
• Aplique a capacidade correspondente ao método de concatenação configurado.

As duas codificações relevantes: GSM 03.38 e UCS2

Para o planeamento prático de SMS, as duas codificações mais relevantes são GSM de 7 bits, baseado no alfabeto GSM 03.38, e UCS2. O GSM de 7 bits permite empacotar até 160 septetos nos 140 octetos disponíveis para dados de utilizador quando não existe UDH. O UCS2 utiliza unidades de 16 bits dentro de um repertório limitado ao Basic Multilingual Plane e permite até 70 unidades UCS2 numa mensagem simples.

O GSM de 7 bits não é um subconjunto visual de Unicode escolhido pela aparência. É um repertório definido de caracteres básicos e uma tabela de extensão. Se cada caráter do texto final pertencer a essas tabelas aplicáveis, a mensagem pode ser calculada em septetos GSM. Se surgir um caráter fora desse repertório, é necessária uma estratégia alternativa. Muitas plataformas codificam-no ou convertem-no para UCS2; outras podem rejeitá-lo, substituí-lo ou exigir uma codificação explícita.

UCS2 não é equivalente a Unicode nem a UTF-16. UCS2 é um repertório e uma codificação de 16 bits limitada ao Basic Multilingual Plane. Algumas implementações comercialmente denominadas «UCS2» podem aceitar UTF-16 ou aplicar transformações próprias. Por isso, especialmente para caracteres fora do Basic Multilingual Plane, valide como a implementação e o fornecedor de mensagens medem, transformam e segmentam o conteúdo.

• GSM de 7 bits sem UDH: até 160 septetos.
• UCS2 sem UDH: até 70 unidades UCS2 de 16 bits.
• Não escolha a codificação pelo idioma da campanha: valide-a face ao texto final.
• Não assuma que a compatibilidade Unicode do editor equivale à compatibilidade GSM de 7 bits.
• Valide o comportamento de caracteres fora do Basic Multilingual Plane na sua implementação concreta.

Limites práticos por segmento e efeito da concatenação

Uma mensagem simples pode transportar até 160 septetos em GSM de 7 bits ou até 70 unidades UCS2 de 16 bits. Quando o conteúdo requer vários segmentos, cada parte precisa de informação para que o terminal possa identificar o conjunto e a sua ordem. Essa informação é normalmente transportada através de um User Data Header, ou UDH, e reduz a carga útil disponível para texto.

Com um IE de concatenação com referência de 8 bits, o UDH ocupa 6 octetos. Do limite de 140 octetos do TP-UD, ficam 134 octetos para conteúdo. Isto equivale, como cálculo técnico, a 153 septetos GSM de 7 bits por segmento multipartes ou 67 unidades UCS2 por segmento multipartes. Com uma referência de 16 bits, o UDH ocupa mais um octeto: a capacidade prática passa para 152 septetos GSM de 7 bits ou 66 unidades UCS2 por segmento multipartes.

Em GSM de 7 bits com UDH, o cálculo deve considerar o preenchimento e o alinhamento dos septetos em conformidade com TP-UDHI. Os valores 153 e 152 são capacidades habituais derivadas dos limites dos dados de utilizador e das estruturas de concatenação indicadas. A implementação final deve medir o TP-UD construído, sobretudo quando são adicionados outros IEs ao UDH. O método real de uma rota pode não coincidir com estes pressupostos; confirme o método exato de segmentação, divisão e contagem faturável do seu SMSC, rota ou fornecedor antes de o fixar como regra contratual ou de faturação.

• GSM de 7 bits, mensagem simples: 160 septetos.
• UCS2, mensagem simples: 70 unidades UCS2 de 16 bits.
• GSM de 7 bits concatenado com referência de 8 bits: 153 septetos por segmento multipartes.
• UCS2 concatenado com referência de 8 bits: 67 unidades UCS2 por segmento multipartes.
• GSM de 7 bits concatenado com referência de 16 bits: 152 septetos por segmento multipartes.
• UCS2 concatenado com referência de 16 bits: 66 unidades UCS2 por segmento multipartes.
• Outros IEs no UDH podem reduzir ainda mais a capacidade disponível.

Como calcular segmentos de forma auditável

Para GSM de 7 bits, classifique cada caráter do texto final como pertencente à tabela básica ou à tabela de extensão. Cada caráter da tabela básica consome um septeto. Cada caráter da tabela de extensão consome dois septetos porque é codificado através de um escape seguido do código de extensão.

A fórmula é: septetos GSM = caracteres da tabela básica + 2 × caracteres da tabela de extensão. Se o resultado couber em 160 septetos, é uma mensagem simples. Se ultrapassar esse valor, divida o total pela capacidade de concatenação aplicável e arredonde para cima. Para referência de 8 bits, a capacidade de planeamento habitual é de 153 septetos por segmento multipartes; para referência de 16 bits, 152. Em GSM de 7 bits com UDH, confirme o resultado a partir do TP-UD construído e ajuste a capacidade se existirem outros IEs no UDH.

Para UCS2, se o texto for composto por caracteres representáveis numa unidade UCS2 de 16 bits, conte unidades UCS2. Divida por 70 se não houver concatenação ou por 67 se for usado um UDH de concatenação de 8 bits, arredondando para cima. Estes resultados expressam unidades UCS2, não caracteres Unicode universais. Se a sua pilha técnica aceitar UTF-16, caracteres fora do Basic Multilingual Plane ou aplicar transformações próprias, não reutilize este cálculo sem verificar como esses caracteres são medidos, transformados e segmentados.

• Fórmula GSM de 7 bits: básicos + 2 × estendidos.
• Segmentos GSM simples: 1 se os septetos forem 160 ou menos.
• Segmentos GSM concatenados: arredondamento para cima do total de septetos dividido por 153 ou 152, consoante o UDH aplicado e após validar o TP-UD construído.
• Segmentos UCS2 simples: arredondamento para cima das unidades UCS2 dividido por 70.
• Segmentos UCS2 concatenados com referência de 8 bits: arredondamento para cima das unidades UCS2 dividido por 67.
• Ajuste a capacidade se o UDH contiver outros IEs ou se a rota aplicar outro método de segmentação.

Caracteres estendidos GSM 03.38: um caráter visível pode ocupar dois septetos

A tabela de extensão GSM de 7 bits permite preservar determinados símbolos sem ativar UCS2, mas estes não são gratuitos em capacidade. Entre eles encontram-se €, ^, {, }, [, ], ~ e a barra invertida. Embora cada um seja visto como um único caráter, requer uma sequência de escape e consome dois septetos.

Este detalhe é importante perto dos limites. Um texto com 158 caracteres visíveis não cabe necessariamente num SMS GSM de 7 bits. Se contiver três caracteres de extensão, o seu consumo será de 161 septetos, mesmo que todos os restantes caracteres pertençam à tabela básica. Nesse caso, o texto passa a exigir concatenação.

O cálculo de septetos para estes símbolos é determinado pela tabela GSM 03.38. Em termos operacionais, valide que a implementação e a rota aplicam a codificação esperada. Um contador operacional deve apresentar pelo menos três valores: caracteres visíveis, número de caracteres estendidos e total de septetos GSM. Mostrar apenas o comprimento visual pode levar a aprovações incorretas.

• Caracteres estendidos frequentes: €, ^, {, }, [, ], ~ e barra invertida.
• Cada caráter estendido GSM consome dois septetos.
• Calcule os septetos de acordo com a tabela GSM 03.38 e valide a implementação da rota.
• Revise especialmente preços, montantes, códigos, expressões técnicas e URLs com símbolos.
• Não substitua caracteres automaticamente sem uma política aprovada: uma substituição pode alterar o significado do conteúdo.

O que costuma ativar Unicode e como evitar alterações inesperadas

Aspas tipográficas, emojis, alfabetos não latinos e muitos símbolos copiados de processadores de texto, folhas de cálculo, ferramentas de design ou sistemas de gestão de conteúdos podem não fazer parte do GSM de 7 bits. Não se deve decidir por intuição: o validador deve comparar cada ponto de código do conteúdo com a tabela básica GSM e a respetiva tabela de extensão.

As aspas retas e as aspas tipográficas são visualmente semelhantes, mas não têm necessariamente a mesma representação. O mesmo acontece com hífenes, espaços especiais, marcas registadas, ícones e variantes estilizadas de letras ou números. O risco não é apenas aplicar uma estratégia diferente de GSM de 7 bits, como uma conversão para UCS2: uma alteração posterior pode aumentar o número de segmentos e modificar a previsão de capacidade.

A medida preventiva mais sólida é normalizar o texto de acordo com uma política documentada, guardar tanto a versão original como a normalizada e recalcular a codificação e os segmentos após cada substituição dinâmica. Quando for detetado um caráter fora de GSM de 7 bits, a política deve definir se é usada uma codificação explícita, se o conteúdo é convertido para UCS2, substituído, transformado ou rejeitado.

• Detete caracteres fora de GSM de 7 bits antes do envio.
• Revise conteúdo colado de ferramentas de edição e bibliotecas de modelos.
• Valide os valores das variáveis com o mesmo motor que valida o corpo fixo.
• Guarde o texto original e o texto normalizado para conseguir explicar diferenças.
• Exija uma nova aprovação se o texto final mudar de codificação ou de escalão de segmentos.

Exemplos de cálculo

Exemplo 1, OTP: "O seu código de acesso é 482913." Se todos os caracteres pertencerem à tabela básica GSM, a mensagem é calculada em septetos GSM e fica amplamente dentro dos 160 de uma mensagem simples. A recomendação operacional é executar o cálculo depois de inserir o código real e qualquer prefixo ou assinatura adicionados em produção.

Exemplo 2, notificação transacional: "Pedido 8742 confirmado. Total: 18€." Este exemplo pressupõe que, exceto o símbolo €, o restante dos caracteres utilizados pertence ao repertório básico GSM aplicável. O símbolo € pertence à tabela de extensão GSM. A mensagem pode manter-se em GSM de 7 bits, mas o € consome dois septetos. Num texto curto, não altera o número de partes, mas deve ficar refletido no contador e na auditoria.

Exemplo 3, mensagem promocional com consentimento: se uma campanha aprovada incluir uma aspa tipográfica ou um emoji, o texto exige uma estratégia alternativa ao GSM de 7 bits. Consoante a configuração, pode ser convertido para UCS2, exigir uma codificação explícita, ser substituído, transformado ou rejeitado. Se for usado UCS2, a capacidade de uma mensagem simples baixa para 70 unidades UCS2 e a de um segmento multipartes, com referência de 8 bits, para 67, sob estes pressupostos de UDH. Antes de alterar o conteúdo, o responsável deve decidir se mantém o caráter, adota uma alternativa aprovada compatível com GSM ou reformula o texto para controlar o número de partes.

Nos três casos, não se deve estimar com um comprimento genérico do modelo. Devem ser incluídos URL, nome da marca, variáveis, textos regulamentares, STOP/HELP quando aplicável e qualquer texto acrescentado pelo sistema remetente.

• OTP: calcule depois de inserir o código final.
• Transacional com €: se o restante texto pertencer ao repertório básico GSM aplicável, mantenha GSM de 7 bits, mas some um septeto adicional face a um caráter básico.
• Promocional com consentimento e emoji ou aspas tipográficas: aplique a estratégia configurada para caracteres fora de GSM de 7 bits.
• Não use exemplos de texto como substituto da validação de cada mensagem renderizada.

Tabela operacional de planeamento e aprovação

Uma tabela operacional transforma o cálculo técnico num controlo repetível. Deve ser registada por modelo e por versão, e também quando uma variável puder alterar de forma material a codificação ou o número de segmentos. Não é necessário tratar estes campos como requisitos normativos; são controlos recomendados para rever uma decisão e reproduzir o envio.

O campo de segmentos previstos deve indicar o pressuposto técnico utilizado. Por exemplo, não basta registar "2 segmentos": é conveniente registar "2 GSM de 7 bits, UDH de concatenação com referência de 8 bits, 153 septetos por segmento multipartes". Assim, evita-se que outra integração aplique um método diferente sem que isso seja detetado.

Em SMPP, SAR descreve uma mensagem concatenada através de parâmetros para a referência do conjunto, o número total de segmentos e a posição de cada fragmento. A especificação SMPP não garante de forma geral que o SMSC segmente automaticamente a mensagem nem que encapsule o conteúdo em UDH: esse comportamento depende do SMSC e do acordo técnico da rota. Em redes GSM, SMPP v3.4 indica que os TLV SAR de concatenação não devem ser combinados com um UDH de concatenação já codificado em short_message.

• Identificador e versão do modelo.
• Texto original e texto após normalização.
• Exemplo de texto final renderizado com variáveis resolvidas.
• Codificação prevista: GSM de 7 bits ou UCS2.
• Caracteres básicos, caracteres estendidos e septetos totais, quando aplicável.
• Unidades UCS2, quando aplicável.
• Segmentos previstos e limite de capacidade utilizado.
• Tipo de UDH ou mecanismo SAR selecionado para concatenação SMPP, quando aplicável. Em redes GSM, não combine TLV SAR de concatenação com um UDH de concatenação codificado em short_message. Se for codificado um UDH nos dados de utilizador, ative o indicador UDHI em esm_class em conformidade com SMPP v3.4.