marshallpierce
`=` character in custom alphabet
I was wondering if a PR would be accepted that changes the Alphabet::new function, or adds a new one, that doesn't have the check that prevents an Alphabet being created if it contains the = character. This is because I have an alphabet like this:
4QTRhE+Hiz0Nme6DsnuAFCP8WaojxdVOZpKL53r2=BIkqSUcbYJG91tvX7lywMgf
I have read the README, and I understand this is obviously non-standard, but currently there is no way to create an alphabet containing the = character if it's not used for padding.
My condolences for the awful universe you are inhabiting. :(
I think the least awful way to handle this abomination would be to get rid of the PAD_BYTE const and instead have each Alphabet specify the relevant padding byte. That will require plumbing the pad byte through a number of places, but it would be easy enough logic to follow, and would still allow the alphabet to check that the tokens don't include the associated pad byte.
In the meantime for a quick but regrettable fix, you could apply some judicious replace(). I also suggest revoking commit privileges for whoever came up with that base64 alphabet.
I also need a feature that allows me to change the padding byte to - within my custom alphabet. For now the replace will work for me since '=' does not appear in my alphabet, but it's a bit unfortunate that the alphabet is configurable but the padding byte is not.
I would suggest dropping the Alphabet type and instead putting that together with the padding settings directly into the GeneralPurpose engine type. That would allow that you don't have to specify a padding byte at all if you don't need one, which is probably the OPs use case.
In my case I'm actually implementing the encoding for some kind of standard which seems to be called RFC 822 and is used in Musicbrainz DiscID calculation: https://github.com/metabrainz/libdiscid/blob/master/src/base64.c
I'm sympathetic to the goal of not needing to specify the padding symbol if it's not used, but I don't see a way to do that without making usage more confusing for the 99.99% of users that don't need this feature. I'm open to ideas, though. Anyway, give the mp/custom-padding branch a try and LMK if it works for you.
Haven't tested this out yet, but took a look at mp/custom-padding and looks like it would be perfect for my use case. Any chance this could be merged into master, or would that complicate the process for regular users?
I don't think merging would achieve anything for the purposes of gathering feedback -- you can specify a dependency on a branch or a commit hash: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories