Export the encoding tables

[P-E-Meunier]

I'd like to reuse the encoding tables for specialised uses, like fixed-length encodings.
It would be great if tables::XX_ENCODE were public.

[marshallpierce]

Hmm... those are pretty tightly coupled to the current implementation, and we might well want to change those radically as the algorithms change (e.g. maybe a constant time implementation that doesn't need tables at all? Or perhaps a different structure that is more amenable to SIMD?).

I think perhaps it would be a better route to simply take the [make_tables](https://github.com/alicemaz/rust-base64/blob/master/examples/make_tables.rs) script and use it as you see fit to generate your own tables.

[marshallpierce]

Closing due to inactivity.

[cehteh]

Even if the implementation changes it would be nice to have the encode tables around and exported.

Rationale:
I am creating a directory hierarchy with the first level being 2 chars from base64 (similar to what git does in .git/objects)

const URL_SAFE_ENCODE: &[u8; 64] =
    &*b"ABCDEFGHIJLKMNOPQRSTUVWXYZabcdefghijlkmnopqrstuvwxyz0123456789-_";
for a in URL_SAFE_ENCODE.iter() {
    for b in URL_SAFE_ENCODE.iter() {
        objectstore_dir.push(OsStr::from_bytes(&[*a, *b]));
        create_dir_all(&objectstore_dir)?;
        objectstore_dir.pop();
    }
}

This now means that I have to the encoding tables in 2 places, once from base64 and once in my own code. Would be cleaner when the is only one place to get the tables from (even if the encoder gets implemented differently, access to the underlying alphabet should be available). Maybe instead tables as raw just expose an API that gives an iterator back.

Maybe consider reopening this ticket and export the tables in future versions, thanks.

[marshallpierce]

Thanks for the use case description, that helps. This should be doable as part of #157.