Closed praveenperera closed 4 months ago
Hey, I saw your example on BBQr repo
let data: &[u8] = b"Hello, World!, but much larger";
How does that work with Alpha numeric?
As you see in best_encoding, we only support [0-9] or [A-Z] or [$%*./:+-?.=] or [space]
@erwanvivien during the splitting process the data is encoded using either hex or base32
As long as your encoded string is using AlphaNum the QRCode will be AlphaNum.
https://github.com/erwanvivien/fast_qr/blob/master/src/encode.rs#L41C8-L61
As Number is included in AlphaNum and AlphaNum in Byte
This cannot be asserted because encode::Mode is not public tho...
As long as you trust your input to QRCode::new() this should not be a problem đź‘Ť
Thanks but since I know it’s going to be alphanumeric , wouldn’t adding mode allow you to skip the first loop checking its numeric?
Probably not a big saving, but still is there a reason to not allow the end user to explicitly select the encoding type?
The main problem was user's input validation, there is not really a problem with that đź‘Ť
cc @praveenperera I deployed fast_qr = "0.12.4"
I would like to force using alphanumeric mode, looks like its possible but the ability is disabled?
I'm implementing the BBQr spec which is a spec for splitting up large data into multiple QRs and the spec wants the alphanumeric encoding.