filter_var

Description

Parameters

Value to filter. Note that scalar values are converted to
string internally before they are filtered.

filter

The ID of the filter to apply. The Types of filters
manual page lists the available filters.

If omitted, FILTER_DEFAULT will be used, which is
equivalent to
FILTER_UNSAFE_RAW.
This will result in no filtering taking place by default.

options

Associative array of options or bitwise disjunction of flags. If filter
accepts options, flags can be provided in "flags" field of array. For
the "callback" filter, callable type should be passed. The
callback must accept one argument, the value to be filtered, and return
the value after filtering/sanitizing it.

localpart.ending.with.dot.@example.com is not valid(comment)localpart@example.com is not valid"this is v@lid!"@example.com is not valid"much.more unusual"@example.com is not validpostbox@com is not validadmin@mailserver1 is not valid"()<>[]:,;@\"\\!#$%&'*+-/=?^_`{}| ~.a"@example.org is not valid" "@example.org is not valid

The documentation does not saying that FILTER_VALIDATE_EMAIL should pass the RFC5321, however you can meet with these examples (especially with the first one). So this is a note, not a bug report.

It's very likely that you actually want to detect all reserved ranges, not just private IPs, and there's another constant for them that should be bitwise-OR'd with it.
<?php
function is_private_ip($ip) {
return !filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE);
}
?>

Keep in mind that FILTER_VALIDATE_EMAIL will validate the email address according to standards.
However, giving the fact that organizations are free to restrict the forms of their own email addresses, using ONLY this filter can you a lot of bounces.

The logic is simple. A non-ascii char is more than one byte long. We replace every one of those chars by "X" and check again.

An alternative will be to punycode the URI before calling filter_var(), but PHP lacks native support for punycode. I think my approach is effective. Please e-mail me if you think otherwise or see room for improvement.

This will fail even if $someVariable is a valid integer in the expected range.

This can show up when you are attempting to validate a potential key for an unsigned MySQL INT type (whose maximum value is 4294967295) on a 32-bit system, where the value of PHP_INT_MAX is 2147483647.

"(comment)localpart@example.com"is an invalid E-Mail address per RFC5322 (Appendix A.6.3):"Also, the comments and white space throughout addresses, dates, and message identifiers are all part of the obsolete syntax."

Many people, myself included, have found that the FILTER_VALIDATE_EMAIL does not actually properly work.

Below is a wrapper that I believe validates every legal routable address.

<?php

/******************************************* * * These are the function * * check_username is called by check_email * - it compensates for bugs in the php * filter_var function. * - returns boolean * * check_email is the function to use. * First argument is string, address to * check * Second argument is optional boolean, * whether or not to use DNS to validate * the domain name. Defaults to true * Returns boolean * */

It is important to note that though the data type of the first parameter of the function is stated as "mixed", this is only one half of the truth.

While it accepts any data type, the first parameter will always be cast to string before being validated or sanitized.

It seems that this function was designed strictly to be used on user input strings. For example: from an online-form. When using it for anything other than that, you may see issues. So read the documentation very carefully!

Especially note that there is an (to date) unresolved issue (#49510) concerning the Boolean filter while using the FILTER_NULL_ON_FAILURE flag. Note that both (string) FALSE and FALSE are not recognized as boolean values and will return NULL (not FALSE as you might expect).

I thus personally suggest that (to date) the best way to take the filter_var()-functions beyond their original purpose (and allow future extension and customization) is to wrap them in your own classes. This will allow you to work-around unexpected behavior on non-string input and add your custom checks, or back-port filters or sanitizers that may be added in later versions of PHP.(Especially since PHP currently still lacks filters and sanitizers for some of the more exotic HTML5 input types, like "color". Thus there actually is a chance that we may see a need for custom filters or backports at some point in the future.)

Note that when using FILTER_VALIDATE_INT along with the FILTER_FLAG_ALLOW_HEX flag, the string "2f", for example, is not validated successfully, because you must use the "0x" prefix, otherwise, it treats the data as base 10.

The range options are also smart enough to recognize when the boundaries are exceeded in different bases.

Notice that filter_var with FILTER_VALIDATE_EMAIL does not work if you are trying to get a String from an XML document e.g. via xpath.

I often use XML files as configuration files and use a function that returns a string from the config file via xpath. While this worked fine before 5.2.11, it doesn't anymore (and shouldn't, since it's an XML Element, not a String).

So, instead of using php filter_var, now you can just use proper input type and proper attributes. It will make your code more clear.

In addition, php runs on server side, so, it's not good idea to validate data using php(it will take server computer resources). Much better is using javascript and html5 features for this purpose and send to server computer only validated data.