yurelle
commented
1 year ago I was not aware that other Base45 encoders were a thing; so, I don't know what their encoding standard is. This encoder was written specifically to cater to an internal Base45 implementation that I stumbled upon inside the ZXING QR Code library source code, here: https://github.com/zxing/zxing/blob/master/core/src/main/java/com/google/zxing/qrcode/encoder/Encoder.java
On line 43, the ALPHANUMERIC_TABLE int array defines the lookup table for conversion between binary & letters. The comment claims that it was copied from "table 5" of some official standard document called "JISX0510:2004" on page 19.
On line 257 in the "chooseMode(...)" function, it detects if the string content which has been passed into the QR Code matches the bounds of the ALPHANUMERIC_TABLE. And if so, then the function "appendAlphanumericBytes(...)" on line 576, compresses 2 of these alphanum digits into 11-bits.
Again, my library was designed specifically to convert binary data into something that this internal ZXING code would recognize and accept, and that would be consistent with itself, encoding & decoding. I called it Base45, just because it was 45 possible values. I had never seen a base45 implementation before, so I didn't know I was clobbering the SEO. Maybe I should have called it something more specific.
When you say that my encoded string doesn't match the python/etc. implementation, do you mean that mine uses different characters than they do, to represent the 45 possible values? Or that we're both using the same letters/symbols, but in a different order (i.e. when I encode some value, like 34, they decode it as 16 or something)? Or am I getting the byte order wrong?
Actually, now that I think about it, it might be the byte order. I didn't think about the byte order when I was writing this, since I was doing both the encoding & decoding, so I could just be consistent, and I didn't know that other implementations existed, so I wasn't trying to be compatible with anything. But, I'm pushing the bytes into the long buffer sort of like a First-In-Last-Out stack. So, I guess it would jumble the bytes, if another implementation is expecting the bytes to be in the same order. It works if you use my code to do both encoding & decoding, but I guess you're saying that if you use my code to encode something, python decodes it into gibberish?
I'm also just settling up the leftover slack at the end of each long buffer into its own byte, rather than trying to keep the data flowing continuously. If other implementations do something more elegant, then I would imagine that that would also cause problems.
hvico
The produced string doesn't seem to be compatible with other base45 decoders out there (for instance the Python base45 lib, or the base45 online decoders out there). Checking python's base45 implementation, it seems the library checks that the len(input_buffer) % 3 == 1 and in my case that is not true for some encodings produced by this JAVA encoder. Besides that it doesn't seem to be compatible at all. Is this really base45 or some custom near-base45 implementation? Thanks