Skip to content
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

Ignore separation characters at end of fixed-length element strings #176

Closed
Alex-Sichkar opened this issue Jan 17, 2023 · 5 comments · Fixed by #304
Closed

Ignore separation characters at end of fixed-length element strings #176

Alex-Sichkar opened this issue Jan 17, 2023 · 5 comments · Fixed by #304
Labels
enhancement New feature or request

Comments

@Alex-Sichkar
Copy link

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.

@jodal
Copy link
Owner

jodal commented Jan 20, 2023

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.

@Alex-Sichkar
Copy link
Author

Alex-Sichkar commented Jan 21, 2023

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.

@jodal jodal added enhancement New feature or request breaking Backwards incompatible change labels Jul 29, 2024
@nnerik
Copy link

nnerik commented Jul 30, 2024

+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.

@jodal
Copy link
Owner

jodal commented Jul 31, 2024

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.

@jodal jodal changed the title Parsing is too strict Ignore separation characters at end of fixed-length element strings Jul 31, 2024
@jodal jodal removed the breaking Backwards incompatible change label Jul 31, 2024
@jodal jodal closed this as completed in #304 Aug 3, 2024
@jodal jodal closed this as completed in 875dded Aug 3, 2024
@jodal
Copy link
Owner

jodal commented Aug 3, 2024

I've released v3.4.0 which ignores redundant separation characters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants