|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2007-11-22 10:54 UTC] gbml at bravogroup dot org
Description: ------------ Filtering input numbers with leading zero(s) and filter FILTER_VALIDATE_INT does not produce number Reproduce code: --------------- // $_POST ["size"] has value "002" filter_input (INPUT_POST, "size", FILTER_VALIDATE_INT) Expected result: ---------------- 2 Actual result: -------------- null PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Tue Oct 28 14:00:01 2025 UTC |
FILTER_FLAG_ALLOW_OCTAL is not a feasible workaround for this issue. echo filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) ? "OKAY" : "NOT OKAY"; // RESULT: "NOT OKAY" FILTER_FLAG_ALLOW_OCTAL completely invalidates tests where the value has a leading 0 and includes an 8 or 9.That assumes one has control over the input. If for example, the input data comes from a form submission then it may in fact come into the program with leading zero(es). In order to make the data in this scenario "valid" for the test you would have to cast it or manipulate it - which makes using the built-in function moot. The concept that filter_var('8', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) should return 8, but filter_var('08', FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL) should return false is ludicrous.Potential work-around: run your input through this filter, before validating it as an integer: $input_without_leading_zeroes=\preg_replace('/^0*/','',$input); This work-around is useful in cases where you already know that your input is going to be in decimal (e.g. for an HTML <input type="number" … > control People from a digital electronics background might differ with Rasmus' assertion that numbers with leading zeroes are not valid integers. Note that FILTER_VALIDATE_FLOAT does not exhibit the same behaviour! Floating-point number-strings with leading zeroes are treated as valid, and converted accordingly into floating point PHP variables, on the assumption that they are in decimal — although FILTER_VALIDATE_FLOAT has its own deficiencies/ idiosyncrasies, in that it assumes that floating-point number-strings are expressed with a "." for a decimal point — rather than "," (comma), or even "٫" (Arabic decimal separator or momayyez)! https://en.wikipedia.org/wiki/Decimal_mark Fundamentally, we cannot expect the language to cover all these edge cases internally (otherwise, the language and its built-in features could end up quite bloated and inefficient). Someone has to decide which features to support, and which not — and someone has to standardise how the language behaves in edge-cases like these! Thanks @Rasmus for that!