Enum `BitOrder`

pub enum BitOrder

Order in which bits are read from a byte

The base-conversion encoding is always little-endian. This means that the least significant byte is always first. However, we can still choose whether, within a byte, this is the most significant or the least significant bit that is first. If the terminology is confusing, testing on an asymmetrical example should be enough to choose the correct value.

Examples

In the following example, we can see that a base with the MostSignificantFirst bit-order has the most significant bit first in the encoded output. In particular, the output is in the same order as the bits in the byte. The opposite happens with the LeastSignificantFirst bit-order. The least significant bit is first and the output is in the reverse order.

use data_encoding::{BitOrder, Specification};
let mut spec = Specification::new();
spec.symbols.push_str("01");
spec.bit_order = BitOrder::MostSignificantFirst;  // default
let msb = spec.encoding().unwrap();
spec.bit_order = BitOrder::LeastSignificantFirst;
let lsb = spec.encoding().unwrap();
assert_eq!(msb.encode(&[0b01010011]), "01010011");
assert_eq!(lsb.encode(&[0b01010011]), "11001010");

Variants

MostSignificantFirst

Most significant bit first

This is the most common and most intuitive bit-order. In particular, this is the bit-order used by RFC4648 and thus the usual hexadecimal, base64, base32, base64url, and base32hex encodings. This is the default bit-order when specifying a base.

LeastSignificantFirst

Least significant bit first

Examples

DNSCurve base32 uses least significant bit first:

use data_encoding::BASE32_DNSCURVE;
assert_eq!(BASE32_DNSCURVE.encode(&[0x64, 0x88]), "4321");
assert_eq!(BASE32_DNSCURVE.decode(b"4321").unwrap(), vec![0x64, 0x88]);