Heeft u wel eens een eenvoudige afspraakherinnering naar uw klanten gestuurd, om er vervolgens achter te komen dat uw SMS-factuur zonder duidelijke reden was verdubbeld? Dit fenomeen is direct gerelateerd aan **SMS-berichtcodering**, een technisch aspect dat vaak over het hoofd wordt gezien, maar dat een grote impact kan hebben op uw communicatiebudget.

Wat is de codering van een SMS-bericht?

Voor een duidelijke definitie van SMS-codering moet u begrijpen dat mobiele netwerken niet alle tekens op dezelfde manier lezen. Codering is het technische proces dat de letters, cijfers en symbolen van uw bericht omzet in binaire gegevens (0'en en 1'en) die door telecomproviders kunnen worden verzonden.

Historisch gezien is het mobiele netwerk ontworpen om zeer lichte berichten te verzenden. Twee belangrijke standaarden bepalen tegenwoordig het verzenden van SMS-berichten:

  • GSM-7: De standaardcodering die 7 bits per teken gebruikt. Hiermee kunt u tot 160 tekens in één enkele SMS schrijven.
  • UCS-2 (Unicode): Een uitgebreidere codering die 16 bits per teken gebruikt, wat nodig is voor niet-Latijnse alfabetten, complexe speciale tekens en emoji's. Dit beperkt de grootte van een enkele SMS tot slechts 70 tekens.

GSM-7 vs UCS-2: De valkuil van speciale tekens en emoji's

Dit is waar de complicaties beginnen voor eigenaren van kleine bedrijven (kapsalons, medische klinieken, rijscholen). Eén enkel teken buiten de GSM-7-tabel dwingt uw hele bericht om over te schakelen naar Unicode.

De SMS-codering van speciale tekens en accenten zoals "ç", "ê" of "ë" (die in het Frans veel voorkomen) en het verzenden van emoji's via SMS met UCS-2-codering verlagen uw limiet onmiddellijk van 160 naar 70 tekens per bericht. De impact van emoji's op SMS-codering is dan ook direct merkbaar: uw bericht wordt opgesplitst in meerdere delen (segmenten), wat de verzendkosten bij de meeste traditionele providers vermenigvuldigt.

Hier is een vergelijkingstabel om dit verschil beter te visualiseren:

CoderingsstandaardTekenlimiet (1 SMS)Toegestane tekensImpact op klassieke facturering
GSM-7160 tekensBasis Latijns alfabet, cijfers, spaties en enkele veelvoorkomende accenten (é, à, è, ù)Standaardtarief (1 credit)
UCS-2 (Unicode)70 tekensAlle alfabetten (Arabisch, Cyrillisch, Chinees), emoji's, complexe accenten (ç, ê, ï)Verdubbelde of verdrievoudigde tarieven (meerdere segmenten)

De impact van Unicode-codering op de SMS-prijs

De impact van Unicode-codering op de SMS-prijs is de grootste financiële valkuil bij klassieke SMS-gateways zoals Twilio of Plivo. Deze platformen rekenen af per SMS-"segment". Een segment komt overeen met 160 tekens in GSM-7, maar daalt naar 70 tekens zodra er één enkel Unicode-teken wordt gedetecteerd.

Stel dat u een autogarage runt en deze afspraakherinnering verstuurt:

"Beste klant! Uw voertuig staat klaar. Gelieve deze voor 18:00 uur op te halen bij de garage. Tot snel!"

Dit bericht bevat 102 tekens. Als u het zo verzendt, gebruikt het de standaard GSM-7-codering (sommige gateways kunnen soms moeite hebben met bepaalde hoofdletters met accenten, maar de rest is standaard). Dit kost u 1 SMS-segment.

Als u aan het einde een eenvoudige auto-emoji toevoegt om het bericht klantvriendelijker te maken, schakelt het bericht over naar UCS-2. Uw 103 tekens overschrijden nu de strikte Unicode-limiet van 70 tekens. Uw bericht wordt dan opgesplitst in 2 segmenten. Bij een traditionele provider betaalt u het dubbele voor dit bericht, alleen vanwege een emoji.

Om dit soort onaangename verrassingen te voorkomen, zoeken veel bedrijven naar alternatieven. Met MySMSGate koppelt u uw eigen Android-smartphone om uw berichten te verzenden. Wij hanteren een uniek en vast tarief van $ 0,02 per verzonden SMS, ongeacht de lengte of de codering. Er zijn geen verborgen kosten per segment. Raadpleeg onze gids over de goedkoopste SMS-gateway voor kleine bedrijven voor meer informatie over voordelige opties.

Ontwikkelaars: Welke codering kiezen voor het verzenden van een SMS via API?

Als u SMS-notificaties integreert in uw eigen applicatie of beheersoftware, rijst de technische vraag: welke codering moet u kiezen om een SMS via API te verzenden?

Vrijwel alle moderne API's, inclusief die van MySMSGate, accepteren verzoeken in JSON-formaat gecodeerd in UTF-8. De SMS-gateway moet deze UTF-8-stroom vervolgens echter converteren naar het mobiele netwerk. Om maximale compatibiliteit te garanderen en verminkte tekens (de bekende vraagtekens of zwarte blokjes) te voorkomen, is het essentieel om de UTF-8-codering van uw SMS-gateway goed te configureren.

Hier is een eenvoudig voorbeeld in Python om een correct gecodeerd bericht te verzenden via de API van MySMSGate zonder dat u zich zorgen hoeft te maken over complexe segmentatie:

import requests

url = "https://mysmsgate.net/api/v1/send"
headers = {
    "Authorization": "Bearer VOTRE_CLE_API",
    "Content-Type": "application/json"
}
payload = {
    "to": "+33612345678",
    "message": "Votre rendez-vous est confirmé pour demain à 14h ! ",
    "sim_slot": 1
}

response = requests.post(url, json=payload, headers=headers)
print(response.json())

Onze API regelt de conversie op een transparante manier. Bovendien bevat ons systeem een automatisch terugbetalingsmechanisme in geval van mislukte aflevering, zodat u alleen betaalt voor wat daadwerkelijk werkt. Lees onze handleiding voor het verzenden van SMS vanaf een Android-telefoon via API voor een volledige integratie op uw eigen server.

Hoe voorkomt u dubbele SMS-codering?

Om dubbele SMS-codering te voorkomen, moet u ervoor zorgen dat uw code geen coderingsfunctie (zoals urlencode of utf8_encode) toepast op een tekenreeks die al door uw HTTP-bibliotheek wordt verwerkt. Het verzenden van dubbel gecodeerde gegevens resulteert in onleesbare berichten met vreemde reeksen symbolen voor uw klanten.

Het speciale geval van de SMS/MMS-video-encoding preset

In de mobiele telecomsector kunt u soms de term preset encodage sms/mms video tegenkomen. In tegenstelling tot tekstcodering (GSM-7 of UCS-2) heeft deze preset betrekking op de compressie en opmaak van multimediabestanden (video's, geanimeerde afbeeldingen) die via MMS worden verzonden.

Mobiele netwerken leggen zeer strikte limieten op aan de grootte van MMS-berichten (vaak minder dan 300 KB of 600 KB, afhankelijk van de provider). De video-encoding preset verlaagt de resolutie en bitrate van een video drastisch, zodat deze zonder weigering door de gateway van de provider kan worden verzonden. Als uw doel alleen het verzenden van tekstnotificaties of operationele herinneringen is, hoeft u zich geen zorgen te maken over deze complexe instellingen.

Veelgestelde vragen over SMS-codering

Hier vindt u de antwoorden op de meest gestelde vragen over het beheer van codering en speciale tekens bij het verzenden van zakelijke SMS-berichten.

Waarom kan een eenvoudig accent de prijs van mijn SMS verdubbelen?

Bepaalde tekens zoals de "ç" (c-cedille), de "ê" (e met circumflex) of de "à" (a met accent grave) maken geen deel uit van het standaard GSM-7-alfabet. Zodra u een van deze tekens gebruikt, schakelt uw verzendsoftware het hele bericht over naar de Unicode-modus (UCS-2). De limiet per SMS daalt dan van 160 naar 70 tekens. Als uw tekst langer is dan 70 tekens, wordt deze in twee segmenten verdeeld, waardoor de verzendkosten bij traditionele providers verdubbelen.

Hoe kan ik de codering van mijn SMS-berichten testen voordat ik ze verzend?

Er zijn online tools om SMS-segmenten te testen (vaak "SMS Length Calculator" genoemd). Hiermee kunt u uw tekst plakken en direct zien of een onzichtbaar teken of een emoji de overschakeling naar Unicode dwingt, evenals het exacte aantal segmenten dat door uw provider in rekening wordt gebracht.

Hoe helpt MySMSGate om extra kosten door Unicode te voorkomen?

In tegenstelling tot klassieke API's (Twilio, Plivo) die elk segment afzonderlijk factureren, hanteert MySMSGate een uniek en vast tarief van $ 0,02 per verzonden bericht, ongeacht de lengte of het gebruik van speciale tekens of emoji's. Uw berichten worden rechtstreeks verzonden via uw eigen Android-smartphone die is gekoppeld aan ons platform, waardoor onredelijke segmentatiekosten worden geëlimineerd.