Har du noen gang sendt en enkel avtalepåminnelse til kundene dine, bare for å oppdage at SMS-fakturaen din ble doblet uten noen åpenbar grunn? Dette fenomenet er direkte knyttet til **SMS-koding**, et teknisk aspekt som ofte blir oversett, men som kan ha stor innvirkning på kommunikasjonsbudsjettet ditt.
Hva er SMS-koding?
For å gi en tydelig definisjon på SMS-koding, må man forstå at mobilnettverk ikke leser alle tegn på samme måte. Kodingen er den tekniske prosessen som konverterer bokstaver, tall og symboler i meldingen din til binære data (0-er og 1-ere) som kan overføres av teleoperatører.
Historisk sett ble mobilnettet designet for å overføre svært lette meldinger. To hovedstandarder styrer sendingen av SMS i dag:
- GSM-7: Standardkodingen som bruker 7 biter per tegn. Den lar deg skrive opptil 160 tegn i en enkelt SMS.
- UCS-2 (Unicode): En rikere koding som bruker 16 biter per tegn, nødvendig for ikke-latinske alfabeter, komplekse spesialtegn og emojier. Den begrenser størrelsen på en enkelt SMS til bare 70 tegn.
GSM-7 vs UCS-2: Fellen med spesialtegn og emojier
Det er her komplikasjonene starter for eiere av små bedrifter (frisørsalonger, medisinske klinikker, kjøreskoler). Et enkelt tegn utenfor GSM-7-tabellen tvinger hele meldingen til å bytte til Unicode.
SMS-koding av spesialtegn og aksenter som "ç", "ê" eller "ë", samt det å sende emojier med UCS-2 SMS-koding, reduserer umiddelbart tegngrensen din fra 160 til 70 per melding. Effekten av emojier på SMS-koding er derfor umiddelbar: Meldingen din blir delt opp i flere deler (segmenter), noe som flerdobler kostnaden for sendingen hos de fleste tradisjonelle leverandører.
Her er en sammenligningstabell for å visualisere denne forskjellen bedre:
| Kodingsstandard | Tegngrense (1 SMS) | Tillatte tegn | Innvirkning på tradisjonell fakturering | |
|---|---|---|---|---|
| GSM-7 | 160 tegn | Grunnleggende latinsk alfabet, tall, mellomrom og noen vanlige aksenter (é, à, è, ù) | Standard prising (1 kreditt) | |
| UCS-2 (Unicode) | 70 tegn | Alle alfabeter (arabisk, kyrillisk, kinesisk), emojier, komplekse aksenter (ç, ê, ï) | Dobbel eller trippel prising (flere segmenter) |
Unicode-kodingens innvirkning på SMS-prisen
Unicode-kodingens innvirkning på SMS-prisen er den største økonomiske fellen med klassiske SMS-gateways som Twilio eller Plivo. Disse plattformene tar betalt per "segment". Et segment tilsvarer 160 tegn i GSM-7, men synker til 70 tegn så snart et enkelt Unicode-tegn oppdages.
Se for deg at du driver et bilverksted og sender denne avtalepåminnelsen:
"Hei! Kjøretøyet ditt er klart. Vennligst kom og hent det før kl. 18:00 på verkstedet. Vi ses snart!"
Denne meldingen inneholder 99 tegn. Hvis du sender den som den er, bruker den standard GSM-7-koding (den store "À" med aksent kan noen ganger være problematisk avhengig av gateway, men resten er standard). Dette koster deg 1 SMS-segment.
Hvis du legger til en enkel bil-emoji på slutten for å gjøre meldingen mer innbydende, bytter meldingen til UCS-2. Dine 100 tegn overskrider nå Unicodes strenge grense på 70 tegn. Meldingen din blir da delt opp i 2 segmenter. Hos en tradisjonell operatør vil du betale dobbelt så mye for denne meldingen, kun på grunn av en emoji.
Det er for å unngå denne typen ubehagelige overraskelser at mange bedrifter ser etter alternativer. Med MySMSGate kobler du til din egen Android-smarttelefon for å sende meldinger. Vi tar en fast, flat takst på 0,02 $ per sendte SMS, uavhengig av lengde eller koding. Det er ingen skjulte kostnader per segment. For å lære mer om økonomiske alternativer, se vår guide om den rimeligste SMS-gatewayen for små bedrifter.
Utviklere: Hvilken koding bør du velge for å sende SMS via API?
Hvis du integrerer SMS-varsler i din egen applikasjon eller programvare, dukker det tekniske spørsmålet opp: hvilken koding bør du velge for å sende SMS via API?
Nesten alle moderne API-er, inkludert MySMSGate sitt, godtar forespørsler i JSON-format kodet i UTF-8. Imidlertid må SMS-gatewayen deretter konvertere denne UTF-8-strømmen til mobilnettet. For å sikre maksimal kompatibilitet og unngå ødelagte tegn (de beryktede spørsmålstegnene eller svarte firkantene), er det viktig å konfigurere UTF-8-koding for SMS-gatewayen riktig.
Her er et enkelt eksempel i Python for å sende en riktig kodet melding via MySMSGate sitt API uten å bekymre deg for komplekse oppdelinger:
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())Vårt API håndterer konverteringen sømløst. I tillegg har systemet vårt en automatisk refusjonsmekanisme ved leveringsfeil, noe som sikrer at du bare betaler for det som faktisk fungerer. For en fullstendig integrasjon på din egen server, les vår veiledning om å sende SMS fra en Android-telefon via API.
Hvordan unngå dobbel SMS-koding?
For å unngå dobbel SMS-koding, må du sørge for at koden din ikke bruker en kodingsfunksjon (som urlencode eller utf8_encode) på en tekststreng som allerede behandles av HTTP-biblioteket ditt. Sending av dobbeltkodede data fører til at kundene dine mottar uleselige meldinger med merkelige symboler.
Det spesielle tilfellet med forhåndsinnstilling for SMS/MMS-videokoding
Innen mobilkommunikasjon kan du av og til støte på begrepet forhåndsinnstilling for SMS/MMS-videokoding. I motsetning til tekstkoding (GSM-7 eller UCS-2), gjelder denne forhåndsinnstillingen komprimering og formatering av multimediefiler (videoer, animerte bilder) som sendes via MMS.
Mobilnettverk pålegger svært strenge størrelsesgrenser for MMS (ofte under 300 KB eller 600 KB avhengig av operatør). Forhåndsinnstillingen for videokoding gjør det mulig å redusere videooppløsningen og bithastigheten drastisk, slik at den kan leveres uten å bli avvist av operatørens gateway. Hvis målet ditt bare er å sende tekstvarsler eller operasjonelle påminnelser, trenger du ikke å bekymre deg for disse komplekse innstillingene.
Ofte stilte spørsmål om SMS-koding
Her er svarene på de vanligste spørsmålene om håndtering av koding og spesialtegn ved sending av profesjonelle SMS-er.
Hvorfor kan et enkelt spesialtegn eller en aksent doble prisen på min SMS?
Enkelte tegn som "ç", "ê" eller "ë" er ikke en del av standard GSM-7-alfabetet. Så snart du bruker et av disse tegnene, bytter programvaren din hele meldingen til Unicode-modus (UCS-2). Grensen per SMS synker da fra 160 til 70 tegn. Hvis teksten din overstiger 70 tegn, blir den delt inn i to segmenter, noe som dobler kostnaden for sendingen hos tradisjonelle operatører.
Hvordan kan jeg teste SMS-kodingen min før jeg sender?
Det finnes nettbaserte verktøy for å teste SMS-segmenter (ofte kalt "SMS Length Calculator"). De lar deg lime inn teksten din og umiddelbart se om et usynlig tegn eller en emoji tvinger meldingen over i Unicode, samt det nøyaktige antallet segmenter du vil bli fakturert for av leverandøren din.
Hvordan hjelper MySMSGate med å unngå ekstra kostnader knyttet til Unicode?
I motsetning til klassiske API-er (Twilio, Plivo) som fakturerer hvert segment individuelt, bruker MySMSGate en fast, flat takst på 0,02 $ per sendte melding, uavhengig av lengde eller bruk av spesialtegn og emojier. Meldingene dine sendes direkte via din egen Android-smarttelefon koblet til plattformen vår, noe som eliminerer urimelige segmenteringskostnader.
Comments (0)
Be the first to comment!