GSM 03.38, Unicode und verkettete SMS: Segmente vor dem Versand berechnen

Welches Problem die Segmentberechnung löst

Bei SMS reicht es nicht aus, sichtbare Zeichen zu zählen. Die Anzahl der Segmente hängt vom tatsächlich kodierten Text, vom gewählten Alphabet und – wenn der Inhalt ein Segment überschreitet – vom Verkettungsmechanismus ab. Ein sichtbares Zeichen kann in GSM-7-Bit eine oder zwei Positionen belegen, und ein Zeichen außerhalb der GSM-03.38-Tabellen kann je nach Plattformkonfiguration eine alternative Strategie erfordern, etwa eine explizite Kodierung, Konvertierung zu UCS2, Ersetzung, Umwandlung oder Ablehnung.

Der Unterschied ist operativ relevant. Er beeinflusst die Volumenschätzung, Kostenkontrolle, die für eine Kampagne reservierte Kapazität und das Empfängererlebnis. Er kann sich auch nach der Freigabe einer Vorlage ändern, wenn eine Variable, eine Signatur, ein Link oder ein Compliance-Text andere Zeichen einführt oder einen Längenschwellenwert überschreitet.

Die praktische Regel lautet: Berechnen Sie immer auf Grundlage der final gerenderten Nachricht, nicht auf Grundlage einer abstrakten Vorlage oder eines generischen Zeichenzählers.

• Bewahren Sie den exakten zu sendenden Text auf, einschließlich aufgelöster Variablen.
• Bestimmen Sie die Kodierung, bevor Sie Segmente schätzen.
• Zählen Sie bei GSM-7-Bit Septette, nicht nur darstellbare Zeichen.
• Zählen Sie UCS2-Einheiten mit 16 Bit, wenn der Text als UCS2 verarbeitet wird.
• Wenden Sie die Kapazität an, die zur konfigurierten Verkettungsmethode gehört.

Die zwei relevanten Kodierungen: GSM 03.38 und UCS2

Für die praktische SMS-Planung sind GSM-7-Bit auf Basis des Alphabets GSM 03.38 und UCS2 die zwei wichtigsten Kodierungen. GSM-7-Bit kann ohne UDH bis zu 160 Septette in den 140 für Nutzdaten verfügbaren Oktetten verpacken. UCS2 verwendet 16-Bit-Einheiten innerhalb eines auf die Basic Multilingual Plane begrenzten Repertoires und erlaubt bis zu 70 UCS2-Einheiten in einer einzelnen Nachricht.

GSM-7-Bit ist kein visuelles Unicode-Teilsystem, das nach dem Erscheinungsbild ausgewählt wird. Es ist ein definiertes Repertoire aus Grundzeichen und einer Erweiterungstabelle. Wenn jedes Zeichen des finalen Texts zu diesen anwendbaren Tabellen gehört, kann die Nachricht in GSM-Septetten berechnet werden. Tritt ein Zeichen außerhalb dieses Repertoires auf, ist eine alternative Strategie erforderlich. Viele Plattformen kodieren es oder wandeln es in UCS2 um; andere können es ablehnen, ersetzen oder eine explizite Kodierung verlangen.

UCS2 ist nicht gleichbedeutend mit Unicode oder UTF-16. UCS2 ist ein auf die Basic Multilingual Plane begrenztes Repertoire und eine 16-Bit-Kodierung. Manche kommerziell als „UCS2“ bezeichneten Implementierungen akzeptieren möglicherweise UTF-16 oder führen eigene Umwandlungen durch. Prüfen Sie deshalb insbesondere bei Zeichen außerhalb der Basic Multilingual Plane, wie Ihre Implementierung und Ihr Messaging-Anbieter Inhalte messen, umwandeln und segmentieren.

• GSM-7-Bit ohne UDH: bis zu 160 Septette.
• UCS2 ohne UDH: bis zu 70 UCS2-Einheiten mit 16 Bit.
• Wählen Sie die Kodierung nicht anhand der Sprache einer Kampagne: Prüfen Sie sie gegen den finalen Text.
• Setzen Sie Unicode-Unterstützung im Editor nicht mit GSM-7-Bit-Kompatibilität gleich.
• Prüfen Sie das Verhalten von Zeichen außerhalb der Basic Multilingual Plane in Ihrer konkreten Implementierung.

Praktische Segmentgrenzen und Auswirkungen der Verkettung

Eine einzelne Nachricht kann bis zu 160 Septette in GSM-7-Bit oder bis zu 70 UCS2-Einheiten mit 16 Bit transportieren. Benötigt der Inhalt mehrere Segmente, benötigt jeder Teil Informationen, damit das Endgerät den Satz und seine Reihenfolge erkennen kann. Diese Informationen werden üblicherweise über einen User Data Header, kurz UDH, übertragen und verringern die für Text verfügbare Nutzlast.

Mit einem Verkettungs-IE mit 8-Bit-Referenz belegt der UDH 6 Oktette. Von der Grenze von 140 Oktetten des TP-UD bleiben 134 Oktette für Inhalte. Das entspricht technisch 153 GSM-7-Bit-Septetten pro mehrteiligem Segment oder 67 UCS2-Einheiten pro mehrteiligem Segment. Bei einer 16-Bit-Referenz belegt der UDH ein Oktett mehr: Die praktische Kapazität sinkt auf 152 GSM-7-Bit-Septette oder 66 UCS2-Einheiten pro mehrteiligem Segment.

Bei GSM-7-Bit mit UDH muss die Berechnung die Auffüllung und Septettausrichtung gemäß TP-UDHI berücksichtigen. Die Werte 153 und 152 sind übliche Kapazitäten, die aus den Nutzdatengrenzen und den genannten Verkettungsstrukturen abgeleitet werden. Die endgültige Implementierung muss das aufgebaute TP-UD messen, besonders wenn weitere IEs zum UDH hinzugefügt werden. Die tatsächliche Methode einer Route kann von diesen Annahmen abweichen; bestätigen Sie die genaue Segmentierungs-, Aufteilungs- und Abrechnungsmethode Ihres SMSC, Ihrer Route oder Ihres Anbieters, bevor Sie sie als Vertrags- oder Abrechnungsregel festlegen.

• GSM-7-Bit, einzelne Nachricht: 160 Septette.
• UCS2, einzelne Nachricht: 70 UCS2-Einheiten mit 16 Bit.
• Verkettetes GSM-7-Bit mit 8-Bit-Referenz: 153 Septette pro mehrteiligem Segment.
• Verkettetes UCS2 mit 8-Bit-Referenz: 67 UCS2-Einheiten pro mehrteiligem Segment.
• Verkettetes GSM-7-Bit mit 16-Bit-Referenz: 152 Septette pro mehrteiligem Segment.
• Verkettetes UCS2 mit 16-Bit-Referenz: 66 UCS2-Einheiten pro mehrteiligem Segment.
• Weitere IEs im UDH können die verfügbare Kapazität weiter reduzieren.

Segmente nachvollziehbar berechnen

Für GSM-7-Bit ordnen Sie jedes Zeichen des finalen Texts der Grundtabelle oder der Erweiterungstabelle zu. Jedes Zeichen der Grundtabelle verbraucht ein Septett. Jedes Zeichen der Erweiterungstabelle verbraucht zwei Septette, weil es als Escape-Zeichen gefolgt vom Erweiterungscode kodiert wird.

Die Formel lautet: GSM-Septette = Zeichen der Grundtabelle + 2 × Zeichen der Erweiterungstabelle. Passt das Ergebnis in 160 Septette, handelt es sich um eine einzelne Nachricht. Überschreitet es diesen Wert, teilen Sie die Gesamtsumme durch die anwendbare verkettete Kapazität und runden Sie auf. Bei 8-Bit-Referenz beträgt die übliche Planungskapazität 153 Septette pro mehrteiligem Segment, bei 16-Bit-Referenz 152. Bei GSM-7-Bit mit UDH bestätigen Sie das Ergebnis anhand des aufgebauten TP-UD und passen die Kapazität an, falls weitere IEs im UDH vorhanden sind.

Für UCS2 zählen Sie UCS2-Einheiten, wenn der Text aus Zeichen besteht, die in einer UCS2-Einheit mit 16 Bit darstellbar sind. Teilen Sie ohne Verkettung durch 70 oder bei einem Verkettungs-UDH mit 8-Bit-Referenz durch 67 und runden Sie auf. Diese Ergebnisse geben UCS2-Einheiten an, nicht universelle Unicode-Zeichen. Wenn Ihr technischer Stack UTF-16 akzeptiert, Zeichen außerhalb der Basic Multilingual Plane verarbeitet oder eigene Umwandlungen vornimmt, verwenden Sie diese Berechnung nicht ohne zu prüfen, wie diese Zeichen gemessen, umgewandelt und segmentiert werden.

• GSM-7-Bit-Formel: Grundzeichen + 2 × Erweiterungszeichen.
• Einfache GSM-Segmente: 1, wenn die Septettzahl 160 oder weniger beträgt.
• Verkettete GSM-Segmente: Aufrunden der Gesamtseptette geteilt durch 153 oder 152, abhängig vom verwendeten UDH und nach Validierung des aufgebauten TP-UD.
• Einfache UCS2-Segmente: Aufrunden der UCS2-Einheiten geteilt durch 70.
• Verkettete UCS2-Segmente mit 8-Bit-Referenz: Aufrunden der UCS2-Einheiten geteilt durch 67.
• Passen Sie die Kapazität an, wenn der UDH weitere IEs enthält oder die Route eine andere Segmentierungsmethode verwendet.

Erweiterte GSM-03.38-Zeichen: Ein sichtbares Zeichen kann zwei Septette belegen

Die GSM-7-Bit-Erweiterungstabelle ermöglicht es, bestimmte Symbole beizubehalten, ohne UCS2 zu aktivieren, doch sie sind nicht kapazitätsneutral. Dazu gehören €, ^, {, }, [, ], ~ und der umgekehrte Schrägstrich. Obwohl jedes davon als einzelnes Zeichen angezeigt wird, benötigt es eine Escape-Sequenz und verbraucht zwei Septette.

Dieses Detail ist in der Nähe der Grenzen wichtig. Ein Text mit 158 sichtbaren Zeichen passt nicht zwangsläufig in eine GSM-7-Bit-SMS. Enthält er drei Erweiterungszeichen, beträgt sein Verbrauch 161 Septette, selbst wenn alle übrigen Zeichen zur Grundtabelle gehören. In diesem Fall wird der Text verkettet.

Die Septettberechnung für diese Symbole wird durch die Tabelle GSM 03.38 bestimmt. Operativ sollten Sie prüfen, ob Implementierung und Route die erwartete Kodierung anwenden. Ein operativer Zähler sollte mindestens drei Werte anzeigen: sichtbare Zeichen, Anzahl der Erweiterungszeichen und gesamte GSM-Septette. Nur die visuelle Länge anzuzeigen kann zu fehlerhaften Freigaben führen.

• Häufige Erweiterungszeichen: €, ^, {, }, [, ], ~ und umgekehrter Schrägstrich.
• Jedes erweiterte GSM-Zeichen verbraucht zwei Septette.
• Berechnen Sie Septette anhand der Tabelle GSM 03.38 und prüfen Sie die Routenimplementierung.
• Prüfen Sie besonders Preise, Beträge, Codes, technische Ausdrücke und URLs mit Symbolen.
• Ersetzen Sie Zeichen nicht automatisch ohne genehmigte Richtlinie: Eine Ersetzung kann die Bedeutung des Inhalts verändern.

Was Unicode häufig aktiviert und wie unerwartete Änderungen verhindert werden

Typografische Anführungszeichen, Emojis, nicht lateinische Alphabete und viele Symbole, die aus Textverarbeitungen, Tabellenkalkulationen, Designwerkzeugen oder Content-Management-Systemen kopiert werden, gehören möglicherweise nicht zu GSM-7-Bit. Die Entscheidung darf nicht intuitiv getroffen werden: Der Validator muss jeden Codepunkt des Inhalts mit der GSM-Grundtabelle und ihrer Erweiterungstabelle abgleichen.

Gerade und typografische Anführungszeichen sehen ähnlich aus, haben aber nicht zwangsläufig dieselbe Darstellung. Dasselbe gilt für Bindestriche, Sonderleerzeichen, eingetragene Marken, Symbole sowie stilisierte Varianten von Buchstaben oder Zahlen. Das Risiko besteht nicht nur darin, eine andere Strategie als GSM-7-Bit anzuwenden, etwa die Konvertierung zu UCS2: Eine nachträgliche Änderung kann die Segmentzahl erhöhen und die Kapazitätsplanung verändern.

Die solideste Präventivmaßnahme besteht darin, Text nach einer dokumentierten Richtlinie zu normalisieren, sowohl die Original- als auch die normalisierte Version aufzubewahren und Kodierung sowie Segmente nach jeder dynamischen Ersetzung neu zu berechnen. Wird ein Zeichen außerhalb von GSM-7-Bit erkannt, muss die Richtlinie festlegen, ob eine explizite Kodierung verwendet, zu UCS2 konvertiert, ersetzt, umgewandelt oder der Inhalt abgelehnt wird.

• Erkennen Sie Zeichen außerhalb von GSM-7-Bit vor dem Versand.
• Prüfen Sie Inhalte, die aus Bearbeitungswerkzeugen und Vorlagenbibliotheken eingefügt wurden.
• Validieren Sie Variablenwerte mit derselben Engine wie den festen Nachrichtentext.
• Bewahren Sie Originaltext und normalisierten Text auf, um Unterschiede erklären zu können.
• Fordern Sie eine erneute Freigabe, wenn sich die Kodierung oder die Segmentstufe des finalen Texts ändert.

Berechnungsbeispiele

Beispiel 1, OTP: „Ihr Zugangscode lautet 482913.“ Wenn alle Zeichen zur GSM-Grundtabelle gehören, wird die Nachricht in GSM-Septetten berechnet und liegt deutlich innerhalb der 160 Septette einer einzelnen Nachricht. Operativ empfiehlt es sich, die Berechnung nach dem Einfügen des tatsächlichen Codes sowie jedes Präfixes oder jeder Signatur durchzuführen, die in der Produktion hinzugefügt wird.

Beispiel 2, Transaktionsbenachrichtigung: „Bestellung 8742 bestätigt. Gesamt: 18€.“ Dieses Beispiel setzt voraus, dass außer dem Symbol € alle verwendeten Zeichen zum anwendbaren GSM-Grundrepertoire gehören. Das Symbol € gehört zur GSM-Erweiterungstabelle. Die Nachricht kann in GSM-7-Bit bleiben, doch € verbraucht zwei Septette. Bei einem kurzen Text ändert dies nicht die Anzahl der Teile, muss aber im Zähler und in der Prüfung berücksichtigt werden.

Beispiel 3, einwilligungsbasierte Werbenachricht: Enthält eine freigegebene Kampagne ein typografisches Anführungszeichen oder ein Emoji, benötigt der Text eine Alternative zu GSM-7-Bit. Je nach Konfiguration kann er zu UCS2 konvertiert werden, eine explizite Kodierung erfordern, ersetzt, umgewandelt oder abgelehnt werden. Bei UCS2 sinkt die Kapazität einer einzelnen Nachricht auf 70 UCS2-Einheiten und die eines mehrteiligen Segments bei 8-Bit-Referenz unter diesen UDH-Annahmen auf 67. Vor einer Inhaltsänderung muss die verantwortliche Person entscheiden, ob sie das Zeichen beibehält, eine genehmigte GSM-kompatible Alternative verwendet oder den Text neu gestaltet, um die Anzahl der Teile zu kontrollieren.

In allen drei Fällen darf nicht mit einer generischen Vorlagenlänge geschätzt werden. URLs, Markenname, Variablen, regulatorische Texte, STOP/HELP, sofern zutreffend, sowie jeder vom sendenden System hinzugefügte Text müssen einbezogen werden.

• OTP: Berechnen Sie nach dem Einfügen des finalen Codes.
• Transaktionsnachricht mit €: Wenn der übrige Text zum anwendbaren GSM-Grundrepertoire gehört, bleibt sie in GSM-7-Bit, aber gegenüber einem Grundzeichen ist ein zusätzliches Septett hinzuzurechnen.
• Einwilligungsbasierte Werbenachricht mit Emoji oder typografischen Anführungszeichen: Wenden Sie die konfigurierte Strategie für Zeichen außerhalb von GSM-7-Bit an.
• Verwenden Sie Textbeispiele nicht als Ersatz für die Validierung jeder gerenderten Nachricht.

Operative Tabelle für Planung und Freigabe

Eine operative Tabelle macht die technische Berechnung zu einer wiederholbaren Kontrolle. Sie sollte je Vorlage und Version erfasst werden sowie dann, wenn eine Variable Kodierung oder Segmentzahl wesentlich verändern kann. Diese Felder müssen nicht als regulatorische Anforderungen behandelt werden; sie sind empfohlene Kontrollen, um eine Entscheidung überprüfen und den Versand reproduzieren zu können.

Das Feld für erwartete Segmente sollte die verwendete technische Annahme nennen. Es reicht beispielsweise nicht aus, „2 Segmente“ zu erfassen: Sinnvoll ist „2 GSM-7-Bit, Verkettungs-UDH mit 8-Bit-Referenz, 153 Septette pro mehrteiligem Segment“. Dadurch wird verhindert, dass eine andere Integration unbemerkt eine andere Methode anwendet.

In SMPP beschreibt SAR eine verkettete Nachricht über Parameter für die Referenz des Satzes, die Gesamtzahl der Segmente und die Position jedes Fragments. Die SMPP-Spezifikation garantiert nicht allgemein, dass das SMSC eine Nachricht automatisch segmentiert oder den Inhalt in UDH kapselt: Dieses Verhalten hängt vom SMSC und von der technischen Vereinbarung der Route ab. In GSM-Netzen gibt SMPP v3.4 an, dass SAR-TLVs für die Verkettung nicht mit einem bereits in short_message kodierten Verkettungs-UDH kombiniert werden dürfen.

• Vorlagenkennung und -version.
• Originaltext und Text nach der Normalisierung.
• Beispiel eines final gerenderten Texts mit aufgelösten Variablen.
• Vorgesehene Kodierung: GSM-7-Bit oder UCS2.
• Grundzeichen, Erweiterungszeichen und gesamte Septette, sofern zutreffend.
• UCS2-Einheiten, sofern zutreffend.
• Erwartete Segmente und verwendeter Kapazitätsschwellenwert.
• Typ des UDH oder ausgewählter SAR-Mechanismus für die SMPP-Verkettung, sofern zutreffend. In GSM-Netzen dürfen SAR-TLVs für die Verkettung nicht mit einem in short_message kodierten Verkettungs-UDH kombiniert werden. Wenn ein UDH in den Nutzdaten kodiert wird, aktivieren Sie den UDHI-Indikator in esm_class gemäß SMPP v3.4.