ASCII, Unicode, and UTF-8

Computers store only numbers, yet your screen is full of letters, punctuation, and emoji. The bridge is a character encoding: an agreed-upon table that says which number stands for which character. 'A' might be 65, a space 32, a smiling face some larger number. Text is, underneath, just numbers interpreted through such a table — another vivid case of a bit pattern meaning whatever the agreed rule says it means.

ASCII is the original, tiny table: 128 characters (the English letters, digits, common punctuation, and a few control codes), each fitting in 7 bits, so capital A is 65 (0x41) and 'a' is 97. It works beautifully for English and nothing else — no accented letters, no Chinese, no emoji. UNICODE solves that by giving a unique number, called a CODE POINT, to every character in essentially every writing system: over a million possible code points, written like U+0041 for 'A' or U+4E2D for the character 中. But Unicode only assigns the numbers; it does not by itself say how to store them as bytes. That job belongs to an encoding, and the dominant one is UTF-8. UTF-8 is a variable-length encoding: a code point is stored in one to four bytes (a CODE UNIT here is one byte), where the plain ASCII characters keep their single-byte values unchanged, and larger code points spread across two, three, or four bytes. So 'A' is still one byte 0x41, while 中 takes three bytes.

UTF-8's cleverness is why it won the web: because ASCII characters are byte-for-byte identical, any old ASCII text is already valid UTF-8, and English-heavy data stays compact, while every other language still fits. The crucial caveat for a C programmer is that a 'character' is no longer one byte: a single visible character can span several bytes, so counting bytes is not counting characters, indexing into a UTF-8 string by byte position can split a character in half, and the C char type holds a byte (a code unit), not necessarily a whole character. Treat text as bytes you decode, not as a simple array of letters.