strip spaces and strip 2D coding prefix if it conforms to eHealth Network Version 1.3, section 2.3

[smarek]

Per specs https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v3_en.pdf

1. strips spaces around the string (typical issue when pasting base45 data through emails, ...)
2. strip prefix, validated by regex, if it conforms with spec section "2.3 2D Code Versioning" (support for NL1, CZ1, HC2, ...)

This might result in trying to parse unsupported data (newer version of certificate) but the basics (b45+zlib) won't ever imho change, cbor will only contain different document

This should fix at least #15

[hannob]

I guess stripping spaces is a good idea, but I'm more skeptical about the other change. I don't think what you write about other barcodes is true, there's an open issue about someone with an NL1 cert and it decodes to something that isn't base45 at all.
Can you point me to example certs for these different prefixes that would be decodable with this change?

[smarek]

Yes, I assumed that the EU certificates concept gets adopted nationally, and certificates might be issued with local jurisdiction and localized prefix, which has to follow the 2D Code Versioning outlined in specs, but I assumed that all national certificates will follow the data structure outlined in EU specs.

This is indeed mistake, see these
minvws/base45-go#1 (comment)
https://github.com/StefH/Dutch-CoronaCheck-QR-Code-Decoder-and-Verifier#overview

So i'll leave that up to you, it won't solve the NL2 incompatibility (and we can specifically point out if the version is not HC1, that the data might not get decoded at all), but if HC2 will be (and i don't see why it should't be) compatible with HC1 (ie. base45 of zlib of CBOR document), then it could be long-term efficient solution