IOSOR Kunskap

Hantera GSM-7 och Unicode Bytestergränser i API-nyttolaster

Styr regler för SMS-nyttolastkodning via IOSOR API-integrationer. Förhindra dolda avgifter för meddelandesegment i flera delar genom att programmässigt granska teckengränser.

Hantera GSM-7 och Unicode Bytestergränser i API-nyttolaster.

Detektering av teckenkodning i API-nyttolaster

När textnyttolaster skickas via API utvärderar systemet automatiskt om strängen ryms inom standardteckenuppsättningen GSM-7 eller kräver UCS-2 Unicode-kodning. Om en nyttolast innehåller ett enda tecken utanför GSM-7-alfabetet – som vissa emojisymboler eller icke-latinska skript – växlar hela SMS:et från 160 bitar per segment ner till 70 bitar per segment. Denna automatiska övergång förändrar antalet segment drastiskt och påverkar ditt förbetalda saldo.

Tekniska skillnader mellan GSM-7 och UCS-2

GSM-7-alfabetet innehåller vanliga latinska tecken, siffror och specifika grekiska symboler, packade effektivt i 7-bitarsenheter. Utökade tecken som parenteser, klammerparenteser och vissa symboler förbrukar dock två teckenenheter trots att de visas som enskilda glyfer. När UCS-2 utlöses kräver varje tecken 16 bitar (2 byte), vilket sänker den maximala meddelandelängden för ett enskilt segment från 160 tecken till 70.

Beräkning av meddelandesegment och gränser för flera delar

Beräkning av exakta segmentgränser kräver parsing av strängar byte för byte i stället för att enbart lita på stränglängdsmetoder i din lokala körtid. En nyttolast som innehåller 161 vanliga GSM-7-tecken delas upp i två segment, vilket effektivt fördubblar API-inlämningskostnaden för den enda sändningen. Om samma nyttolast utlöser Unicode på grund av ett vilseledande smart citattecken eller accenttecken, multipliceras kostnaden ytterligare över kortare segmenttrösklar.

Optimering av mallar för att förhindra oväntad fakturering

Meddelandemallar för OTP, transaktionsvarningar och aviseringar bör granskas noggrant för att ta bort dolda Unicode-tecken. Vanliga bovar inkluderar formaterad skiljetecken som kopierats från textredigerare, såsom tankstreck, smarta citattecken och hårda mellanslag. Att ersätta dessa med standard-ASCII-ekvivalenter garanterar GSM-7-efterlevnad och maximerar segmentkapaciteten.

Avstämning av DLR-loggar och API-reserverade data

Detaljerade leveransrapporter ger avgörande insyn i hur operatörsgatways bearbetade dina textnyttolaster. När avvikelser uppstår mellan förväntade segmentantal och faktiska reskontradragningar måste ingenjörsteam korsreferera webhook-loggar med IOSOR-transaktionsreskontran.

Börja med IOSOR

Konfigurera validering av teckenkodning före sändning i dina IOSOR-konsolinställningar eller i din API-integreringspipeline innan du skickar ut automatiserade mallar till produktion. Ställ in granskningar av nyttolasten för att rensa bort dolda Unicode-tecken och utvärdera antal byte innan anrop skickas vidare till nedströmsgateways. Övervaka dina webbhook-flöden för leveransrapporter och systemloggar för att omedelbart upptäcka oväntade sms-delningar som utlöses av utökade teckenuppsättningar.

IOSOR sammanfattning

Denna analys visar att ett enda tecken utanför standardstandarden – till exempel ett typografiskt anföringstecken, ett tankstreck eller en emoji – omedelbart omvandlar hela meddelandet från 7-bitars kodning till 16-bitars UCS-2, vilket drastiskt sänker gränsen för tecken per meddelandelängd från 160 till 70 tecken. Genom att tillämpa strikt byte-baserad parsning och identifiering av teckenkodning i skedet då meddelandet sätts ihop förhindras oavsiktlig uppdelning i flera delmeddelanden.

Var den här guiden till hjälp?

Relaterade guider