-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raw and parsed decode compatibility with ZXing #17
Comments
Can you give a specific example of a barcode where the ZXing Java library produces a non-UTF8-compatible raw and/or parsed output, and how you think that barcode should be interpreted?
It would be nice to make it work for as many cases as possible. I'm a bit leery about changing the current/existing behavior (return a Python |
Below is the QR code for the binary packed integer 128: b'\x80'. For the current UTF-8 decoding, i.e. python-zxing/zxing/__init__.py Lines 143 to 144 in 938ce86
it results in: ![]() But removing the UTF-8 decoding, i.e.
results in what I am expecting: I emphasize I am expecting because I'm not sure if the "raw" here is intended to be just the "raw text" or the appropriate portion of "raw bytes" as seen in the https://zxing.org/w/decode output for the same QR code. It seems that the zxing CommandLineRunner is able to return the "raw bytes" when subprocess is using the None encoding as it currently is. I understand if this is not supported because trying to get all three of the "raw text", part of "raw bytes", and "parsed result" from the subprocess (with only options of all bytes or all string with specified encoding) is probably ugly usage of try/catch and attempting to guess whatever decoding/parsing is intended. I am not doing anything special with reading the QR code:
|
The QR code symbology does not provide any mechanism to encode "binary" barcodes. The only well-defined use of it is to encode strings in various character encodings. The default interpretation of the bytes in a QR code (same for PDF417, Aztec code, DataMatrix) is ISO-8859-1; any barcode that intends another character encoding must declare it using ECI codes in order to be interpreted correctly. (See https://stackoverflow.com/questions/27857718/aztec-barcode-vs-qr-code/64585749 for some work I've done in this area.) So:
I guess the "tl;dr" here is that there's no way to use the ZXing command-line runner, in its current form, to decode barcodes whose contents don't map to a sequence of UTF-8 characters. |
Yes, my tests were on Windows. Thanks for the detailed response. I appreciate all the information. |
Good to know, thanks! Interesting that ZXing CLI mangles the output less on Windows. It'd be good to get a stable encoding-proof output method upstream. I lack the bandwidth to work on this now, but would be happy to review an upstream PR if you want to contribute it. :-D |
This is probably related to issue #6 and tangentially related to issue #8 ; it might also just be closed with statement on the use case/spec compatibility of this wrapper with ZXing.
With ZXing, the default outputs of the raw stream are hex bytes while the parsed/text appears to defaul to just Java String (UTF-16). However, the python-zxing wrapper has these two lines in
__init__.py/Barcode
:python-zxing/zxing/__init__.py
Lines 143 to 144 in 938ce86
which force UTF-8 compatibility of the raw and parsed streams. This causes UnicodeDecodeError exceptions with any byte sequences that begin with bytes "larger" than b"\x7f" with which ZXing doesn't appear to have any problems. Just commenting out '.decode()' in each of these lines, I am able to reproduce ZXing results for byte data in both raw and parsed.
My question: is there a reason the '.decode()' or UTF-8 is even necessary for either raw or parsed or is the use case for this wrapper intended to be for UTF-8 compatible QR codes only?
The text was updated successfully, but these errors were encountered: