trim input in IBANValidator.validate

[sahvx655-wq]

Noticed while validating IBANs read line by line out of a file: a value with a trailing newline came back INVALID_LENGTH and one with a leading space UNKNOWN_COUNTRY, although both validate once the surrounding whitespace is stripped.

1. validate(String) is the only validation method here and isValid delegates to it, yet it never normalises its argument, unlike CodeValidator.validate and the AbstractNumberValidator/AbstractCalendarValidator parse paths which all trim first.
2. the raw string is handed to getValidator, which reads the first two characters as the country code, so a leading space selects the wrong code and any surrounding whitespace also trips the fixed-length check, leaving the returned IBANValidatorStatus misleading rather than VALID.

Trimmed once at the top of validate and ran the country lookup, length, pattern and check digit against that value; the null path is unchanged as getValidator already tolerates null.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.

[sebbASF]

Sorry, but I don't think this is a good idea.

The purpose of validation is to check the data that is passed to it.

If a caller passes an IBAN with leading or trailing spaces, and the result is success, then the caller should be able to expect that the value can be used as is when passing the data to another method which expects an actual IBAN without any spaces.

Any trimming needs to be done by the caller.

[sahvx655-wq]

Fair enough, that's a reasonable line to draw. The contract argument holds: if validate() trims and returns VALID, a caller could quite reasonably treat the string it handed in as a clean IBAN and pass it on with the whitespace still attached, which is worse than a clear rejection. Leaving normalisation to the caller keeps the status honest about exactly what was given.

I'll leave this closed. Cheers for taking a look.