Skip to content

Failed to parse IBAN with CountryCode in lowercase #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fano0001 opened this issue Feb 19, 2020 · 4 comments
Closed

Failed to parse IBAN with CountryCode in lowercase #17

fano0001 opened this issue Feb 19, 2020 · 4 comments

Comments

@fano0001
Copy link

If we try to parse a IBAN e.g. de31 3002 0900 7500 0217 66 we got a

UnknownCountryCodeException: Unknown country code in input.

I expect that the parse method also can deal with countryCodes in lowercase.

A possible solution is to convert the substring of the countryCodes to uppercase.

@barend
Copy link
Owner

barend commented Feb 25, 2020

Hi @fano0001,

Thank you for your feature request. I'm afraid this is something I will not support in the IBAN class.

The reason is that lowercase country codes are not a thing that exists within the IBAN specification. The IBAN Registry is unambiguous there; they just don't occur. I want to stay true to the specification. I appreciate that the parse(CharSequence) method is on the edge between valid and invalid, so your request is not necessarily at odds with that idea.

However, I choose to draw the line at validating the input without modifying the input.

If you want to make it easier for your users to enter an IBAN into some UI control by allowing them to input or dictate a lowercase country code, then I think it makes sense that the UI code assists the user by uppercasing the first two characters. The inverse is not true: if someone else in some other usecase wants to reject lowercase country codes, they should not have to write an additional, external check outside this library to do so.

The third option would be to provide some kind of "parse leniently" function, but that's an open ended domain with no single right answer. I don't want to go there.

@barend barend closed this as completed Feb 25, 2020
@fano0001
Copy link
Author

Hi @barend
thx for your quick reply.

To Support our user we will uppercase the first 2 chars an then call parse.

@aSemy
Copy link

aSemy commented Aug 17, 2022

The third option would be to provide some kind of "parse leniently" function, but that's an open ended domain with no single right answer. I don't want to go there.

Hi @barend, I would like a 'parse leniently' function, but I understand your reasoning. Instead, would you consider formalizing the exceptions that java-iban can throw? For example, adding an interface IbanException and ensuring that all exceptions that java-iban throws extend from this interface? Then I can implement 'parse leniently' as

public IBAN parseIbanLenient(String input) {
  try {
    return IBAN.parse(input);
  } catch(IbanException e) {
    return null;
  }
}

I think this is possible at the moment because from a quick check I think that all exceptions extend IllegalArgumentException, but being able to specifically determine that an exception is because of a problem with IBAN validation would be much more convenient.

@barend
Copy link
Owner

barend commented Sep 16, 2022

@aSemy sorry for the delayed reply, you posted while I was on vacation. I like your suggestion and I'll add an intermediate IBANException.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants