7 Things You Didn’t Know a Data Coding Scheme Controls (Including Your Text Messages)
Whenever a computer stores a file, sends a message, or reads a spreadsheet, something has to tell it precisely how to interpret the raw 1s and 0s it sees first. That instruction layer is the data encoding scheme—and it’s much more important than its plumbing-level name would suggest. Get it wrong and a perfectly good SMS turns into a string of question marks. Do it right, and terabytes of data flow across networks without losing a single character.
In this guide, we’ll break down what a data coding scheme does, the main types you’ll run into, and—because it matters directly if you’re working with SMS or Salesforce messaging—how this very concept determines whether your outbound texts come through as nice, clean 160-character messages or get truncated to 70 characters.
What Is a Data Coding Scheme?
A data coding scheme is a standardized way of encoding information into a form that can be reliably stored, transmitted, and interpreted by a computer or network. It is the agreed upon rulebook that tells a receiving system that these bytes are this character, this number, or this instruction.
This is worth separating out from compression, which people confuse all the time with these. We can encode data to provide a structured representation of it. For example, convert a letter into its binary equivalent. Compression, conversely, reduces file size by removing redundancy. A file can be coded and not compressed or compressed without changing the underlying coding scheme. They often work together, but they solve different problems.
Core Types of Data Coding Schemes
Lossless Coding vs. Lossy Coding
These two are at opposite ends of the spectrum:
| Type | What It Does | Typical Formats | Best For |
|---|---|---|---|
| ✔ Lossless coding | Compresses and restores data with zero loss | ZIP, PNG, FLAC | Text, databases, anything that needs exact accuracy |
| ✔ Lossy coding | Compresses by discarding less-critical data | JPEG, MP3, H.265 | Images, audio, video where minor quality loss is imperceptible |
| ✗ Lossy with finance/legal data | Results in unacceptable data loss | – | Records, transactions, compliance-sensitive files |
Binary, Text, and Numeric Coding
Everything else is built on top of binary code. Every image, every character, every instruction, ultimately boiled down to a sequence of bits. So for example, ASCII and Unicode are standards for encoding text; they map letters, numbers, and symbols to numeric values that a machine can process. The coding scheme itself is a standard that tells a machine which character maps to which set of bytes. Getting it right is important because without it, the same sequence of bytes might be read as a completely different character. This is how we represent numbers. There are many formats to code numbers, such as Binary-Coded Decimal (BCD).
Data Coding Schemes in the Wild
- Telecommunications – Error coding and interleaving can help preserve signals across long distances and unreliable connections.
- Multimedia – MP4, JPEG, etc. sacrifice file size for visual/audio quality.
- Big Data & databases—Coding allows the scale-out of indexing and compression over distributed infrastructure.
- Cyber Security – Cryptographic coding (e.g., AES) scrambles sensitive data into an unreadable format without a decryption key.
- SMS and Mobile Messaging – This is the one most people never hear about, and it deserves its own section.
Data Coding Scheme Behind Every SMS You Send
The SMS protocol itself includes a literal field called the TP-Data-Coding-Scheme (TP-DCS), a single byte in each SMS PDU (Protocol Data Unit) that tells the receiving handset or network exactly how to decode the message body. This field is also used to determine the character alphabet a text message is using. It is defined in 3GPP 23.040 and 3GPP 23.038.
Here, three coding options are usually relevant:
| Coding Scheme | Bits/Character | Max Characters (Single Segment) | Use Case |
|---|---|---|---|
| ✔ GSM 7-bit default alphabet | 7 bits | 160 | Standard English + common Western European characters |
| ✔ UCS-2 (Unicode) | 16 bits | 70 | Non-Latin scripts—Arabic, Hindi, Chinese, emojis |
| ✔ 8-bit binary | 8 bits | 140 | Non-text data (ringtones, provisioning, OTA settings) |
This is precisely why a message containing a single emoji or non-Latin character silently lowers your character count from 160 to 70—the entire message switches to UCS-2 coding as soon as one character is outside the GSM 7-bit alphabet. For languages like Chinese, Korean, or Japanese, which are not part of the GSM 7-bit alphabet, the transfer has to be done with the 16-bit UCS-2 character encoding. This is also true for something as little as a curly quote or an emoji that happens to sneak into an otherwise plain English message.
Why It’s Important If You’re Using Salesforce to Send SMS
For teams running SMS campaigns natively inside Salesforce, understanding data coding schemes is not an academic exercise; it directly impacts cost and deliverability:
- When special characters or emojis enter your copy, what appears as “one message” in your CRM can silently be divided into multiple billed segments.
- Templates created with smart quotes, em-dashes, or other non-standard punctuation (often when copy is pasted from Word or Google Docs) can cause an unnecessary encoding switch.
- Armed with this knowledge, marketing and RevOps teams can write their SMS copy to stay within the GSM 7-bit alphabet, which limits the characters to 160 characters and prevents any surprise multi-segment charges.
This is exactly the kind of encoding-level reliability that native-to-Salesforce platforms, such as MessageBlink, are designed to handle automatically — so your team can focus on the message, not the byte count.
