GSM 03.38, Unicode e SMS concatenati: come calcolare i segmenti prima dell’invio

Quale problema risolve il calcolo dei segmenti

Negli SMS, contare i caratteri visibili non è sufficiente. Il numero di segmenti dipende dal testo effettivamente codificato, dall’alfabeto selezionato e, se il contenuto supera un segmento, dal meccanismo di concatenazione. Un carattere visibile può occupare una o due posizioni in GSM 7-bit e un carattere esterno alle tabelle GSM 03.38 può richiedere una strategia alternativa, come una codifica esplicita, la conversione in UCS2, la sostituzione, la trasformazione o il rifiuto, a seconda della configurazione della piattaforma.

La differenza è operativa. Incide sulla stima dei volumi, sul controllo dei costi, sulla capacità riservata per una campagna e sull’esperienza del destinatario. Può inoltre cambiare dopo l’approvazione di un modello se una variabile, una firma, un link o un testo di conformità introduce caratteri diversi o supera una soglia di lunghezza.

La regola utile è calcolare sempre sul messaggio finale renderizzato, non su un modello astratto né su un contatore generico di caratteri.

• Conserva il testo esatto che verrà inviato, incluse le variabili risolte.
• Determina la codifica prima di stimare i segmenti.
• Conta i settenari per GSM 7-bit, non soltanto i caratteri visualizzati.
• Conta le unità UCS2 a 16 bit quando il testo viene trattato come UCS2.
• Applica la capacità corrispondente al metodo di concatenazione configurato.

Le due codifiche rilevanti: GSM 03.38 e UCS2

Per la pianificazione pratica degli SMS, le due codifiche più rilevanti sono GSM 7-bit, basata sull’alfabeto GSM 03.38, e UCS2. GSM 7-bit consente di comprimere fino a 160 settenari nei 140 ottetti disponibili per i dati utente quando non è presente un UDH. UCS2 utilizza unità a 16 bit all’interno di un repertorio limitato al Basic Multilingual Plane e consente fino a 70 unità UCS2 in un messaggio singolo.

GSM 7-bit non è un sottoinsieme visivo di Unicode scelto in base all’aspetto. È un repertorio definito di caratteri di base e una tabella di estensione. Se ogni carattere del testo finale appartiene alle tabelle applicabili, il messaggio può essere calcolato in settenari GSM. Se compare un carattere esterno a questo repertorio, è necessaria una strategia alternativa. Molte piattaforme lo codificano o lo convertono in UCS2; altre possono rifiutarlo, sostituirlo o richiedere una codifica esplicita.

UCS2 non equivale né a Unicode né a UTF-16. UCS2 è un repertorio e una codifica a 16 bit limitata al Basic Multilingual Plane. Alcune implementazioni commercialmente denominate «UCS2» possono accettare UTF-16 o applicare trasformazioni proprie. Per questo motivo, soprattutto per i caratteri esterni al Basic Multilingual Plane, verifica come l’implementazione e il fornitore di messaggistica misurano, trasformano e segmentano il contenuto.

• GSM 7-bit senza UDH: fino a 160 settenari.
• UCS2 senza UDH: fino a 70 unità UCS2 a 16 bit.
• Non scegliere la codifica in base alla lingua della campagna: convalidala rispetto al testo finale.
• Non presumere che il supporto Unicode dell’editor equivalga al supporto GSM 7-bit.
• Verifica il comportamento dei caratteri esterni al Basic Multilingual Plane nella tua implementazione specifica.

Limiti pratici per segmento ed effetto della concatenazione

Un messaggio singolo può trasportare fino a 160 settenari in GSM 7-bit o fino a 70 unità UCS2 a 16 bit. Quando il contenuto richiede più segmenti, ogni parte necessita di informazioni affinché il terminale possa identificare l’insieme e il relativo ordine. Tali informazioni vengono abitualmente trasportate tramite uno User Data Header, o UDH, e riducono il carico utile disponibile per il testo.

Con un IE di concatenazione con riferimento a 8 bit, l’UDH occupa 6 ottetti. Sul limite di 140 ottetti del TP-UD rimangono 134 ottetti per il contenuto. Ciò equivale, come calcolo tecnico, a 153 settenari GSM 7-bit per segmento multipart o a 67 unità UCS2 per segmento multipart. Con un riferimento a 16 bit, l’UDH occupa un ottetto in più: la capacità pratica passa a 152 settenari GSM 7-bit o 66 unità UCS2 per segmento multipart.

In GSM 7-bit con UDH, il calcolo deve considerare il riempimento e l’allineamento dei settenari in conformità a TP-UDHI. I valori 153 e 152 sono capacità comuni derivate dai limiti dei dati utente e dalle strutture di concatenazione indicate. L’implementazione finale deve misurare il TP-UD costruito, soprattutto quando vengono aggiunti altri IE all’UDH. Il metodo effettivo di una route potrebbe non coincidere con queste ipotesi; conferma il metodo esatto di segmentazione, suddivisione e conteggio fatturabile del tuo SMSC, della route o del fornitore prima di stabilirlo come regola contrattuale o di fatturazione.

• GSM 7-bit, messaggio singolo: 160 settenari.
• UCS2, messaggio singolo: 70 unità UCS2 a 16 bit.
• GSM 7-bit concatenato con riferimento a 8 bit: 153 settenari per segmento multipart.
• UCS2 concatenato con riferimento a 8 bit: 67 unità UCS2 per segmento multipart.
• GSM 7-bit concatenato con riferimento a 16 bit: 152 settenari per segmento multipart.
• UCS2 concatenato con riferimento a 16 bit: 66 unità UCS2 per segmento multipart.
• Altri IE nell’UDH possono ridurre ulteriormente la capacità disponibile.

Come calcolare i segmenti in modo verificabile

Per GSM 7-bit, classifica ogni carattere del testo finale nella tabella di base o nella tabella di estensione. Ogni carattere della tabella di base consuma un settenario. Ogni carattere della tabella di estensione consuma due settenari perché viene codificato tramite un escape seguito dal codice di estensione.

La formula è: settenari GSM = caratteri della tabella di base + 2 × caratteri della tabella di estensione. Se il risultato rientra in 160 settenari, è un messaggio singolo. Se lo supera, dividi il totale per la capacità concatenata applicabile e arrotonda per eccesso. Per il riferimento a 8 bit, la capacità di pianificazione abituale è di 153 settenari per segmento multipart; per il riferimento a 16 bit, 152. In GSM 7-bit con UDH, conferma il risultato in base al TP-UD costruito e adegua la capacità se nell’UDH sono presenti altri IE.

Per UCS2, se il testo è formato da caratteri rappresentabili in una unità UCS2 a 16 bit, conta le unità UCS2. Dividi per 70 se non c’è concatenazione oppure per 67 se viene usato un UDH di concatenazione a 8 bit, arrotondando per eccesso. Questi risultati esprimono unità UCS2, non caratteri Unicode universali. Se il tuo stack tecnico accetta UTF-16, caratteri esterni al Basic Multilingual Plane o applica trasformazioni proprie, non riutilizzare questo calcolo senza verificare come tali caratteri vengano misurati, trasformati e segmentati.

• Formula GSM 7-bit: caratteri di base + 2 × caratteri estesi.
• Segmenti GSM singoli: 1 se i settenari sono 160 o meno.
• Segmenti GSM concatenati: arrotondamento per eccesso dei settenari totali divisi per 153 o 152, in base all’UDH applicato e dopo la validazione del TP-UD costruito.
• Segmenti UCS2 singoli: arrotondamento per eccesso delle unità UCS2 divise per 70.
• Segmenti UCS2 concatenati con riferimento a 8 bit: arrotondamento per eccesso delle unità UCS2 divise per 67.
• Adegua la capacità se l’UDH contiene altri IE o la route applica un diverso metodo di segmentazione.

Caratteri estesi GSM 03.38: un carattere visibile può occupare due settenari

La tabella di estensione GSM 7-bit consente di mantenere determinati simboli senza attivare UCS2, ma non sono gratuiti in termini di capacità. Tra questi figurano €, ^, {, }, [, ], ~ e la barra rovesciata. Sebbene ciascuno appaia come un singolo carattere, richiede una sequenza di escape e consuma due settenari.

Questo dettaglio è importante vicino ai limiti. Un testo di 158 caratteri visibili non entra necessariamente in un SMS GSM 7-bit. Se contiene tre caratteri di estensione, il consumo sarà di 161 settenari anche se tutti gli altri caratteri appartengono alla tabella di base. In questo caso, il testo passa alla concatenazione.

Il calcolo dei settenari per questi simboli è determinato dalla tabella GSM 03.38. Dal punto di vista operativo, verifica che l’implementazione e la route applichino la codifica prevista. Un contatore operativo dovrebbe mostrare almeno tre valori: caratteri visibili, numero di caratteri estesi e settenari GSM totali. Mostrare solo la lunghezza visiva può portare ad approvazioni errate.

• Caratteri estesi comuni: €, ^, {, }, [, ], ~ e barra rovesciata.
• Ogni carattere esteso GSM consuma due settenari.
• Calcola i settenari in base alla tabella GSM 03.38 e verifica l’implementazione della route.
• Controlla con particolare attenzione prezzi, importi, codici, espressioni tecniche e URL con simboli.
• Non sostituire automaticamente i caratteri senza una policy approvata: una sostituzione può modificare il significato del contenuto.

Cosa attiva di solito Unicode e come prevenire cambiamenti inattesi

Le virgolette tipografiche, le emoji, gli alfabeti non latini e molti simboli copiati da elaboratori di testo, fogli di calcolo, strumenti di progettazione o sistemi di gestione dei contenuti potrebbero non far parte del GSM 7-bit. Non bisogna decidere per intuizione: il validatore deve confrontare ogni punto di codice del contenuto con la tabella di base GSM e con la relativa tabella di estensione.

Le virgolette dritte e quelle tipografiche sono visivamente simili, ma non hanno necessariamente la stessa rappresentazione. Lo stesso vale per trattini, spazi speciali, marchi registrati, icone e varianti stilistiche di lettere o numeri. Il rischio non consiste soltanto nell’applicare una strategia diversa da GSM 7-bit, come la conversione in UCS2: una modifica successiva può aumentare il numero di segmenti e alterare la previsione della capacità.

La misura preventiva più solida consiste nel normalizzare il testo secondo una policy documentata, conservare sia la versione originale sia quella normalizzata e ricalcolare codifica e segmenti dopo ogni sostituzione dinamica. Quando viene rilevato un carattere esterno al GSM 7-bit, la policy deve definire se usare una codifica esplicita, convertire in UCS2, sostituire, trasformare o rifiutare il contenuto.

• Rileva i caratteri esterni al GSM 7-bit prima dell’invio.
• Controlla il contenuto incollato da strumenti di editing e librerie di modelli.
• Convalida i valori delle variabili con lo stesso motore che convalida il corpo fisso.
• Conserva testo originale e testo normalizzato per poter spiegare le differenze.
• Richiedi una nuova approvazione se il testo finale cambia codifica o fascia di segmenti.

Esempi di calcolo

Esempio 1, OTP: "Il tuo codice di accesso è 482913." Se tutti i caratteri appartengono alla tabella GSM di base, il messaggio viene calcolato in settenari GSM e rientra ampiamente nei 160 di un messaggio singolo. La raccomandazione operativa è eseguire il calcolo dopo aver inserito il codice effettivo e qualsiasi prefisso o firma aggiunti in produzione.

Esempio 2, notifica transazionale: "Ordine 8742 confermato. Totale: 18€." Questo esempio presuppone che, a eccezione del simbolo €, il resto dei caratteri utilizzati appartenga al repertorio GSM di base applicabile. Il simbolo € appartiene alla tabella di estensione GSM. Il messaggio può restare in GSM 7-bit, ma € consuma due settenari. Per un testo breve non modifica il numero di parti, ma deve essere riportato nel contatore e nell’audit.

Esempio 3, messaggio promozionale con consenso: se una campagna approvata include una virgoletta tipografica o un’emoji, il testo richiede una strategia alternativa a GSM 7-bit. A seconda della configurazione, può essere convertito in UCS2, richiedere una codifica esplicita, essere sostituito, trasformato o rifiutato. Se viene usato UCS2, la capacità di un messaggio singolo scende a 70 unità UCS2 e quella di un segmento multipart, con riferimento a 8 bit, a 67, in base a queste ipotesi UDH. Prima di modificare il contenuto, il responsabile deve decidere se mantenere il carattere, adottare un’alternativa approvata compatibile con GSM o riprogettare il testo per controllare il numero di parti.

In tutti e tre i casi, non si deve stimare usando una lunghezza generica del modello. Devono essere inclusi URL, nome del marchio, variabili, testi normativi, STOP/HELP quando pertinenti e qualsiasi testo aggiunto dal sistema mittente.

• OTP: calcola dopo aver inserito il codice finale.
• Transazionale con €: se il resto del testo appartiene al repertorio GSM di base applicabile, rimani in GSM 7-bit, ma aggiungi un settenario rispetto a un carattere di base.
• Promozionale con consenso con emoji o virgolette tipografiche: applica la strategia configurata per i caratteri esterni al GSM 7-bit.
• Non usare esempi di testo come sostituto della validazione di ogni messaggio renderizzato.

Tabella operativa per pianificazione e approvazione

Una tabella operativa trasforma il calcolo tecnico in un controllo ripetibile. Deve essere registrata per modello e per versione, nonché quando una variabile può modificare in modo sostanziale la codifica o il numero di segmenti. Non è necessario considerare questi campi come requisiti normativi; sono controlli consigliati per poter riesaminare una decisione e riprodurre l’invio.

Il campo dei segmenti previsti deve indicare l’ipotesi tecnica utilizzata. Ad esempio, non è sufficiente registrare "2 segmenti": è opportuno registrare "2 GSM 7-bit, UDH di concatenazione con riferimento a 8 bit, 153 settenari per segmento multipart". In questo modo si evita che un’altra integrazione applichi un metodo diverso senza che venga rilevato.

In SMPP, SAR descrive un messaggio concatenato mediante parametri relativi al riferimento dell’insieme, al numero totale di segmenti e alla posizione di ciascun frammento. La specifica SMPP non garantisce in modo generale che l’SMSC segmenti automaticamente il messaggio né che incapsuli il contenuto in UDH: tale comportamento dipende dall’SMSC e dall’accordo tecnico della route. Nelle reti GSM, SMPP v3.4 indica che i TLV SAR di concatenazione non devono essere combinati con un UDH di concatenazione già codificato in short_message.

• Identificatore e versione del modello.
• Testo originale e testo dopo la normalizzazione.
• Esempio di testo finale renderizzato con le variabili risolte.
• Codifica prevista: GSM 7-bit o UCS2.
• Caratteri di base, caratteri estesi e settenari totali, quando applicabile.
• Unità UCS2, quando applicabile.
• Segmenti previsti e soglia di capacità utilizzata.
• Tipo di UDH o meccanismo SAR selezionato per la concatenazione SMPP, quando applicabile. Nelle reti GSM, non combinare i TLV SAR di concatenazione con un UDH di concatenazione codificato in short_message. Se un UDH viene codificato nei dati utente, attiva l’indicatore UDHI in esm_class in conformità a SMPP v3.4.