ECI designator followed by invalid mode: "0010"

[m-duerig]

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.

[codemasher]

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

	elseif($datamode === Mode::ECI){
	$result .= ECI::decodeSegment($this->bitBuffer, $versionNumber);
	}

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.

[m-duerig]

Hello Thanks a lot for the quick answer and the workaround code I just tested with the same QR-Code using your new code, commenting out the old one. It still doesn't work, I get now the following error message: "not enough bits available" if you want me to try another code, I would like to help Thanks a lot in advance Markus o Am Sa., 16. Nov. 2024 um 14:05 Uhr schrieb smiley ***@***.***

…

: 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 https://github.com/chillerlan/php-qrcode/blob/90eb116a12e25a213a9f7687045dc83ea624d54d/src/Decoder/Decoder.php#L134-L136 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. — Reply to this email directly, view it on GitHub <#289 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APAYURC77GH5KFKP2UIQQED2A47JNAVCNFSM6AAAAABR4YNHVSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRXG42DCOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[codemasher]

Hmm, this exception is thrown inside the called data mode interface, e.g. here:

php-qrcode/src/Data/AlphaNum.php

Line 118 in 90eb116

throw new QRCodeDataException('not enough bits available'); // @codeCoverageIgnore

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.

[codemasher]

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.

[m-duerig]

I still get the exception : not enough bits available (both patches applied) Am Sa., 16. Nov. 2024 um 16:54 Uhr schrieb smiley ***@***.***

…

: Hmm, this exception is thrown inside the called data mode interface, e.g. here: https://github.com/chillerlan/php-qrcode/blob/90eb116a12e25a213a9f7687045dc83ea624d54d/src/Data/AlphaNum.php#L118 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. — Reply to this email directly, view it on GitHub <#289 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APAYURDLJBK5VFONXDGFYPT2A5TE7AVCNFSM6AAAAABR4YNHVSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRXHAZTKMA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[codemasher]

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.

[codemasher]

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.

[m-duerig]

Hello thanks a lot for the fix - I just copied the code to ECI.php - and this is now working perfectly. Should I inform the company that is sending this kind of qr codes which does not adhere to standards? Thanks a lot and have a great day Markus Am Sa., 16. Nov. 2024 um 19:36 Uhr schrieb smiley ***@***.***

…

: 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 <1d8b7fd> is currently in the main branch (upcoming v6) and you can check it out by using dev-main#1d8b7fd8ba932a232ba6177a91283707f18e870f in your composer.json. — Reply to this email directly, view it on GitHub <#289 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APAYURCNOXUE4F2P5W4WDNT2A6GCPAVCNFSM6AAAAABR4YNHVSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRXHEZTCNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[codemasher]

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.