Closed 0xced closed 6 months ago
Thanks for your contribution.
"Some other libraries out there": What specific libraries are these? (I'd like to understand the motivation for this feature.)
The culprit is the FastReport .NET library. It assumes CRLF separators when given a Swiss QR-bill code and does something roughly equivalent to this:
var parts = qrCodeText.Split("\r\n");
var iban = parts[3]; // 👈 crashes with IndexOutOfRangeException
It should be using a StreamReader but unfortunately does not!
I have reported this issue to the FastReport support today so we can probably wait a bit and see if they fix their QR data decoder.
Have you heard back re FastReport.NET?
I'm currently working on a new release. But it's delayed because I lost my access to the QR bill validator portal and SIX is not responding.
Support said it's now in the hands of the development team but that's it for now.
Note that I have updated the code since my initial pull request and force pushed. It's now using a StringWriter
instead of a StringBuilder
and the code is tidy. Since the QR-bill spec allows both LF and CR+LF I think it makes sense to propose both possibilities, defaulting to the existing (LF) behaviour.
I have merged it with minor changes to the documentation.
This introduces a new
Separator
property on theBill
object which can be either LF (the default) or CR + LF.The Swiss Implementation Guidelines for the QR-bill (§ 4.1.4 Separator element) allows both:
Some other libraries out there manipulating the QR code data absolutely require CR + LF.