3

I have application where I am using printed qr codes to identify real life objects with their database records.

The database uses GUID's as primary keys (this is non-negotiable as it is an occasionally connected system).

In order to make the qr code as small as possible I am attempting to convert my 32 character hexadecimal GUID to a shorter string that takes advantage of the 36 character alphabet (0-9 and A-Z) available in alphanumeric qr codes.

The whole base conversion is going over my head, so any help is greatly appreciated.

Andy
  • 282
  • 1
  • 4
  • 11

4 Answers4

2

You could store the GUID as a byte array and convert it into Base32.

Also see this related question.

Community
  • 1
  • 1
sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • He wants to make the string shorter. The methods discussed at those links make the string longer. – Oscar Feb 11 '13 at 21:44
  • 2
    @Oscar: You're not required to process the GUID as a string, you can treat is as a byte sequence so it is 16 bytes, then convert it into Base32 and still have less characters than you would have with hex representation. – sharptooth Feb 12 '13 at 06:15
1

I'd convert it to Base64 which is about 20% smaller than Base32. Libraries or sample code to convert to base64 is readily available. The only problem with base64 is obviously that the letter 'a' and 'A' is different according to base64 but not necessarily to your DB, so if you choose Base64 over Base32, then you'll have to check that your DB table collation is setup correctly.

Hannes de Jager
  • 2,903
  • 6
  • 37
  • 57
  • Base64 appears to be a very easy conversion (as Microsoft have put it in the Convert class), unfortunately, I am stuck with the qr code alphabet which only covers the characters 0-9 and A-Z. Thanks – Andy Jan 19 '11 at 22:11
0

The value of a globally unique identifier (GUID) can be represented as a 32-character hexadecimal string, but is usually stored as a 128-bit (16 byte) integer.

I suspect that the smallest possible QR code that can store such 128-bit values is to specify "Binary/byte encoding" (which can store any 8-bit bytes) and store the 16 bytes directly. That encodes with 1 pixel per bit, 8 pixels per byte (plus the standard overhead bits). I'm pretty sure that all other valid QR encodings will use at least 1 pixel per bit and have the same standard overhead. So you're not going to get a smaller QR code with any kind of Base64 or Base45 or Base36 or Base32 conversion.

Most of the QR codes I've ever seen that encode URLs use that same "Binary/byte encoding" in order to support lowercase letters. QR codes that use "Alphanumeric encoding" are less common in my experience -- when used to encode URLs, they decode to all-uppercase URLs (since they can store only the 45 symbols 0–9, A–Z [upper-case only], space, $, %, *, +, -, ., /, :). The "11 bits per 2 characters" is pretty clever in many situations, but it doesn't really help when encoding GUIDs.

Have you seen http://www.younoodle.com/startups/barcode_guid or Wikipedia:spime ?

David Cary
  • 5,250
  • 6
  • 53
  • 66
0

Storing a GUID in a QRcode as a 16 byte integer is the best way to get a small QRcode, if you find this still physically still too large, consider rendering Micro QR codes. [https://www.qrcode.com/en/codes/microqr.html] (QRcodes can't be further compressed, as they are already close to maximum entropy)

Shrimpy
  • 174
  • 3
  • 5