Fix: Umlaute for creditor and debtor about swissqrbill HOT 8 CLOSED

Thank you for your feedback. I think you are probably right. I have to look into this, but I don't expect to have time to do so until the weekend.

from swissqrbill.

Hi

If you follow the QR-Bill specifications (page 25) exactly, umlauts are actually not allowed.

However, many other QR Bill generators and banks support the umlauts anyway. In fact, I was not aware of any bank that does not support umlauts, and all the banks I have tested support them as well, so I decided against strictly enforcing this rule.

If you really want to be on the save side, you should convert the umlauts for example from Zürich to Zuerich.

Maybe I could add an option in the next version to convert them automatically.

from swissqrbill.

Hi @schoero,

thanks for your quick response. I am wondering why umlauts should not be allowed. What I unterstand on page 25 is that umlauts are not allowed for field definitions and I want to use umlauts in values not in the field definition. Additional the QR code has to be in latin character set which allows umlauts or not? There are multiple example in the specifications with umlauts in the value (page 38, 43, 45 - Max Muster & Söhne).

My bank supports umlauts. I know it because I successfully use the postfinance QR generator with umlauts.

Your generator seems to have a different encoding. Are you sure that your QR-Code has the utf-8 encoding?

from swissqrbill.

Just a quick feedback as I have been doing some research on this topic and I wanted to share my findings:

I decoded a QR code generated by the PostFinance generator and noticed extra bytes 71 a4 00... at the beginning.
By default, a QR code does not encode or transform any data. This means that the string (or bytes) you enter are also the bytes that the reader reads.
If the PostFinance reader treated the read-in data as utf-8 encoded bytes, it would already support umlauts.

However, in the QR code, different modes can be set and one of these modes allows us to " enforce" the encoding. This mode is called "Extended Channel Interpretation" ECI for short and I found some great documentation on this here starting on page 16. These modes are then set with the extra bytes mentioned above.

Apparently the PostFinance generator uses this mode to specify the encoding, and the PostFinance reader depends on this information.

Unfortunately, the library I used (and all other libraries I found) to generate the QR code does not support this mode. However, at first glance I think I could implement this myself with manageable effort.

I just wanted to let you know in case you are doing some research yourself.

from swissqrbill.

Great catch @schoero, thanks for your research and it sounds promising. I only used the PostFinance generator to generate QR code before and scanned it within another bank. So it seems to me that it's some kind of standard what you figured out.

from swissqrbill.

Hi @vanvuongngo
I ended up changing the QR-Code library #367 because I have found one that supports the ECI segments and seems to be written very well.

I have published a beta version, which uses the new QR-Code library. You can install it using the following command:

npm i swissqrbill@beta

Could you please test if the new version now properly gets decoded using the PostFinance scanner? If you have access to any other ebanking or scanners, I would be happy if you could test them as well because I want to ensure that this change does not affect any other bank.

So far I have testet it in the following ebanking apps:

• Raiffeisen
• ZKB

from swissqrbill.

H @schoero,
tip top :) and it works with my ebanking apps:

• BKB
• migros bank

from swissqrbill.

Thank you for testing, I have released the new version v3.1.5 on npm.

from swissqrbill.