erwanvivien / fast_qr

Ultra fast QRCode generation
https://fast-qr.com/
MIT License
197 stars 29 forks source link

Add ability to force mode #55

Closed praveenperera closed 4 months ago

praveenperera commented 4 months ago

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.

erwanvivien commented 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]

praveenperera commented 4 months ago

@erwanvivien during the splitting process the data is encoded using either hex or base32

erwanvivien commented 4 months ago

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...

erwanvivien commented 4 months ago

As long as you trust your input to QRCode::new() this should not be a problem đź‘Ť

praveenperera commented 4 months ago

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?

erwanvivien commented 4 months ago

The main problem was user's input validation, there is not really a problem with that đź‘Ť

erwanvivien commented 4 months ago

cc @praveenperera I deployed fast_qr = "0.12.4"