This project is read-only.

QR with Swedish characters

Aug 22, 2012 at 8:17 AM

Trying to use QrCode.Net with Swedish characters such as å ä ö but do not really know how to do this. Is that possible? Someone who can lead me in the right direction?

Coordinator
Aug 22, 2012 at 10:43 AM

It is possible. Either get source code and compile yourselves or grab 0.3 beta. It will detect your language and use proper encode. You don't have to do anything other than normal action that's described under documentation. 

Aug 22, 2012 at 12:46 PM
Edited Aug 22, 2012 at 12:47 PM

Thanks for the reply. I have downloaded version 0.3 and ran Gma.QrCodeNet.Demo.exe and tested with å ä ö but it is not right. I create QR code by another program so my QR reader can handle å ä ö

This is created by QrCode.Net, dont work with å ä ö
http://www.securum.se/download/qr/qr-code_dontwork.PNG


This is created with another program, work with å ä ö
http://www.securum.se/download/qr/qr-code_work.PNG

Any idea?

 

Coordinator
Aug 22, 2012 at 7:52 PM
Edited Aug 22, 2012 at 7:55 PM

I can not decode with my mobile devise but able to with ZXing's online decoder. I have also look into code which it uses standard encoding iso-8859-1. My guess is some of mobile decoder still base on ISO 18004 2000. Where shift jis treated as default encoder. Where in ISO 18004 2006, iso-8859-1 is present as default. I can give it a quick fix later. Which you will have to use latest source code once I upload my changes. 

 

Here is link to ZXing decode result. http://goo.gl/whpiy

Where you can test at : http://zxing.org/w/decode.jspx

 

Thanks for report

 

Edit: Did more test, other iso-8859-1 works fine but special Europe character won't work.  Guess its related to decoder's smart detection. Shrug. Will see how it goes when I change some of code around. 

Coordinator
Aug 23, 2012 at 7:44 AM

Ok, Its pretty clear now. It's not our encoder's problem, it's decoder's issue. They are using ISO 18004:2000 instead of ISO 18004:2006. 

 

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

http://en.wikipedia.org/wiki/Shift_JIS

 

Here are two links for encoder table which I will post here so you can easily understand what I am saying. 

QrCode will have default 8 bit byte encoder, which default encoder won't need any header to describe what encoder it is. ISO 18004:2000 is japanese QrCode documentation which register way back at 2000, where ISO 18004:2006 is international QrCode specification register at year 2006.

2000's version is using shift-jis as default encoder, where 2006 using iso 8859-1 as their default encoding. So if decoder is tailor to use ISO 18004:2000 to decode, your char ä for shift-jis table is empty. Thus gives error while trying to decode by ISO 18004:2000 decoder. So if I type ¦ char, which is A6 in ISO 8859-1 table, when I try to decode I will get ヲ as Japanese character. 

 

So now problem comes to fix, One of fix is add header for both 8859-1 and shift-jis, then it will support by all decoder. Is that good? I don't know actually. Few reasons. 

1. It will be against ISO specification. Which can be nasty if some project required. 

2. The advantage of be a default encoder will be gone for good. As I have to write header for that, the QrCode we generate will be larger than what we expect. 

Thus, currently I decide to against change, and once I have time I will add support to create QrCode for specific ISO specification. One thing you can do is either ask your user to use proper decoder(which is western focused decoder that use latest ISO specification), or if you know they are not decoder that made by Japan you can ask them to change their code, or last option edit our source code on your own( which I can help you out, it's not hard, only take few min). 

Let me know your opinion also try to read carefully about what I have written up their and make your decision according to that. One thing you might notice is that the one we can decode is using utf8. Which that QrCode is so large. It's good that we can decode, but on the other hand, if you want print something on your small business card, you are going to have hard time. As the larger code you get, the smaller cells when it paint on card, thus it will be really hard to decode. Smaller size code is optimal choice to print on limit space, that's one major reason I'm against to change our code. Please understand that. 

Aug 23, 2012 at 1:03 PM

okay, now I understand. I have tested another. NET component. It was the one who made the second QR code I sent the previous post. It also has a QR decoder. When I tested both QR codes in the decoder both were right, that shows å ä ö.

Now we handle most of it without å ä ö so I'll going to think about how we should do in the future.

Thanks for the help

Coordinator
Aug 23, 2012 at 7:32 PM

You are welcome. 

One thing I would like to point out is include head is not that expensive unless your task require to print it on a small limited space. So if you don't have that requirement, I can teach you how to enable that header so that you can use those character safely.