Interactive examples

The worked-input buttons show several short cases; the text box also accepts any input. The tabs show three compression ideas for the current bytes. These examples use UTF-8 bytes, just like the Rust codecs. The implementations here are simplified; their bit counts do not include an archive header or model cost.

Change the inputAAAABBCD

8 bytes shown · 64 raw bits

Worked inputs

A appears four times, so this toy tree can give it a shorter code. The displayed bit total excludes a header and tree description.

Give common bytes shorter codes

A Huffman tree for just these input bytes yields 14 data bits, versus 64 raw bits. A real archive also has a header and a way to reproduce the model.

Byte	Count	Code	Data bits
"A" (0x41)	4	0	4
"B" (0x42)	2	10	4
"C" (0x43)	1	110	3
"D" (0x44)	1	111	3

The repository’s Huffman codec starts with all 256 byte counts at one and adapts across blocks. This toy tree uses only the displayed input.

Worked inputs

• With AAAABBCD, A occurs four times, so the toy Huffman tree gives it a short code. The prefix-code chapter shows the tree construction.
• With abcabcabc, the first abc is emitted as literals; later bytes can be represented by a backward match. The LZ77 chapter explains the copy rule.
• With ABABABAB, the last byte is B, and every earlier B with a following byte was followed by A. The next-byte view therefore favors A; byte PPM adds escape and fallback behavior missing from this toy view.
• With ééé, each é occupies two UTF-8 bytes, so the display shows six bytes for three visible letters. Bytes and bits explains the distinction.

From toy to source

These examples show one part of an algorithm at a time. The Rust implementation also has to write a stable archive format, handle empty input, agree exactly with the decoder about updates, and keep its counts within finite integer limits. Follow one archive to see those additional responsibilities.