From text identities to bytes
Computers store and transmit numerical values, while readers interpret text. Encoding applies agreed rules to represent that text; decoding applies the corresponding rules in reverse. Unicode code points are commonly written as U+ followed by hexadecimal digits. A code point is a numbered position in a code space, not a picture of a letter.
A character repertoire, its code-point assignments, and an encoding form are related but distinct. Unicode also supplies properties and rules needed for text processing. Describing a file merely as “Unicode” does not uniquely specify its bytes: a reader still needs to know whether the representation is UTF-8, UTF-16, or another applicable form or scheme.
An encoding and decoding example
UTF-8 represents a Unicode scalar value using one to four bytes and retains the original single-byte values of the ASCII range. Surrogate code points are not directly encoded as UTF-8 characters. Variable length means that byte count is not code-point count and that an arbitrary byte boundary is not necessarily a safe place to split text.
For example, the character 日 has code point U+65E5, represented in UTF-8 by hexadecimal bytes E6 97 A5. A decoder recognizes the three-byte structure, extracts the payload bits, and reconstructs U+65E5 for further text processing. By contrast, A at U+0041 uses the single byte 41. The character identity, numeric code point, and byte sequence describe different stages of the same representation.
References: [2]
Encoding does not choose a font
A glyph is a visible representation produced on a screen or page. Fonts and rendering systems determine its particular appearance. Unicode identifies abstract characters; it does not prescribe every character's size, stroke design, or style. Changing a font can change the image without changing the underlying text encoding.
A missing-glyph problem and a decoding problem consequently occur at different layers. A correctly decoded character may lack a suitable image in the available font. Incorrect decoding instead interprets the incoming bytes using the wrong rules. Replacing a font cannot generally repair that earlier mistake, and correct decoding does not guarantee that all required glyphs are available.
References: [3]
What counts as one character?
A unit that a reader perceives as one character can contain several code points, such as a base letter followed by a combining mark. A precomposed representation may also exist. Unicode documentation therefore distinguishes byte counts, code-unit counts, code-point counts, and grapheme-cluster counts. Different tasks require different measures.
Text that looks equivalent need not contain identical bytes. Comparison, searching, and identifier handling may require appropriate normalization rather than decoding alone. Separately, decoders must recognize invalid UTF-8 sequences instead of treating arbitrary bytes as valid text. Representation validity, textual equivalence, and visual appearance are related concerns, but none can safely stand in for the others.
Normalization distinguishes canonical from compatibility equivalence. NFC unifies canonical variants while preserving the compatibility distinction between ① and1; NFKC folds the circled digit to1 and removes some other formatting differences. This changes character sequences rather than merely switching UTF-8 to UTF-16. Unicode warns against blindly applying compatibility normalization to arbitrary text because erased distinctions may matter, including in mathematical notation. Searching and faithful preservation can therefore require different policies.