http://pear.php.net/bugs/search.php?cmd=display&package_name%5B0%5D=Validate&PHPSESSID=6sh8hov6085gl1gd4s43b0k8h0 Search Results en-us pear-webmaster@lists.php.net pear-webmaster@lists.php.net hourly 1 2000-01-01T12:00+00:00 http://pear.php.net/gifs/pearsmall.gif http://pear.php.net/bugs http://pear.php.net/bugs/16489 Validate Feature/Change Request Reported by adrianlang 2009-08-03T12:56:28+00:00 PHP: Irrelevant OS: Debian 5.0 Package Version: Unknown Description: ------------ I would like Validate::string to use mb_strlen for min_length and max_length.]]> Validate Feature/Change Request Reported by adrianlang 2009-08-03T12:56:28+00:00 PHP: Irrelevant OS: Debian 5.0 Package Version: Unknown Description: ------------ I would like Validate::string to use mb_strlen for min_length and max_length.]]> 2009-08-04T01:01:35+00:00 mail at adrianlang dot de Validate Feature/Change Request http://pear.php.net/bugs/13825 Validate Bug Reported by ctj951 2008-05-02T16:00:52+00:00 PHP: 5.2.5 OS: Mac OS X Package Version: 0.8.1 Description: ------------ The email validation in the Validate PEAR package doesn't work correctly. This is because the '&' symbol though valid in emails such as: "Joe & Mac"@example.com isn't accepted by the email parser. This is caused by the simple fact that the __stringToUtf7() routine doesn't recognize any string with a '&' sign as valid UTF7. This is despite the fact that the '&' character is valid UTF7 as defined by RFC 2152 as I read it: http://www.faqs.org/rfcs/rfc2152.html In the __stringToUtf7() routine the following substitution is made for the '&' character: elseif ($char == '&') { $return .= '&-'; } Thus when the UTF7 "return" string is returned it doesn't match the original string passed to the UTF7 routine and all '&' characters are replaced by '&-'. Its not clear why this substitution is made at all. Especially since this routine is only used from within the email parser. In any case the result is that the following test in __emailRFC822() fails with emails like "Joe & Mac"@example.com: if (Validate::__stringToUtf7($email) != $email) { return false; } Leading to the email parser returning that emails like "Joe & Mac"@example.com are invalid email addresses when in fact they are valid. Test script: --------------- Script 1: (fails when should succeed) $Email = '"Joe & Mac"@example.com'; $Options = 0; assert( Validate::__emailRFC822( $Email, $Options ) ); Script 2: (fails when should succeed) $string = '&'; assert( __stringToUtf7($string) == $string ); Expected result: ---------------- Scripts fail when they should succeed Actual result: -------------- Scripts faile.]]> Validate Bug Reported by ctj951 2008-05-02T16:00:52+00:00 PHP: 5.2.5 OS: Mac OS X Package Version: 0.8.1 Description: ------------ The email validation in the Validate PEAR package doesn't work correctly. This is because the '&' symbol though valid in emails such as: "Joe & Mac"@example.com isn't accepted by the email parser. This is caused by the simple fact that the __stringToUtf7() routine doesn't recognize any string with a '&' sign as valid UTF7. This is despite the fact that the '&' character is valid UTF7 as defined by RFC 2152 as I read it: http://www.faqs.org/rfcs/rfc2152.html In the __stringToUtf7() routine the following substitution is made for the '&' character: elseif ($char == '&') { $return .= '&-'; } Thus when the UTF7 "return" string is returned it doesn't match the original string passed to the UTF7 routine and all '&' characters are replaced by '&-'. Its not clear why this substitution is made at all. Especially since this routine is only used from within the email parser. In any case the result is that the following test in __emailRFC822() fails with emails like "Joe & Mac"@example.com: if (Validate::__stringToUtf7($email) != $email) { return false; } Leading to the email parser returning that emails like "Joe & Mac"@example.com are invalid email addresses when in fact they are valid. Test script: --------------- Script 1: (fails when should succeed) $Email = '"Joe & Mac"@example.com'; $Options = 0; assert( Validate::__emailRFC822( $Email, $Options ) ); Script 2: (fails when should succeed) $string = '&'; assert( __stringToUtf7($string) == $string ); Expected result: ---------------- Scripts fail when they should succeed Actual result: -------------- Scripts faile.]]> 2008-06-21T01:05:07+00:00 chadsspameateremail at yahoo dot com Validate Bug