It's hard to use our own character set tables. How about making encode and decode modules public?

[magiclen]

In some cases, we need to use a non-standard character set, but the CharacterSet enum only provides Standard, UrlSafe, and Crypt crypt(3). The function encode_to_slice in mod encode and the function decode_chunk in mod decode can be used for encoding and decoding with our own charset tables. However, they are not public outside the crate. How about making encode and decode modules public?

Or just add a new trait like

pub trait CharacterSetTrait {
     fn encode_table(&self) -> &'static [u8; 64];
     fn decode_table(&self) -> &'static [u8; 256];
}

And make the INVALID_VALUE constant public so that we can implement the trait for our structures to use our own charset tables.

[marshallpierce]

That seems reasonable. I think the trait idea is attractive. It provides a place to clearly document the expected contents of the tables.

[ggriffiniii]

Hi, I just stumbled upon this issue when opening #89 and noticed that this is somewhat related to my design discussion. I have a prototype change that would allow custom alphabets to be used. In my change you would do something like:

let alphabet = b"~]0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
let config = base64::CustomAlphabetBuilder::new(alphabet.iter().cloned()).with_padding(b'+').build().unwrap();

encode_config(bytes, &config);
decode_config(bytes, &config);

Would that meet your needs? Note that I'm not a maintainer of this library so the decision is up to the maintainers. I'm just curious if we may be able to kill two birds with one stone.

[ElectronicRU]

Any updates on this? I stumbled upon the need to support bcrypt alphabet, and ended up just writing my own base64 implementation which I would be much happier nuking if this crate supports custom alphabets.

[marshallpierce]

I've been super busy (I'm teaching a course at a local university) so I have no hobby time until thatt's over, and then my sizable to-do list is ground down... I do intend to implement this, but it won't be immediately. :(

[ggriffiniii]

@ElectronicRU: In case you really need this support one option is to use my proposed PR #91. It supports a custom alphabet and has other performance improvements as well. I can understand not wanting to run unmerged changes, just throwing it out there as a possibility in case you prefer that over your custom base64 impl.

[ggriffiniii]

A followup to my last comment here. I implemented an alternative base64 crate called radix64 that includes support for custom alphabets. You can find it on docs.rs/radix64

[Fishrock123]

Also need this. I don't care all that much what the api shape is. (To be clear, I'm using radix64 instead...)

[ggriffiniii]

shameless plug: https://docs.rs/radix64/0.6.2/radix64/struct.CustomConfig.html

[marshallpierce]

That is pretty shameless. :P I haven't forgotten. Some day... or PRs welcome that hopefully aren't as overwhelming as #91. :)

[Keats]

@marshallpierce would you accept a PR to add a bcrypt config?

[marshallpierce]

sure!

[fraillt]

Hello,
Are there any plans to make encode/decode tables public?

[marshallpierce]

I don't think so -- it's an implementation detail I'd like to move away from. You could always snag the code that generates them if you want to make your own table or replicate one of the existing ones, though.

[marshallpierce]

Fixed in #157.