feat: add whitespace filtering to iban validator

[Erawpalassalg]

• add a new function to filter whitespace to IBAN validator

[yozachar]

Hi, @Erawpalassalg, this library does not perform input data sanitization (mostly). See the cards module. Those numbers could be separated by spaces, hyphens, or slashes, but that's not taken into account for validation.

[Erawpalassalg]

Hi @yozachar, thanks for letting me know.

Would this matter be open to discussion? As I believe that by only validating the machine-readable format this lib puts the formatting pressure on the end user rather than on the developer/company storing the numbers.

If not, could this be stated very clearly in the docs? (For the IBAN case, the discrepancy between the human-readable format and the machine-readable format is a whole part of the Wikipedia related page)

[yozachar]

Would this matter be open to discussion? As I believe that by only validating the machine-readable format this lib puts the formatting pressure on the end user rather than on the developer/company storing the numbers.

I suppose an end-user would be a non-developer, in that case, they are never going to use this library directly. Another developer/company who works for the end-user/client, making use of this library, can and should, sanitize the human-readable input (from the end-user) before validating it.

Regardless, if spaces are the only separators, I suppose it can be considered (even though input sanitization is beyond the scope of this library).

[Erawpalassalg]

I went a little further with this IBAN stuff.

Apparently a lib already does all the validation taking into account the specifics of the ISO-13616 mentioned in this document, and it's called schwifty.

The interesting things when playing around with schwifty are:

• They don't care about spaces in the input (suppressing them internally)
• Some of their invalid test cases actually pass validators' validation process (I double-checked with an online validator, which is consistent with schwifty), said test cases are:
  • GB96 BARC 2020 1530 0934 591 -- Too long
  • GB12 BARC 2020 1530 093A 59 -- Wrong account format (country specific)
  • GB01 BARC 2071 4583 6083 87 -- Wrong checksum digits
  • GB00 HLFX 1101 6111 4553 65 -- Wrong checksum digits

So, I was wondering if it would be interesting to start using schwifty as a dependency to be compliant with ISO-13616?

[yozachar]

Cool, I'm open to adding it as an optional dependency.