Submission declined on 10 August 2026 by Sulfurboy (talk). This draft's references do not show that the subject meets Wikipedia's criteria for inclusion. The draft requires multiple published secondary sources that: provide significant coverage: discuss the subject in detail, not just brief mentions or routine announcements; are reliable: from reputable outlets with editorial oversight; are independent: not connected to the subject, such as interviews, press releases, the subject's own website, or sponsored content. Please add references that meet all three of these criteria. If none exist, the subject is not yet suitable for Wikipedia. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by Sulfurboy 17 hours ago. Last edited by Sulfurboy 17 hours ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

UCE-8 (Unicode Compact Encoding) is an experimental variable-width character encoding for Unicode that represents each code point in one, two or three bytes. It was designed to reduce the storage and transmission cost of scripts that UTF-8 encodes in three bytes, principally the writing systems of South Asia, Southeast Asia, East Asia and the Horn of Africa.

Unlike UTF-8, in which the leading byte identifies both the length and the general range of a character, UCE-8 places the identifying information in the final byte of a sequence. The high bit of each byte acts solely as a continuation flag, and the terminating byte doubles as an index into one of 68 character "pages".

UCE-8 assigns byte lengths by script rather than by position in the Unicode code space. The difference from UTF-8 falls entirely on the third tier, which UCE-8 promotes to two bytes and UTF-8 does not:

The saving applies only to the characters the two-byte tier actually holds; the scripts concerned, and how completely each is covered, are listed under Page map below.

The most significant bit of every byte indicates whether another byte follows. A byte with the high bit set ("lead byte") is followed by at least one more byte; a byte with the high bit clear ("trail byte") terminates the character. The encoding is therefore self-terminating and requires no length field.

The capacity of the three-byte tier, 128 × 128 × 68, equals 1,114,112, which is also the total size of the Unicode code space (17 × 65,536).

In a two-byte sequence the trail byte selects a page of 128 characters and the lead byte selects a position, or "slot", within it. This is the reverse of UTF-8, where the leading byte carries the identifying information.

For example, the Devanagari letter na (U+0928) is encoded as the byte pair A8 35:

• A8 = 1 0101000 — high bit set, slot 28 hex
• 35 = 0 0110101 — high bit clear, page index 35 hex

Page 35 hex corresponds to the Unicode block beginning at U+0900, so the sequence resolves to U+0900 + 28 hex = U+0928. Holding the lead byte constant and changing only the trail byte selects the same slot in a different script.

Of the 128 possible trail-byte values, 60 are excluded: the 33 control codes, the space character, and 26 punctuation marks that have structural meaning in common data formats such as JSON, CSV, URLs, file paths and shell syntax. Only six punctuation marks remain usable as trail bytes: !, (, ), ^, _ and ~.

This leaves 68 usable page indices, giving the two-byte tier a capacity of 128 × 68 = 8,704 characters.

The following table lists every trail-byte value. The row gives the high nibble and the column the low nibble; the small character in each cell is the ASCII character that byte represents, and the value beneath it is the page selected. WLD, CHN and KOR mark indexed pages, which hold a curated list rather than an aligned Unicode block.

Devanagari occupies row 3, column 5 — the ASCII digit 5 — which is why text in that script produces byte streams containing that digit at every second position.

The page values in the table above are Unicode block addresses with the final hexadecimal digit removed; page 090 therefore denotes the 128 code points beginning at U+0900. The scripts they correspond to are:

Population figures are approximate and are given for the writing system rather than for any one language. The scripts listed all fall in the range UTF-8 encodes in three bytes.

Pages are of two kinds. Block pages map a 128-code-point-aligned slice of Unicode, so the slot is computed arithmetically. Indexed pages hold a curated list of 128 entries, so the slot requires a table lookup. Chinese and Korean use indexed pages because Unicode orders Han characters by radical and Hangul syllables by jamo composition, neither of which correlates with frequency of use.

UCE-8 is not the first encoding to represent East Asian scripts in two bytes. GB 18030, Shift JIS, EUC-KR and Big5 all predate it and encode their respective scripts in two bytes, but each covers a single language community and they are mutually incompatible. UTF-16 encodes the entire Basic Multilingual Plane in two bytes but requires two bytes for ASCII as well.

Unicode also defines two compression schemes with related goals, the Standard Compression Scheme for Unicode (UTS #6) and BOCU-1 (UTS #12), neither of which is widely deployed.

• Incompatibility. A UCE-8 byte stream is not valid UTF-8, and vice versa, except for pure ASCII, which is identical in both.
• Byte order does not follow code-point order. Because indexed pages are ordered by frequency rather than by code point, sorting encoded bytes does not sort characters, affecting binary search and range queries over raw encoded data.
• Context-dependent bytes. A trail byte cannot be distinguished from a standalone ASCII character by inspection alone; determining which requires examining the preceding byte. UTF-8, by contrast, marks continuation bytes with a reserved 10xxxxxx prefix. The designer describes this as a deliberate trade: reserving such a prefix would reduce the two-byte tier from 8,704 characters to 4,096.
• Substring search. Because trail bytes are ordinary ASCII digits and letters, a naive byte-level substring search can report false positives. These can be eliminated by testing the byte preceding each candidate match, described under Character boundaries below. The test applies only to code that performs the search, so tools that are unaware of the encoding — grep, SQL LIKE, or a general-purpose search index — remain affected.
• Fixed repertoire. The curated character tables cannot be reordered without invalidating previously encoded data.
• Interaction with compression. Much of the size advantage over UTF-8 is reduced when general-purpose compression such as gzip or Brotli is applied, since UTF-8's repeated lead bytes are themselves highly compressible.

A reference implementation in Python, together with the frozen character tables and a browser-based demonstration, is published by the designer under a public repository.^[1]

The 32 indexed pages are backed by three ordered strings, one per category. A character's slot is its position in the string, so the tables are the encoding: reordering them would change the meaning of every byte sequence already written. They are consequently frozen.

Each table fills its pages exactly, 32 × 128 = 4,096 entries with none unused. The complete tables are too long to reproduce here; they appear in full in the reference implementation.^[1]

The encoder tries the block pages first, since their slot is arithmetic, then the three indexed tables, and finally falls back to the three-byte tier. LEAD_BASE is 0x80, the bit that marks a byte as non-terminating, and TAIL_COUNT is 68, the number of usable trail values.

def encode(code_point):
    """Encode a Unicode code point into 1, 2 or 3 bytes."""

    # TIER 1 - plain ASCII passes straight through
    if code_point < 0x80:
        return bytes([code_point])

    # TIER 2a - block pages: an aligned 128-code-point slice of Unicode
    trail = PAGE_TO_TRAIL.get((code_point >> 7) << 3)
    if trail is not None:
        return bytes([LEAD_BASE | (code_point & 0x7F), trail])

    # TIER 2b-d - indexed pages: the slot comes from a curated table
    for table, trails in ((CHINESE_SLOT, CHINESE_TRAILS),
                          (KOREAN_SLOT, KOREAN_TRAILS),
                          (WORLD_SLOT, WORLD_TRAILS)):
        slot = table.get(code_point)
        if slot is not None:
            return bytes([LEAD_BASE | (slot & 0x7F), trails[slot >> 7]])

    # TIER 3 - everything else, spread across the 68 legal terminators
    index = code_point - 0x80
    rest, tail = divmod(index, TAIL_COUNT)

    return bytes([
        LEAD_BASE | (rest >> 7),
        LEAD_BASE | (rest & 0x7F),
        TAIL_BYTES[tail],
    ])

The third tier has no page table left to consult, so it distributes the remaining code points arithmetically: the remainder modulo 68 selects one of the legal terminating bytes and the quotient becomes the two lead bytes. This is why the tier's capacity is exactly 128 × 128 × 68, and why the encoder cannot emit an illegal terminator even in its fallback path.

The decoder reads the high bit of the second byte to choose the tier, then uses the trail byte as the page index.

def decode(data):
    """Decode a 1, 2 or 3 byte sequence back into a Unicode code point."""

    first = data[0]
    if first < 0x80:
        return first

    second = data[1]

    # TIER 2 - the second byte clears the high bit, so it terminates
    if second < 0x80:
        page = TRAIL_TO_PAGE[second]

        if page is WORLD:
            return WORLD_CODE_POINTS[(WORLD_PAGE[second] << 7) | (first & 0x7F)]
        if page is CHINESE:
            return CHINESE_CODE_POINTS[(CHINESE_PAGE[second] << 7) | (first & 0x7F)]
        if page is KOREAN:
            return KOREAN_CODE_POINTS[(KOREAN_PAGE[second] << 7) | (first & 0x7F)]

        return ((page >> 3) << 7) | (first & 0x7F)

    # TIER 3 - the second byte keeps the high bit, so a third follows
    tail = TAIL_INDEX[data[2]]
    rest = ((first & 0x7F) << 7) | (second & 0x7F)

    return 0x80 + rest * TAIL_COUNT + tail

Because a trail byte is indistinguishable from a standalone ASCII character in isolation, a byte-level substring search over a UCE-8 stream can match the interior of a multi-byte character. The effect is pronounced for scripts whose page index happens to be a common ASCII character: Devanagari's page index is 0x35, the digit 5, so Devanagari text contains that byte at every second position. Searching such a stream for the digit 5 returns one match per character in addition to any genuine digit.

The ambiguity is resolved by a single test on the preceding byte. A low byte always terminates a character, so a position begins a character precisely when the byte before it is also low, or when it is the start of the stream:

def is_char_start(data, i):
    """A low byte terminates a character, so position i begins one."""
    return i == 0 or not (data[i - 1] & 0x80)

Only the first byte of a candidate match needs this test. If that byte begins a character and is itself low, it also terminates one, so the following byte begins a character in turn, and the property carries along the whole search term. The same test governs where a stream may be split: a cut is safe unless the byte before it is a lead byte.

• Comparison of Unicode encodings
• Standard Compression Scheme for Unicode
• BOCU-1
• GB 18030
• Variable-width encoding

• UCE-8 repository and interactive demonstration

Category:Unicode Transformation Formats Category:Character encoding Category:Computer-related introductions in 2026