Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.perl.modules > #206

Re: Imager::QRCode-ing octet sequences vs. zbarimg(1)

Cross-posted to 3 groups.

Show all headers | View raw

>>>>> Ben Morrow <ben@morrow.me.uk> writes:

[...]

 > There is a Perl decoder based on zbar (Barcode::ZBar), though
 > presumably it would behave the same as zbarimg.

	... Or it may not.  It definitely worths checking out.

[...]

 > So you have a UTF-8 problem somewhere.  (c2 and c3 (or  and Ã)
 > showing up unexpectedly is the giveaway here.)  Looking at the code,
 > I think it's zbar which is converting 8859-1 to UTF-8; one way to
 > test this is to create a QR code containing 17 0xffs at ECC level L;
 > this is the maximum number of characters that will fit into a 21x21
 > QR code, so if the code comes out bigger than that you know there are
 > extra bytes in there somewhere.

	ACK, thanks!  With qw (level L  margin 0  size 2) being added to
	the parameters, the code now gives (also using $ zbarimg --raw):

Blob:     ffffffffffffffffffffffffffffffffff
Image:    42 by 42
Decoded:  c3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bfc3bf0a
scanned 1 barcode symbols from 1 images in 0.05 seconds

	Thus, unless there's some magic in the resulting QR code saying
	that it's an ISO-8859-1-encoded string (I'm not familiar with QR
	encoding, so can't tell if it's a sensible guess), zbarimg(1),
	is indeed to blame, and perhaps the underlying library, too.

 > However, it's not unlikely that other QR code readers will do similar
 > conversions to UTF-8, or other stupid things.  Depending on what
 > you're doing it might be safer to explicitly UTF-8-encode your data
 > (all 8-bit data can be represented in UTF-8) and then decode it on
 > the other end.  Of course, this will make the codes a little larger
 > than they need to be.

	In this case, there'd indeed be some benefit from using the
	smallest-possible image.  OTOH, I do not expect for the problem
	of interoperability to arise anytime soon.

[...]

-- 
FSF associate member #7257

Back to comp.lang.perl.modules | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-13 11:40 +0000
  Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ben Morrow <ben@morrow.me.uk> - 2013-03-13 16:27 +0000
    bytes, English, and prototypes Ivan Shmakov <oneingray@gmail.com> - 2013-03-13 17:28 +0000
    Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-14 20:25 +0000
    Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ivan Shmakov <oneingray@gmail.com> - 2013-03-17 17:57 +0000
      Re: Imager::QRCode-ing octet sequences vs. zbarimg(1) Ben Morrow <ben@morrow.me.uk> - 2013-03-18 23:42 +0000
        [OT] reporting bugs Ivan Shmakov <oneingray@gmail.com> - 2013-03-30 11:02 +0000
          Re: reporting bugs Ben Morrow <ben@morrow.me.uk> - 2013-04-01 22:58 +0100
            Re: reporting bugs Ivan Shmakov <oneingray@gmail.com> - 2013-04-06 13:50 +0000
          configuring CPAN to apply patches (such as #29468, IPv6 in Net::HTTP) Ivan Shmakov <oneingray@gmail.com> - 2013-06-28 19:48 +0000

csiph-web