-
-
Notifications
You must be signed in to change notification settings - Fork 319
-
Hello.
I'm using php-qrcode (successfully) in decoding qr-codes contained in qrbills in Switzerland. Though decoding a new code php-qrcode is not able to decode. It breaks with the following error message : "ECI designator followed by invalid mode: "0010"
The QR-Code is recognized by other scanners without problems or error messages... are there any ideas? (I am not sharing the QR-Code as it contains confidential information..). Other QR-Codes from the same company do not work either (it's a major insurance company in Switherland). But as already mentioned, there is no issue with other QR-Readers.
Any help in getting php-qrcode to successfully decode also in this case would be greatly appreciated.
Thanks a lot.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 4 comments 5 replies
-
Hey, the decoder will throw if it detects a sequence that is other than "8-bit byte" following an ECI mode marker (as per specification). Mode 0010 means that the following sequence is an alphanumeric segment, which does not require to be preceded by an ECI designator. I guess just silently discarding the invalid marker is what other decoders do.
If you feel like a little bit of experimenting and helping me to improve this, you can try the following:
Open the Decoder.php and change this block
php-qrcode/src/Decoder/Decoder.php
Lines 134 to 136 in 90eb116
to
elseif($datamode === Mode::ECI){ // check if the ECI designator is followed by a byte segment, skip otherwise if((clone $this->bitBuffer)->read(4) !== Mode::BYTE){ continue; } $result .= ECI::decodeSegment($this->bitBuffer, $versionNumber); }
and see if your QR Codes are being decoded as expected.
You could also send me a sample of a non-working QR Code to my email address that's in almost every file header, so that I can examine what's going wrong.
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
Hmm, this exception is thrown inside the called data mode interface, e.g. here:
php-qrcode/src/Data/AlphaNum.php
Line 118 in 90eb116
You could change the line where the exception is thrown to simply return ''; so that it continues without doing anything. But also I think the QR Codes are not properly encoded if there's not enough data available after an ECI marker. The supposed ECI marker (0111) should be a terminator (0000) instead.
Beta Was this translation helpful? Give feedback.
All reactions
-
Oh I just realized you sent me an email! I'll check out the attached QR Code and see if there's a somewhat elegant solution.
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
Ok, for now I can assure you that the data has been read correctly - the issue lies within the encoded data or the decoder, which might take me a while to examine and debug.
Beta Was this translation helpful? Give feedback.
All reactions
-
So it's certainly an encoding issue - the data contains numeric and alphanumeric segments (by definition ASCII) that are preceded by an ECI marker that contains character set information for UTF-8 (???). Either way, I let the ECI decoder now consider this possibility and your QR Codes should decode as expected now.
The fix is currently in the main branch (upcoming v6) and you can check it out by using dev-main#1d8b7fd8ba932a232ba6177a91283707f18e870f in your composer.json.
Beta Was this translation helpful? Give feedback.
All reactions
-
Beta Was this translation helpful? Give feedback.
All reactions
-
Hey, I'm glad the fix worked for you!
Should I inform the company that is sending this kind of qr codes which does not adhere to standards?
Ok, so I checked the standards document that's available to me (a rather old one) and the documentation on ECI couldn't be more confusing:
8.4.1 Extended Channel Interpretation (ECI) Mode
This mode, used for encoding data subject to alternative interpretations of byte values (e.g. alternative character sets) in accordance with the AIM ECI specification which defines the pre-processing of this type of data, is invoked by the use of Mode Indicator 0111. There is no need to invoke the default Extended Channel Interpretation for QR Code (ECI 000020, corresponding to the JIS8/Shift JIS character sets) specifically at the beginning of any symbol.
The Extended Channel Interpretation can only be used with readers enabled to transmit the Symbology Identifier. Readers that cannot transmit the Symbology Identifier cannot transmit the data from any symbol containing an ECI.
Input ECI data shall be handled by the encoding system as a series of 8-bit byte values.
Data in an ECI sequence may be encoded in whatever mode or modes permit the most efficient encoding of the byte values of the data, irrespective of their significance. For example, a sequence of bytes in the range 30 HEX to 39HEX could be encoded in Numeric Mode (see 8.4.2) as though it were a sequence of digits 0 – 9 even though it might not actually represent numeric data. In order to determine the value of the Character Count Indicator, the number of bytes (or, in Kanji Mode, of byte pairs) shall be used.
So first it says ECI data should be handled as 8-bit bytes (because naturally binary/byte mode is the only mode that can handle encoded character set data).
The last paragraph adds confusion by saying that random encoding modes can be used within an ECI segment??? So I guess it's fine then even though it makes no sense.
Beta Was this translation helpful? Give feedback.