Closed Alex-Sichkar closed 3 months ago
To answer the part I have an immediate answer for:
If you have barcodes with HRI (Human Readable Interpretation) data encoded in the barcode and you really want to accept it, I suggest checking if the barcode data starts with a (
and if so use the recently added GS1Message.parse_hri()
to interpret the data.
Thanks. HRI is a small problem. For me, the most important thing is the redundant separator character. For now, I'm solving this by catching the ParseError exception and checking for the appropriate message (with regex), then removing the separator. But this is, to say the least, not very effective.
+1 on ignoring the redundant GS character. I think it should be safe to do this by default, but some sort of non-strict opt-in would also be fine.
Thanks for pointing this out, getting me to reread this issue.
I agree that ignoring superfluous separator characters at the end of fixed-length element strings is reasonable to do by default and not a breaking change.
I've released v3.4.0 which ignores redundant separation characters.
Thank you for the project, @jodal
I have encountered some issues with barcodes not always being encoded correctly. Specifically, when an element string with a fixed length ends with a separator character, and when the barcode is encoded as a human-readable interpretation. Perhaps, making the parsing less strict with an optional argument like "strict=False" would be helpful.