ZipCode validation should be case insensitive

[stof]

Zipcode patterns are documented as generated from http://i18napis.appspot.com, which does not work anymore. I assume that this is similar to the data available at https://chromium-i18n.appspot.com/ssl-address for the libaddressinput of google.

When looking at the Java library for libaddressinput which consumes this data, the zipcode is matched case insensitively: https://github.com/google/libaddressinput/blob/2610f7b1043d6784ada41392fc9392d1ea09ea07/common/src/main/java/com/google/i18n/addressinput/common/FieldVerifier.java#L156-L163

This library performs case sensitive matching in https://github.com/ronanguilloux/IsoCodes/blob/bf815eacc2cf0c4a96d5f2ad3a4cf18827da3d25/src/IsoCodes/ZipCode.php#L228

Would it make sense to update the implementation to match the behavior of libaddressinput ?

[yguedidi]

@ronanguilloux any news here? would you accept a PR doing the change?

[ronanguilloux]

Hi guys, still in holidays - expect news end of August - cheers

Le mer. 14 août 2024 à 18:49, Yassine Guedidi @.***> a écrit :

@ronanguilloux https://github.com/ronanguilloux any news here? would you accept a PR doing the change?

— Reply to this email directly, view it on GitHub https://github.com/ronanguilloux/IsoCodes/issues/184#issuecomment-2289301182, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMSTJ3GSYSEBASMTBBEGLZRODCRAVCNFSM6AAAAABKUPY2Z6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBZGMYDCMJYGI . You are receiving this because you were mentioned.Message ID: @.***>

[ronanguilloux]

Hi @stof It would make sense to update the implementation to have zipcodes matched case-insensitively, only if you can find evidence that this is nowadays the international-approved standard way to validate zipcodes!

I'm very open to that change, as soon as you find evidence of this from a regulatory body - so not just an example of a validation library implementation.

[yguedidi]

@ronanguilloux out of curiousity, would you accept if we make it a 3rd optional argument of validate, $caseInsensitive, that will default to false, so at least developers can decide explicitly if they want case sensitive or insensitive validation by usage? Thanks

[ronanguilloux]

Why not? Yes as long as this doesn't start breaking any backward compatibility with the current ZipCode::validate($string, $country) implementation and current default behavior (case-sensitive). Something like ZipCode::validate($string, $country, $case_sensitive=false) should be okay.

[yguedidi]

@ronanguilloux here the PR: #191