Representation: Bits, Symbols, and Meaning

By the end of this lesson, you will be able to...

• Separate a value, a symbol, its encoded bytes, and the interpretation that gives those bytes a role.

• Trace how the text café becomes UTF-8 bytes and becomes text again.

• Recognize when an encoding or data-type mismatch can change, corrupt, or erase meaning.

Idea in one sentence: Bits do not arrive with labels, so a computer can recover the intended value only when it uses the right representation and interpretation.

Core Insight

In the previous lesson, we asked a computer to count vowels in a word. The procedure was clear enough for the word CODE. Then we reached café and had to decide whether é belongs to the vowel set.

Now imagine a different failure. A file contains the visible word café, but an application opens it as caf�, rejects it as invalid text, or displays a strange pair of characters. The procedure for counting vowels may be fine. The problem is earlier: the application and the file disagree about what the stored bytes stand for.

A human sees one word. A computer sees physical states organized into bits and bytes. To get from those states to a word, it needs an agreed mapping.

That mapping is a representation. It is not a cosmetic detail. It determines what a program can preserve, compare, transmit, and understand.

The key trade-off is this: representations make information storable and computable, but each representation chooses what to preserve, what to omit, and what agreement every reader must share.

The Confusion This Concept Solves

It is tempting to say that a file “contains letters.” That is close enough for everyday work, but it hides an important chain.

For text, the chain is:

intended text
-> characters and symbols
-> encoding rule
-> bytes in storage or transit
-> decoding rule
-> displayed text

Each arrow needs an agreement. If the encoding rule changes in the middle, the same bytes can lead to a different result.

The phrase “same bytes can mean different things” is sometimes stated too loosely. Bytes are not magical shape-shifters. A program uses bytes according to a format, type, encoding, or protocol that tells it how to group and interpret them. Without that rule, the bytes are only patterns.

From a Value to Bytes

Let us name the layers in the café example.

Value

The value is the piece of information we want to preserve: the text of a café name. At this stage, we care about the word, not about a particular file format.

Symbols

We write that value with four characters: c, a, f, and é.

A character is a symbol in a writing system. It is not yet a byte. The same character can be encoded in more than one way, just as the same number can be written in decimal, binary, or hexadecimal.

Encoding

An encoding is a rule for converting symbols into bytes and back again. UTF-8 is a widely used text encoding. It represents common ASCII characters with one byte and many other characters with two or more bytes.

Bytes

A byte is a group of eight bits. Bits are two-state values, often written 0 and 1. Storage hardware preserves physical states that we treat as bits; software groups them into bytes because that grouping is useful.

For the lowercase text café, UTF-8 uses these hexadecimal byte values:

Hexadecimal is only a convenient notation for bytes. The byte 63 in this table is not the characters 6 and 3; it is one byte whose value is written in base sixteen.

Decoding and interpretation

Decoding applies the same encoding rule in reverse. A UTF-8 decoder reads C3 A9 together and returns the character é.

Interpretation asks what the resulting value is for. The string café might be a display label, a search term, a password, or a database key. The characters can be identical while the system rules around them differ.

Plain meaning:

A representation is a chosen form that lets a system store, move, or process a value.

In this scenario:

UTF-8 represents the character é with the two bytes C3 A9, and a UTF-8 decoder turns those two bytes back into é.

Technical name:

The conversion from characters to bytes is encoding. The reverse conversion is decoding. The agreed set of characters and their identifiers is part of Unicode; UTF-8 is one encoding for Unicode characters.

A Worked Trace: Why café Breaks

Suppose a small café directory saves each name as UTF-8 text. The writer stores the following bytes:

value:        café
UTF-8 bytes:  63 61 66 C3 A9

Now a reader opens the file. A correct UTF-8 decoder works from left to right:

The decoder must know that C3 A9 is one two-byte sequence. If it treats each byte as a separate legacy character, it can produce a garbled result such as café instead of café.

The failure is not that the bytes changed. The writer and reader used different rules for the same byte sequence.

Here is the full path:

intended name café
-> choose UTF-8
-> write 63 61 66 C3 A9
-> read the same bytes
-> decode as UTF-8
-> display café

And the naive failure contrast:

write UTF-8 bytes
-> read with a different character encoding
-> group bytes using the wrong rule
-> display the wrong characters or report invalid text

So far, we have seen that text is not simply “letters in a file.” It is a contract between a writer and a reader. This matters because a procedure can only classify or transform text after the system has recovered the intended symbols correctly.

Representation Is More Than Text

The same separation appears outside character encodings.

Consider the visible digits 007.

• As a number, it has the value seven. The leading zero is not mathematically important.
• As a catalogue identifier, it is a three-character code. The leading zeros are part of the value we must preserve.

If a system stores a book code as the number 7 and later displays it as 7, it has not made a formatting mistake. It chose the wrong representation for the intended value.

Similarly, the bit pattern for a small integer can be interpreted as a temperature, a user identifier, a pixel colour component, or one part of a machine instruction. The surrounding type, schema, or format supplies the rule. A database column, file header, network protocol, and programming-language type are all ways to make that rule explicit.

This does not mean “anything can mean anything.” A useful system narrows the possibilities. It records or agrees on enough context that the next component knows how to decode the data safely.

What This Changes

Before this idea, we might ask only whether a file contains the right data.

After this idea, we ask a more useful set of questions:

• What value are we trying to preserve?
• Which symbols or fields represent that value?
• Which encoding or binary format turns them into bytes?
• Which decoder, type, or schema will the next component use?
• Which details must survive the round trip?

For the vowel counter, this changes the order of reasoning. We first decode bytes into text. Then we decide which characters count as vowels. A good procedure cannot repair meaning that was lost or misread before it received the input.

Trade-offs and Limits

Representations buy us storage, transmission, comparison, and computation. They also impose choices.

• A compact representation can save space, but it may require more work to decode or make errors harder to inspect.
• A rich format can preserve more structure, but it may be larger and require more agreement between systems.
• A strict type or schema can prevent ambiguous use, but it makes changes require coordination and migration.
• A text format is often easy for humans to inspect, but it may be less compact or less precise for some numeric data.

An encoding does not tell us whether the content is true, safe, or appropriate. UTF-8 can preserve the text temperature: 21, but it does not say whether the unit is Celsius, Fahrenheit, or whether the reading is current.

You can see the boundary when a system has bytes but no declared encoding, when a field loses meaningful detail such as leading zeros, or when two components agree on the field name but disagree on its type or unit. Those are representation contracts that have become visible through failure.

Common Confusions

Confusion: A byte is a character

Why it is tempting:

Many English characters are one byte in UTF-8, so the distinction stays hidden in ordinary text.

Better model:

A byte is a unit of stored data. A character is a symbol. UTF-8 sometimes uses one byte for a character and sometimes uses several.

Confusion: Unicode and UTF-8 are the same thing

Why it is tempting:

People often see both terms in the same error message.

Better model:

Unicode defines characters and their identifiers. UTF-8 is one rule for encoding those characters as bytes. Other Unicode encodings exist.

Confusion: Correct decoding gives meaning automatically

Why it is tempting:

Once 007 displays correctly, it feels like the system has understood it.

Better model:

Decoding recovers symbols. Interpretation still decides whether 007 is a number, a product code, a room number, or text that must preserve its leading zeros.

Confusion: Representation errors only affect unusual languages

Why it is tempting:

Encoding discussions often begin with accented characters or emoji.

Better model:

The same problem appears with dates, units, money, identifiers, images, booleans, and every binary protocol. Accented text simply makes the hidden agreement easy to see.

Check Your Understanding

Check: A file contains the UTF-8 bytes 63 61 66 C3 A9. A reader decodes them as UTF-8. What text should the reader produce?

Think first, then reveal.

Answer: café. The final two bytes form one UTF-8 sequence for é; they are not two independent characters.

Check: A book catalogue stores the identifier 007 as the number 7. What information has been lost?

Think first, then reveal.

Answer: The system lost the leading-zero requirement. If 007 is an identifier rather than a quantity, the representation should preserve it as text or as a fixed-width code.

Practice: Define a Representation Contract

A library needs to exchange a book code with another system. The code is always three digits, and 007 is different from 7 because readers use the printed code to find the book.

Write a small representation contract. It should specify:

1. the value being preserved
2. the symbol or field form
3. the encoding
4. the rule used by the receiving system
5. one invalid case

A strong answer could be:

value: a three-character library identifier
field form: exactly three ASCII digits, such as "007"
encoding: UTF-8 text
receiver rule: decode as UTF-8 and reject any value that is not exactly three digits
invalid case: "7" is invalid because it has only one character

This contract is deliberately simple. Its value is not that UTF-8 is always the best storage choice. Its value is that every component can now preserve, validate, and interpret the identifier in the same way.

Resources

• [REFERENCE] The Unicode Standard — Focus: Use the standard's overview to separate characters from their UTF-8, UTF-16, or UTF-32 encodings.
• [BOOK] Structure and Interpretation of Computer Programs — Focus: Read the early discussion of data and abstraction as chosen representations for information.
• [COURSE] CS50x — Focus: Use the early binary and text-encoding material to connect bits, bytes, and characters.

Key Takeaways

• A representation is a chosen form for storing, moving, or processing a value.
• Text requires a chain from characters through an encoding to bytes, then back through decoding.
• The UTF-8 bytes for é are C3 A9; treating them with the wrong decoding rule can corrupt the visible text.
• Decoding recovers symbols, while interpretation decides what role those symbols play in a system.
• Representations make computation possible, but they also require explicit contracts about encoding, type, format, and preserved detail.