The following table shows how different ranges of Unicode characters are encoded to bytes using seven different types of encoding. Byte Order Marks (BOMs) were not emitted for simplicity. Some notes and observations:

• ASCII encoding can only handle characters in the range U+0000 to U+007F. It simply replaces out-of-range bytes with a question mark (U+003F) and information is lost.
• UTF-7 produces incomprehensible bytes for characters outside the ASCII range, but weirdly enough, the bytes can be decoded back to the original characters without any information loss.
• The last column of UTF-16 encodings show the surrogate pairs used to encode characters outside the Basic Multilingual Plane (BMP).
• The most perfect of the encodings is arguably UTF-32 BE, because every posible characters is clearly represented as a single 32‑bit integer with the bytes in big-endian order (making them easier to read). UTF-32 encoding is rarely used in practice because it takes the most space, but it could be useful for exchanging characters between different exotic computer systems or alien lifeforms.

Characters with code points U+0000 to U+001F are known as the C0 control code set. Those points have no character glyphs associated with them, but if you want represent them in documentation then you can use their corresponding Unicode glyphs shown in the table below. The glyph column will only display correctly if the font your browser is using includes those characters.

Code points U+0080-U+009F are defined as C1 control codes in the ISO standards. They originally had no display glyph, but most of them were 'borrowed' for use in the Windows CP-1252 encoding. The following table shows a mapping from the CP-1252 encoding to the Unicode equivalents. Note that the characters in the CP-1252 column may appear as different characters if your browser is set to use a language other than English. They exactly match the Unicode equivalents in my copy of Chrome set to use the English (Australia) language.