search

dmtx / libdmtx

libdmtx Library
Other
300 stars 137 forks source link

EDIFACT does not mask special character '31' #9

Closed mungewell closed 6 years ago

mungewell commented 6 years ago

If the user includes the '31' (unlatch to ASCCII) character in the input, EDIFACT barcode is corrupted. It should unlatch to ASCII first and then encode character in a different scheme, or at least throw an error.

$ echo -en 'OH\037CRAP' | dmtxwrite -o test.png -e e ; dmtxread test.png
OHG
$ echo -en 'OH\037CRAP' | dmtxwrite -o test.png -e e ; dmtxread test.png -c
d:240
d:060
d:135
d:195
d:072
d:020
d:031
d:129
...
mungewell commented 6 years ago

commit 96a49807006c654959ae18315e161496c27cce04 breaks GS-1/FNC1 encoding.

$ echo -n '+0010030378123456789017130700103033262+3000017' | dmtxwrite -e e -o test.png -G 43
dmtxwrite: Unable to encode message (possibly too large for requested size)

We need to (internally) be able to send '31', however when a user includes it in the barcode text we need to escape back to ASCII to encode it. This could be done with a check for 'non-EDIFACT' characters somewhere around here: https://github.com/dmtx/libdmtx/blob/master/dmtxencodeedifact.c#L28

msva commented 6 years ago

echo -n '+0010030378123456789017130700103033262+3000017' | dmtxwrite -e e -o test.png -G 43

Well, 68794ea should fix it (as far as I tested). Can you confirm it (so I can tag v0.7.6 on that commit), please?

mungewell commented 6 years ago

2nd patch was putting FNC1 when not needed. This should fix it. https://github.com/dmtx/libdmtx/pull/11

'We' probably need to figure out whether specify the encoding means only that encoding, or whether it is more a hint. If the user supplies a character which can not be encoded in specified encoding what should we do...?