Nov 1, 2012 at 9:33 AM
Edited Nov 1, 2012 at 9:37 AM
I think that's a lot to do with decoder. The one use QrCode.Net, can be properly decode by zxing. Where zxing and our's encoder's version can not be decode by ingma mobile decoder.
Currently QrCode.Net is base on ZXing, but more restrict on shift-jis. Our encoder is 100% according to ISO specification, where zxing is not for shift-jis.
Shift-jis under iso specification, only first 225 char should be used for 8 bit byte. As what iso said is most original shift-jis table, not full version. Where zxing uses full version. Shift-jis table have been expand for several times.
Another reason why our code can be decode by zxing is we are base on their encoder. It was originally re-craft on top of zxing. So even though our rule is restrict, but still within their range. Where I have never seen any other decoder's internal code.
One down side of our encoder is that we automatically decide which encoder to use. That's something I want to address later for advanced encode. As 99% of people who uses encoder, they want auto decide for them. (Well my assumption. As most people never
read iso spec, they also never read char table. There is no way for them to decide which table is best for what situation).
One way could resolve it if you know your target is most likely use shift-jis or utf8. I can tell you which code to remove, then it will only check for specific table without use kanji. I bet a lot of decoder don't care about kanji table, as its not widely
used even for Japanese. So once remove detection code you can compile and have your own special version without big issue.
Let me know if you want to do that.
Edit: For what I mean ZXing use full table. Shift-jis first 225 chars are what we call original shift-jis table, where rest of table is what Qrcode ISO specified as kanji table. Reason I said even Japanese won't use kanji much, as their language usage a
lot of time will be in first 225 chars table or mixed with kanji. Pure kanji is rare from my understanding.