low order six bits of the final byte, and again is stored in the high order two bits (). The three bytes can be more concisely written in hexadecimal, as . The following table summarizes this conversion, as well as others with different lengths in UTF-8. The colors indicate how bits from the code point are distributed among the UTF-8 bytes. Additional bits added by the UTF-8 encoding process are shown in black. Octal UTF-8's use of six bits per byte to represent the actual characters being encoded means that octal notation (which uses 3-bit groups) can aid in the comparison of UTF-8 sequences with one another and in manual conversion. With octal notation, the arbitrary octal digits, marked with x, y, z or w in the table, will remain unchanged when converting to or from UTF-8. Example: Á = U+00C1 = (in octal) is encoded as in UTF-8 (C3 81 in hex). Example: € = U+20AC = is encoded as in UTF-8 (E2 82 AC in hex). Codepage layout The following table summarizes usage of UTF-8 code units (individual bytes or octets) in a code page format. The upper half is for bytes used only in single-byte codes, so it looks like a normal code page; the lower half is for continuation bytes and leading bytes and is explained further in the legend below. Overlong encodings In principle, it would be possible to inflate the number of bytes in an encoding by padding the code point with leading 0s. To encode the euro sign € from the above example in four bytes instead of three, it could be padded with leading 0s until it was 21 bits long , and encoded as (or in hexadecimal). This is called an overlong encoding. The standard specifies that the correct encoding of a code point uses only the minimum number of bytes required to hold the significant bits of the code point. Longer encodings are called overlong and are not valid UTF-8 representations of the code point. This rule maintains a one-to-one correspondence between code points and their valid encodings, so that there is a unique valid encoding for each code point. This ensures that string comparisons and searches are well-defined. Invalid sequences and error handling Not all sequences of bytes are valid UTF-8. A UTF-8 decoder should be prepared for: invalid bytes an unexpected continuation byte a non-continuation byte before the