ZF-1882: Improve integer validation

Issue Type: Improvement Created: 2007-08-27T06:48:54.000+0000 Last Updated: 2008-12-19T06:22:34.000+0000 Status: Resolved Fix version(s): - 1.8.0 (30/Apr/09)

Reporter: Lukasz Rajchel (rayell) Assignee: Thomas Weidner (thomas) Tags: - Zend_Validate

Related issues: Attachments: - Int-V3.php.patch


Right now Zend_Validate_Int uses intval() function while checking if given value is valid integer. There is a problem with that solution because this validation rejects all correct integers that exceedes bounds of integer type. Also note that this method of validation sometimes also approves values like 0.00000001 as valid integers, which is wrong.

This can be easy fixed by using regular expressions instead of intval() function.

This code of isValid() method:

<pre class="highlight">
if (strval(intval($valueFiltered)) != $valueFiltered) {
      return false;

can be replaced by the following one:

<pre class="highlight">
if (!preg_match('/^[-+]?((\d+(\.0*)?)|(0x[\dABCDE]+))$/', $valueFiltered)) {
      return false;

This improvement will validate all, even extremely long integer values (passed as string of course, because we don't want value beyond integer type). This can be usefull when for example when working on databases that accepts wider range of integer values than php or when working on GMP values converted to string.


Posted by Thomas Weidner (thomas) on 2008-01-22T04:29:33.000+0000

This leads to another problem:

When the locale of your environment is set to another value than 'en' the validation will not work anymore.

If you define 1000 as integer and cast it to an string you will get '1.000' when 'de' is set as locale or '1 000' if your locale is set to 'fr'.

You regex will not work in such environments...

The simplest solution would be to use Zend_Locale_Format::isInteger($number) for such cases... or as fallback to intval().

Posted by Wil Sinclair (wil) on 2008-04-18T13:12:00.000+0000

This doesn't appear to have been fixed in 1.5.0. Please update if this is not correct.

Posted by Wil Sinclair (wil) on 2008-04-18T16:55:03.000+0000

Please evaluate and categorize/assign as necessary.

Posted by Andries Seutens (andries) on 2008-04-22T12:25:11.000+0000

Please review the attached patch.

Posted by Darby Felton (darby) on 2008-04-22T12:37:30.000+0000

The patch does not make clear the changes; could you re-attach a new version (e.g., with correct line endings)? Still, I'll apply the patch to my local copy and diff without regard to white space.

Posted by Darby Felton (darby) on 2008-04-22T12:43:36.000+0000

It appears this is just output of svn diff, not a patch-compatible file; please attach such a new version.

Posted by Andries Seutens (andries) on 2008-04-22T13:00:29.000+0000

Sorry, i used wrong line endings. please check the attached file (new one)

Posted by Darby Felton (darby) on 2008-04-22T13:14:37.000+0000

setFailOnPhpIntegerBoundary() should return $this for convenience.

Also, it appears that $this->_error() is called without differentiating the cause of the error. It would be nice to expose the specific cause of the validation failure to the developer, rather than hiding it. Put another way, multiple causes of validation failure are producing the same validation failure message, which hides information that could otherwise be exposed to the application (e.g., for logging, usability analysis, etc.).

Posted by Andries Seutens (andries) on 2008-04-22T13:36:53.000+0000

changes taken into account, please verify

Posted by Andries Seutens (andries) on 2008-04-22T13:45:44.000+0000

V3 attached, please verify

Posted by Thomas Weidner (thomas) on 2008-04-22T13:54:18.000+0000

In my eyes this patch is problematic.

Zend_Validate_Int accepts only english notation regarding to replacing the actual set number tokens to english. But when you use Zend_Locale_Format you rely to the last set default locale which can differ from the one from setlocale.

I would ask you to fix the used locale to english to prevent this problem.

Also you should create a new issue to allow the usage of ANY locale which would allow the user to check for inputs of foreign locales by will. This would allow the same benefit as already available in Zend_Validate_Date.

Posted by Andries Seutens (andries) on 2008-04-22T13:59:53.000+0000


I've taken your suggestions into account, could you verify (V4).

Posted by Emanuele Deserti (lord_lele) on 2008-05-09T06:00:24.000+0000

This issue also affect Zend_Validate_Float. If you set another locale (with setlocale()) the validator will fail, because PHP function floatval() return a value with the correct (for the locale) decimal separator, but Zend_Validate_Float replace the separator with a dot '.'

It's possible to fix Zend_Validate_Float to take in account the current locale?

Here is the code:

<pre class="highlight">
$number = 123.15;
$float = new Zend_Validate_Float();
if ($float->isValid($number)) {
    echo $number . " is a valid float.";
} else {
    echo $number . " is NOT a valid float.";

This output, ever, "is NOT a valid float"... and even with:

<pre class="highlight">
$number = floatval(123.15);
// or
$number = floatval(123,15);

Posted by Wil Sinclair (wil) on 2008-12-04T13:28:47.000+0000

Andries, what is the status of this issue? Has it already been committed? Are you just waiting for Thomas' feedback?

Posted by Thomas Weidner (thomas) on 2008-12-19T06:19:11.000+0000

New feature implemented with r13375

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.