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

IsoCodes/src/IsoCodes/ZipCode.php

Line 228 in bf815ea

return (bool) preg_match('/^('.self::$patterns[$country].')$/', $zipcode);

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 <#184 (comment)>, 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