GSM 03.38, Unicode et SMS concaténés : comment calculer les segments avant l’envoi

Quel problème résout le calcul des segments

Dans les SMS, compter les caractères visibles ne suffit pas. Le nombre de segments dépend du texte réellement encodé, de l’alphabet sélectionné et, si le contenu dépasse un segment, du mécanisme de concaténation. Un caractère visible peut consommer une ou deux positions en GSM 7 bits, et un caractère absent des tables GSM 03.38 peut exiger une stratégie alternative, telle qu’un encodage explicite, une conversion en UCS2, un remplacement, une transformation ou un rejet, selon la configuration de la plateforme.

La différence est opérationnelle. Elle affecte l’estimation des volumes, la maîtrise des coûts, la capacité réservée pour une campagne et l’expérience du destinataire. Elle peut également changer après l’approbation d’un modèle si une variable, une signature, un lien ou un texte de conformité introduit des caractères différents ou dépasse un seuil de longueur.

La règle utile consiste à toujours calculer sur le message final rendu, et non sur un modèle abstrait ni sur un compteur générique de caractères.

• Conservez le texte exact qui sera envoyé, y compris les variables résolues.
• Déterminez l’encodage avant d’estimer les segments.
• Comptez les septets pour le GSM 7 bits, et pas uniquement les caractères affichables.
• Comptez les unités UCS2 de 16 bits lorsque le texte est traité en UCS2.
• Appliquez la capacité correspondant à la méthode de concaténation configurée.

Les deux encodages pertinents : GSM 03.38 et UCS2

Pour la planification pratique des SMS, les deux encodages les plus pertinents sont le GSM 7 bits, fondé sur l’alphabet GSM 03.38, et UCS2. Le GSM 7 bits permet d’empaqueter jusqu’à 160 septets dans les 140 octets disponibles pour les données utilisateur en l’absence d’UDH. UCS2 est une forme de codage de caractères sur 16 bits et permet jusqu’à 70 unités UCS2 de 16 bits dans un message simple.

Le GSM 7 bits n’est pas un sous-ensemble visuel d’Unicode choisi selon l’apparence. Il s’agit d’un répertoire défini de caractères de base et d’une table d’extension. Si chaque caractère du texte final appartient aux tables applicables, le message peut être calculé en septets GSM. Si un caractère se trouve hors de ce répertoire, une stratégie alternative est nécessaire. De nombreuses plateformes l’encodent ou le convertissent en UCS2 ; d’autres peuvent le rejeter, le remplacer ou exiger un encodage explicite.

UCS2 n’est pas équivalent à Unicode ni à UTF-16. Dans ce contexte SMS, il est limité au Basic Multilingual Plane et la capacité s’applique à des unités de 16 bits. Certaines implémentations commercialement appelées « UCS2 » peuvent accepter UTF-16 ou appliquer leurs propres transformations. Par conséquent, en particulier pour les caractères situés hors du Basic Multilingual Plane, vérifiez comment l’implémentation et le fournisseur de messagerie mesurent, transforment et segmentent le contenu.

• GSM 7 bits sans UDH : jusqu’à 160 septets.
• UCS2 sans UDH : jusqu’à 70 unités UCS2 de 16 bits.
• Ne choisissez pas l’encodage en fonction de la langue de la campagne : validez-le par rapport au texte final.
• Ne supposez pas que la compatibilité Unicode de l’éditeur implique une compatibilité GSM 7 bits.
• Validez le comportement des caractères hors du Basic Multilingual Plane dans votre implémentation précise.

Limites pratiques par segment et effet de la concaténation

Un message simple peut transporter jusqu’à 160 septets en GSM 7 bits ou jusqu’à 70 unités UCS2 de 16 bits. Lorsque le contenu requiert plusieurs segments, chaque partie a besoin d’informations permettant au terminal d’identifier l’ensemble et son ordre. Ces informations sont généralement transportées par un User Data Header, ou UDH, et réduisent la charge utile disponible pour le texte.

Avec un IE de concaténation comportant une référence sur 8 bits, l’UDH occupe 6 octets. Sur la limite de 140 octets du TP-UD, il reste 134 octets pour le contenu. Cela équivaut à 153 septets GSM 7 bits par segment multipartie ou à 67 unités UCS2 par segment multipartie. Avec une référence sur 16 bits, l’UDH occupe un octet supplémentaire et laisse 133 octets. La capacité pratique habituelle est alors de 152 septets GSM 7 bits ou de 66 unités UCS2 par segment multipartie.

Pour UCS2, les capacités de 67 et 66 unités se déduisent directement des octets restant après l’UDH. Pour le GSM 7 bits avec UDH, le calcul doit aussi prendre en compte UDHL, les bits de remplissage et l’empaquetage des septets conformément à TP-UDHI. Les capacités habituelles de 153 septets avec une référence sur 8 bits et de 152 septets avec une référence sur 16 bits doivent donc être appliquées selon l’UDH effectivement construit. L’implémentation finale doit mesurer le TP-UD construit, notamment lorsque d’autres IE sont ajoutés à l’UDH. La méthode réelle d’une route peut ne pas correspondre à ces hypothèses ; confirmez la méthode exacte de segmentation, de découpage et de comptage facturable auprès de votre SMSC, de votre route ou de votre fournisseur avant d’en faire une règle contractuelle ou de facturation.

• GSM 7 bits, message simple : 160 septets.
• UCS2, message simple : 70 unités UCS2 de 16 bits.
• GSM 7 bits concaténé avec référence sur 8 bits : 153 septets par segment multipartie.
• UCS2 concaténé avec référence sur 8 bits : 67 unités UCS2 par segment multipartie.
• GSM 7 bits concaténé avec référence sur 16 bits : 152 septets par segment multipartie.
• UCS2 concaténé avec référence sur 16 bits : 66 unités UCS2 par segment multipartie.
• D’autres IE dans l’UDH peuvent réduire davantage la capacité disponible.

Comment calculer les segments de manière auditable

Pour le GSM 7 bits, classez chaque caractère du texte final dans la table de base ou la table d’extension. Chaque caractère de la table de base consomme un septet. Chaque caractère de la table d’extension consomme deux septets, car il est encodé au moyen d’un caractère d’échappement suivi du code d’extension.

La formule est la suivante : septets GSM = caractères de la table de base + 2 × caractères de la table d’extension. Si le résultat tient dans 160 septets, il s’agit d’un message simple. S’il dépasse cette limite, divisez le total par la capacité concaténée applicable et arrondissez à l’entier supérieur. Pour une référence sur 8 bits, la capacité de planification habituelle est de 153 septets par segment multipartie ; pour une référence sur 16 bits, elle est de 152. En GSM 7 bits avec UDH, confirmez le résultat à partir du TP-UD construit, en tenant compte de UDHL, des bits de remplissage et de l’empaquetage des septets conformément à TP-UDHI. Ajustez la capacité si d’autres IE sont présents dans l’UDH.

Pour UCS2, si le texte est formé de caractères représentables dans une unité UCS2 de 16 bits, comptez les unités UCS2. Divisez par 70 en l’absence de concaténation, par 67 lorsqu’un UDH de concaténation avec référence sur 8 bits est utilisé, ou par 66 avec une référence sur 16 bits, en arrondissant à l’entier supérieur. Ces résultats expriment des unités UCS2, et non des caractères Unicode universels. Si votre pile technique accepte UTF-16, des caractères hors du Basic Multilingual Plane ou applique ses propres transformations, ne réutilisez pas ce calcul sans vérifier comment ces caractères sont mesurés, transformés et segmentés.

• Formule GSM 7 bits : caractères de base + 2 × caractères étendus.
• Segments GSM simples : 1 si les septets sont inférieurs ou égaux à 160.
• Segments GSM concaténés : plafond du total de septets divisé par 153 ou 152, selon l’UDH appliqué, après validation du TP-UD construit, de UDHL, des bits de remplissage et de l’empaquetage des septets.
• Segments UCS2 simples : plafond des unités UCS2 divisé par 70.
• Segments UCS2 concaténés : plafond des unités UCS2 divisé par 67 avec une référence sur 8 bits, ou par 66 avec une référence sur 16 bits.
• Ajustez la capacité si l’UDH contient d’autres IE ou si la route applique une autre méthode de segmentation.

Caractères étendus GSM 03.38 : un caractère visible peut occuper deux septets

La table d’extension GSM 7 bits permet de conserver certains symboles sans activer UCS2, mais ils ne sont pas sans coût en capacité. Parmi eux figurent €, ^, {, }, [, ], ~ et la barre oblique inversée. Bien que chacun apparaisse comme un seul caractère, il requiert une séquence d’échappement et consomme deux septets.

Ce détail est important à proximité des limites. Un texte de 158 caractères visibles ne tient pas nécessairement dans un SMS GSM 7 bits. S’il contient trois caractères d’extension, sa consommation sera de 161 septets, même si tous les autres caractères appartiennent à la table de base. Dans ce cas, le texte passe en concaténation.

Le calcul des septets pour ces symboles est déterminé par la table GSM 03.38. D’un point de vue opérationnel, vérifiez que l’implémentation et la route appliquent l’encodage attendu. Un compteur opérationnel doit afficher au minimum trois valeurs : les caractères visibles, le nombre de caractères étendus et le total de septets GSM. Afficher uniquement la longueur visuelle peut conduire à des validations incorrectes.

• Caractères étendus fréquents : €, ^, {, }, [, ], ~ et barre oblique inversée.
• Chaque caractère étendu GSM consomme deux septets.
• Calculez les septets selon la table GSM 03.38 et validez l’implémentation de la route.
• Vérifiez particulièrement les prix, les montants, les codes, les expressions techniques et les URL contenant des symboles.
• Ne remplacez pas automatiquement les caractères sans politique approuvée : un remplacement peut modifier le sens du contenu.

Ce qui active généralement Unicode et comment prévenir les changements inattendus

Les guillemets typographiques, les emojis, les alphabets non latins et de nombreux symboles copiés depuis des traitements de texte, des feuilles de calcul, des outils de conception ou des systèmes de gestion de contenu peuvent ne pas faire partie du GSM 7 bits. Il ne faut pas décider par intuition : le validateur doit comparer chaque point de code du contenu avec la table de base GSM et sa table d’extension.

Les guillemets droits et les guillemets typographiques se ressemblent visuellement, mais n’ont pas nécessairement la même représentation. Il en va de même pour les tirets, les espaces spéciaux, les marques déposées, les icônes et les variantes stylisées de lettres ou de chiffres. Le risque ne consiste pas seulement à appliquer une stratégie différente du GSM 7 bits, comme une conversion en UCS2 : une modification ultérieure peut augmenter le nombre de segments et modifier la prévision de capacité.

La mesure préventive la plus solide consiste à normaliser le texte conformément à une politique documentée, à conserver à la fois la version originale et la version normalisée, puis à recalculer l’encodage et les segments après chaque substitution dynamique. Lorsqu’un caractère hors GSM 7 bits est détecté, la politique doit définir si un encodage explicite est utilisé, si le texte est converti en UCS2, remplacé, transformé ou rejeté.

• Détectez les caractères hors GSM 7 bits avant l’envoi.
• Vérifiez le contenu collé depuis des outils d’édition et des bibliothèques de modèles.
• Validez les valeurs de variables avec le même moteur que celui qui valide le corps fixe.
• Conservez le texte original et le texte normalisé afin de pouvoir expliquer les différences.
• Exigez une nouvelle approbation si le texte final change d’encodage ou de tranche de segments.

Exemples de calcul

Exemple 1, OTP : « Votre code d’accès est 482913. » Si tous les caractères appartiennent à la table de base GSM, le message est calculé en septets GSM et reste largement dans la limite des 160 d’un message simple. La recommandation opérationnelle consiste à effectuer le calcul après l’insertion du code réel et de tout préfixe ou signature ajouté en production.

Exemple 2, notification transactionnelle : « Commande 8742 confirmée. Total : 18€. » Cet exemple suppose que, à l’exception du symbole €, le reste des caractères utilisés appartient au répertoire GSM de base applicable. Le symbole € fait partie de la table d’extension GSM. Le message peut rester en GSM 7 bits, mais le € consomme deux septets. Pour un texte court, cela ne modifie pas le nombre de parties, mais doit être reflété dans le compteur et l’audit.

Exemple 3, message promotionnel avec consentement : si une campagne approuvée inclut un guillemet typographique ou un emoji, le texte requiert une stratégie alternative au GSM 7 bits. Selon la configuration, il peut être converti en UCS2, nécessiter un encodage explicite, être remplacé, transformé ou rejeté. Si UCS2 est utilisé, la capacité d’un message simple tombe à 70 unités UCS2 et celle d’un segment multipartie est de 67 avec une référence sur 8 bits ou de 66 avec une référence sur 16 bits, selon ces hypothèses d’UDH. Avant de modifier le contenu, le responsable doit décider s’il conserve le caractère, adopte une alternative approuvée compatible GSM ou repense le texte afin de maîtriser le nombre de parties.

Dans les trois cas, il ne faut pas estimer à partir d’une longueur générique du modèle. Les URL, le nom de marque, les variables, les textes réglementaires, STOP/HELP lorsqu’ils s’appliquent et tout texte ajouté par le système expéditeur doivent être inclus.

• OTP : calculez après insertion du code final.
• Transactionnel avec € : si le reste du texte appartient au répertoire GSM de base applicable, restez en GSM 7 bits, mais ajoutez un septet par rapport à un caractère de base.
• Promotionnel avec consentement comprenant un emoji ou des guillemets typographiques : appliquez la stratégie configurée pour les caractères hors GSM 7 bits.
• N’utilisez pas des exemples de texte comme substitut à la validation de chaque message rendu.

Tableau opérationnel de planification et d’approbation

Un tableau opérationnel transforme le calcul technique en contrôle reproductible. Il doit être renseigné par modèle et par version, ainsi que lorsqu’une variable peut modifier de manière significative l’encodage ou le nombre de segments. Il n’est pas nécessaire de considérer ces champs comme des exigences réglementaires ; ce sont des contrôles recommandés pour pouvoir examiner une décision et reproduire l’envoi.

Le champ des segments prévus doit indiquer l’hypothèse technique utilisée. Par exemple, il ne suffit pas d’enregistrer « 2 segments » : il est préférable d’indiquer « 2 GSM 7 bits, UDH de concaténation avec référence sur 8 bits, 153 septets par segment multipartie ». Cela évite qu’une autre intégration applique une méthode différente sans que cela soit détecté.

Dans SMPP, SAR décrit un message concaténé au moyen de paramètres relatifs à la référence de l’ensemble, au nombre total de segments et à la position de chaque fragment. La spécification SMPP ne garantit pas, de manière générale, que le SMSC segmentera automatiquement le message ni qu’il encapsulera le contenu dans un UDH : ce comportement dépend du SMSC et de l’accord technique de la route. Dans les réseaux GSM, SMPP v3.4 indique que les TLV SAR de concaténation ne doivent pas être combinés avec un UDH de concaténation déjà encodé dans short_message.

• Identifiant et version du modèle.
• Texte original et texte après normalisation.
• Exemple de texte final rendu avec les variables résolues.
• Encodage prévu : GSM 7 bits ou UCS2.
• Caractères de base, caractères étendus et total de septets, le cas échéant.
• Unités UCS2, le cas échéant.
• Segments prévus et seuil de capacité utilisé.
• Type d’UDH ou mécanisme SAR sélectionné pour la concaténation SMPP, le cas échéant. Dans les réseaux GSM, ne combinez pas les TLV SAR de concaténation avec un UDH de concaténation encodé dans short_message. Si un UDH est encodé dans les données utilisateur, activez l’indicateur UDHI dans esm_class conformément à SMPP v3.4.