Encoding row bytes instead of string

Dec 18, 2012 at 9:48 AM

We need to store non-character data in QR-code for internal use. Possible few kB.

Is it possible to make QrCode.NET version which will accept row byte[] as input but not only a string? Or does this not supported by QR-Code standard (I'm newbie about QR-codes)?

In source codes EncodingName and Gma.QrCodeNet.Encoding.DataEncodation.Mode are used quite often so I'm afraid to make errors during modification...

Coordinator
Dec 19, 2012 at 5:31 AM

In short. QrCode does not support byte[] input. As far as according to ISO. It is totally char based.

Even though we do convert char to byte array according to char table, but if you check any char table, most them contain non solve able special char. Decoder will always assume income byte as part of char table, and turn it into question mark if non solve able. 

If you have total control of decoder, then its possible. Grab byte[] before decoder turn into char. That means you have to have a QrCode decoder that's under your demand. That's not easy. Especially for paid solution. If you want to do that, you can. Put some time on ZXing's decoder, and break it down. Grab byte array before char decode. 

Same at encode side, ignore char encode, just put in byte array. That's what I want to do at later stage, I don't have time set up yet as been busy recently. For this project to include decoder will take longer than optimize current encoder. 

If you can get decoder going, I can help you with encoder.

QrCode specification is under our home page. You can download and give it a quick read for DataEncodation.

Dec 19, 2012 at 8:14 AM

Thanks for quick reply.

As Decoder we use MS POS for .NET library with real 2D-scanner. POS for .NET "produce" byte[]. Does it check about readable range - don't know exactly but on first look - no.

So would you recommend to modify your library with ignoring of Encoding etc. to encode row bytes? I see place in sources where byte[] is generated by string but later after that place Encoding and Mode still are used... So i afraid that ignoring of it may cause problems in correct Matrix generation...

Coordinator
Dec 20, 2012 at 5:03 AM

If you are not in hurry. I might be able to take look at this weekend. 

Output byte array sounds good, but it's also dangerous. If you have time, take look at ISO's documentation about what stored inside main data.

From what I remember, head of data will be data encodation's information, size of QrCode, and that header's length is determined by Size. Then it will have fill out data, after all of that, you have a huge block of error correction data. If you don't have any knowledge towards that, you will fail on extracting correct data.

Unless, MS POS did that for you, extract correct byte array from data and pass to you before decode through char table. The data you want is right before char table decode. This is really important. Else you will have to filter out those bits or bytes to find out real data. A lot of them are dynamic, its not fixed position.  

Dec 20, 2012 at 7:53 AM

I'm not in harry.

Currently we wrap bytes in string and all work. It would be good if you will look at this but its ok if you will do it in new year: I think you have another tasks just before Christmass ;)

About POS - it give decoded bytes (as we encode in QRCode.NET) plus 3 fixed bytes (don't know what is it - just ignoring now). I'm not sure: are this bytes result of char table decoding or not :( If it is chars decoding result then why byte[] but not string? I will take more deep look in it and in ISO standard.

In any cases thanks for great library.

Coordinator
Dec 21, 2012 at 6:15 AM

3 fixed bytes sounds definitely like the header that indicate which data encodation used. If you could post that 3 fixed bytes here as bit, like 011011 etc. I can probably figure out what it is. 

What do you mean by wrap bytes in string?

 

Oh well. Was going to give this project some love during holiday anyway. Left it in wild for more than half year. Hope I still remember what I did last year. XD

Coordinator
Jan 5, 2013 at 10:58 PM

Just commit a change set for byte array encode. 

Let me know if your decode tool can proper extract that byte array. 

Jan 16, 2013 at 11:42 AM

Just have tested with few readers: byte array encoding work in wrong way.

Code from your samples can't be decoded by our scanners. And our own code was decoded as only first byte from array.

Jan 16, 2013 at 11:58 AM

Seems in DataEncode.Encode(IEnumerable<byte> content, ErrorCorrectionLevel eclevel) next string cause problems:

            BitList encodeContent = new BitList(content);

this BitList constructor seems work in incorrect way: length of bit list set to length of byte array.

I'm not fully anderstand what should be there instead... :( So can't correct myself.

Jan 16, 2013 at 12:16 PM

To get expected (for us) behaviour we have changed this string to next one:

            BitList encodeContent = EightBitByteEncoder.GetDataBitsByByteArray(content.ToArray(), QRCodeConstantVariable.DefaultEncoding);

Coordinator
Jan 16, 2013 at 4:36 PM

Pain to work on something that you don't know what's inside. Just like a black box with full of mysteries. 

 

Could you just decode a normal QrCode, and let me know your input string for that code. Also after decode what byte array you got. That will be easier to figure out. 

 

Also for that normal QrCode, use our encoder to encode, so at least I know how to reproduce it again. 

 

Also you don't have to test with any reader, because it will never work. Only reader that can output byte array before transfer to normal char can decode it. If your POV decoder is give you byte array after transfer to normal char then you better give up. That means that POV doesn't support byte array at ALL. It just doing dumb translation at end of normal decode. Not give you proper byte array in the middle of process. 

 

The only way to get byte array is cut off normal decode line and grab information from middle.