This is about whether or not the behavior of bytesECI() is optimal with respect to the handling of the symbology identifier. My claim and mental model was that this property is exactly what a standard (hardware) barcode reader would produce. Looks like I was wrong.

@oehhar wrote in another discussion:

Lets look to two examples:

The first code is a system login code with non ISO-8859-1 characters, e.g. containing an ECI:

The code contains an ECI 2 for ISO-Latin-2 and the data "1HJ" then a byte with decimal value 234 then "drek".
The byte with decimal 234 in ISO8859-2 is unicode codepoint x0119 "ę"
The decode result is as follows. Remark that byte 234 is shown by its Unicode representation "ê".

• text 1HJędrek
• format DataMatrix
• bytes 1HJêdrek
• bytesECI ]d4\0000041HJêdrek
• content Text
• symbologyIdentifier ]d1
• hasECI 1

Here, bytesECI is, what a normal scanner would output. The item "text" with the decoded ECI is great (remark the change of "ê" to "ę" due to the ISO-8859-2 decoding).

The output of a standard scanner is exactly what "bytesECI" contains.

Now try a HIBC code without any ECI which only contains printable ASCII:

The decode result is:

• text +E4947611201/$LI
• format DataMatrix
• bytes +E4947611201/$LI
• bytesECI ]d4+E4947611201/$LI
• content Text
• symbologyIdentifier ]d1
• hasECI 0

The output of a standard scanner is what the concatenation of "symbologyIdentifier" and "bytes" contains.

To get the standard output in both cases, I do:

if (hasECI) return bytesECI else return symbologyIdentifier+bytes

Only now did I realize the issue: ]d4 vs. ]d1 in the case where there is actually no eci designator contained in the message. I would like to change the behavior, such that it fits my mental model, namely exactly what Harald wrote in his last line above. I wonder whether a standard conforming reader is actually required to not advertise the (potential) presence of ECI designators if there aren't any?

The other option would be to add a parameter to the bytesECI(mode) function to switch between those two behaviors. But I'd only do that with a proven use case for it.