Standard Validation Classes¶
Zend Framework comes with a standard set of validation classes, which are ready for you to use.
Alnum¶
Zend\Validator\Alnum
allows you to validate if a given value contains only alphabetical characters and digits.
There is no length limitation for the input you want to validate.
Supported options for Zend\Validator\Alnum¶
The following options are supported for Zend\Validator\Alnum
:
- allowWhiteSpace: If whitespace characters are allowed. This option defaults to
FALSE
Basic usage¶
A basic example is the following one:
1 2 3 4 5 6 | $validator = new Zend\Validator\Alnum();
if ($validator->isValid('Abcd12')) {
// value contains only allowed chars
} else {
// false
}
|
Using whitespaces¶
Per default whitespaces are not accepted because they are not part of the alphabet. Still, there is a way to accept them as input. This allows to validate complete sentences or phrases.
To allow the usage of whitespaces you need to give the allowWhiteSpace
option. This can be done while creating
an instance of the validator, or afterwards by using setAllowWhiteSpace()
. To get the actual state you can use
getAllowWhiteSpace()
.
1 2 3 4 5 6 | $validator = new Zend\Validator\Alnum(array('allowWhiteSpace' => true));
if ($validator->isValid('Abcd and 12')) {
// value contains only allowed chars
} else {
// false
}
|
Using different languages¶
When using Zend\Validator\Alnum
then the language which the user sets within his browser will be used to set
the allowed characters. This means when your user sets de for german then he can also enter characters like
ä, ö and ü additionally to the characters from the english alphabet.
Which characters are allowed depends completely on the used language as every language defines it’s own set of characters.
There are actually 3 languages which are not accepted in their own script. These languages are korean, japanese and chinese because this languages are using an alphabet where a single character is build by using multiple characters.
In the case you are using these languages, the input will only be validated by using the english alphabet.
Alpha¶
Zend\Validator\Alpha
allows you to validate if a given value contains only alphabetical characters. There is no
length limitation for the input you want to validate. This validator is related to the Zend\Validator\Alnum
validator with the exception that it does not accept digits.
Supported options for Zend\Validator\Alpha¶
The following options are supported for Zend\Validator\Alpha
:
- allowWhiteSpace: If whitespace characters are allowed. This option defaults to
FALSE
Basic usage¶
A basic example is the following one:
1 2 3 4 5 6 | $validator = new Zend\Validator\Alpha();
if ($validator->isValid('Abcd')) {
// value contains only allowed chars
} else {
// false
}
|
Using whitespaces¶
Per default whitespaces are not accepted because they are not part of the alphabet. Still, there is a way to accept them as input. This allows to validate complete sentences or phrases.
To allow the usage of whitespaces you need to give the allowWhiteSpace
option. This can be done while creating
an instance of the validator, or afterwards by using setAllowWhiteSpace()
. To get the actual state you can use
getAllowWhiteSpace()
.
1 2 3 4 5 6 | $validator = new Zend\Validator\Alpha(array('allowWhiteSpace' => true));
if ($validator->isValid('Abcd and efg')) {
// value contains only allowed chars
} else {
// false
}
|
Using different languages¶
When using Zend\Validator\Alpha
then the language which the user sets within his browser will be used to set
the allowed characters. This means when your user sets de for german then he can also enter characters like
ä, ö and ü additionally to the characters from the english alphabet.
Which characters are allowed depends completely on the used language as every language defines it’s own set of characters.
There are actually 3 languages which are not accepted in their own script. These languages are korean, japanese and chinese because this languages are using an alphabet where a single character is build by using multiple characters.
In the case you are using these languages, the input will only be validated by using the english alphabet.
Barcode¶
Zend\Validator\Barcode
allows you to check if a given value can be represented as barcode.
Zend\Validator\Barcode
supports multiple barcode standards and can be extended with proprietary barcode
implementations very easily. The following barcode standards are supported:
CODABAR: Also known as Code-a-bar.
This barcode has no length limitation. It supports only digits, and 6 special chars. Codabar is a self-checking barcode. This standard is very old. Common use cases are within airbills or photo labs where multi-part forms are used with dot-matrix printers.
CODE128: CODE128 is a high density barcode.
This barcode has no length limitation. It supports the first 128 ascii characters. When used with printing characters it has an checksum which is calculated modulo 103. This standard is used worldwide as it supports upper and lowercase characters.
CODE25: Often called “two of five” or “Code25 Industrial”.
This barcode has no length limitation. It supports only digits, and the last digit can be an optional checksum which is calculated with modulo 10. This standard is very old and nowadays not often used. Common use cases are within the industry.
CODE25INTERLEAVED: Often called “Code 2 of 5 Interleaved”.
This standard is a variant of CODE25. It has no length limitation, but it must contain an even amount of characters. It supports only digits, and the last digit can be an optional checksum which is calculated with modulo 10. It is used worldwide and common on the market.
CODE39: CODE39 is one of the oldest available codes.
This barcode has a variable length. It supports digits, upper cased alphabetical characters and 7 special characters like whitespace, point and dollar sign. It can have an optional checksum which is calculated with modulo 43. This standard is used worldwide and common within the industry.
CODE39EXT: CODE39EXT is an extension of CODE39.
This barcode has the same properties as CODE39. Additionally it allows the usage of all 128 ASCII characters. This standard is used worldwide and common within the industry.
CODE93: CODE93 is the successor of CODE39.
This barcode has a variable length. It supports digits, alphabetical characters and 7 special characters. It has an optional checksum which is calculated with modulo 47 and contains 2 characters. This standard produces a denser code than CODE39 and is more secure.
CODE93EXT: CODE93EXT is an extension of CODE93.
This barcode has the same properties as CODE93. Additionally it allows the usage of all 128 ASCII characters. This standard is used worldwide and common within the industry.
EAN2: EAN is the shortcut for “European Article Number”.
These barcode must have 2 characters. It supports only digits and does not have a checksum. This standard is mainly used as addition to EAN13 (ISBN) when printed on books.
EAN5: EAN is the shortcut for “European Article Number”.
These barcode must have 5 characters. It supports only digits and does not have a checksum. This standard is mainly used as addition to EAN13 (ISBN) when printed on books.
EAN8: EAN is the shortcut for “European Article Number”.
These barcode can have 7 or 8 characters. It supports only digits. When it has a length of 8 characters it includes a checksum. This standard is used worldwide but has a very limited range. It can be found on small articles where a longer barcode could not be printed.
EAN12: EAN is the shortcut for “European Article Number”.
This barcode must have a length of 12 characters. It supports only digits, and the last digit is always a checksum which is calculated with modulo 10. This standard is used within the USA and common on the market. It has been superseded by EAN13.
EAN13: EAN is the shortcut for “European Article Number”.
This barcode must have a length of 13 characters. It supports only digits, and the last digit is always a checksum which is calculated with modulo 10. This standard is used worldwide and common on the market.
EAN14: EAN is the shortcut for “European Article Number”.
This barcode must have a length of 14 characters. It supports only digits, and the last digit is always a checksum which is calculated with modulo 10. This standard is used worldwide and common on the market. It is the successor for EAN13.
EAN18: EAN is the shortcut for “European Article Number”.
This barcode must have a length of 18 characters. It support only digits. The last digit is always a checksum digit which is calculated with modulo 10. This code is often used for the identification of shipping containers.
GTIN12: GTIN is the shortcut for “Global Trade Item Number”.
This barcode uses the same standard as EAN12 and is its successor. It’s commonly used within the USA.
GTIN13: GTIN is the shortcut for “Global Trade Item Number”.
This barcode uses the same standard as EAN13 and is its successor. It is used worldwide by industry.
GTIN14: GTIN is the shortcut for “Global Trade Item Number”.
This barcode uses the same standard as EAN14 and is its successor. It is used worldwide and common on the market.
IDENTCODE: Identcode is used by Deutsche Post and DHL. It’s an specialized implementation of Code25.
This barcode must have a length of 12 characters. It supports only digits, and the last digit is always a checksum which is calculated with modulo 10. This standard is mainly used by the companies DP and DHL.
INTELLIGENTMAIL: Intelligent Mail is a postal barcode.
This barcode can have a length of 20, 25, 29 or 31 characters. It supports only digits, and contains no checksum. This standard is the successor of PLANET and POSTNET. It is mainly used by the United States Postal Services.
ISSN: ISSN is the abbreviation for International Standard Serial Number.
This barcode can have a length of 8 or 13 characters. It supports only digits, and the last digit must be a checksum digit which is calculated with modulo 11. It is used worldwide for printed publications.
ITF14: ITF14 is the GS1 implementation of an Interleaved Two of Five bar code.
This barcode is a special variant of Interleaved 2 of 5. It must have a length of 14 characters and is based on GTIN14. It supports only digits, and the last digit must be a checksum digit which is calculated with modulo 10. It is used worldwide and common within the market.
LEITCODE: Leitcode is used by Deutsche Post and DHL. It’s an specialized implementation of Code25.
This barcode must have a length of 14 characters. It supports only digits, and the last digit is always a checksum which is calculated with modulo 10. This standard is mainly used by the companies DP and DHL.
PLANET: Planet is the abbreviation for Postal Alpha Numeric Encoding Technique.
This barcode can have a length of 12 or 14 characters. It supports only digits, and the last digit is always a checksum. This standard is mainly used by the United States Postal Services.
POSTNET: Postnet is used by the US Postal Service.
This barcode can have a length of 6, 7, 10 or 12 characters. It supports only digits, and the last digit is always a checksum. This standard is mainly used by the United States Postal Services.
ROYALMAIL: Royalmail is used by Royal Mail.
This barcode has no defined length. It supports digits, uppercase letters, and the last digit is always a checksum. This standard is mainly used by Royal Mail for their Cleanmail Service. It is also called RM4SCC.
SSCC: SSCC is the shortcut for “Serial Shipping Container Code”.
This barcode is a variant of EAN barcode. It must have a length of 18 characters and supports only digits. The last digit must be a checksum digit which is calculated with modulo 10. It is commonly used by the transport industry.
UPCA: UPC is the shortcut for “Universal Product Code”.
This barcode preceded EAN13. It must have a length of 12 characters and supports only digits. The last digit must be a checksum digit which is calculated with modulo 10. It is commonly used within the USA.
UPCE: UPCE is the short variant from UPCA.
This barcode is a smaller variant of UPCA. It can have a length of 6, 7 or 8 characters and supports only digits. When the barcode is 8 chars long it includes a checksum which is calculated with modulo 10. It is commonly used with small products where a UPCA barcode would not fit.
Supported options for Zend\Validator\Barcode¶
The following options are supported for Zend\Validator\Barcode
:
- adapter: Sets the barcode adapter which will be used. Supported are all above noted adapters. When using a self defined adapter, then you have to set the complete class name.
- checksum:
TRUE
when the barcode should contain a checksum. The default value depends on the used adapter. Note that some adapters don’t allow to set this option. - options: Defines optional options for a self written adapters.
Basic usage¶
To validate if a given string is a barcode you just need to know its type. See the following example for an EAN13 barcode:
1 2 3 4 5 6 | $valid = new Zend\Validator\Barcode('EAN13');
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Optional checksum¶
Some barcodes can be provided with an optional checksum. These barcodes would be valid even without checksum.
Still, when you provide a checksum, then you should also validate it. By default, these barcode types perform no
checksum validation. By using the checksum
option you can define if the checksum will be validated or ignored.
1 2 3 4 5 6 7 8 9 | $valid = new Zend\Validator\Barcode(array(
'adapter' => 'EAN13',
'checksum' => false,
));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Note
Reduced security by disabling checksum validation
By switching off checksum validation you will also reduce the security of the used barcodes. Additionally you should note that you can also turn off the checksum validation for those barcode types which must contain a checksum value. Barcodes which would not be valid could then be returned as valid even if they are not.
Writing custom adapters¶
You may write custom barcode validators for usage with Zend\Validator\Barcode
; this is often necessary when
dealing with proprietary barcode types. To write your own barcode validator, you need the following information.
- Length: The length your barcode must have. It can have one of the following values:
- Integer: A value greater 0, which means that the barcode must have this length.
- -1: There is no limitation for the length of this barcode.
- “even”: The length of this barcode must have a even amount of digits.
- “odd”: The length of this barcode must have a odd amount of digits.
- array: An array of integer values. The length of this barcode must have one of the set array values.
- Characters: A string which contains all allowed characters for this barcode. Also the integer value 128 is allowed, which means the first 128 characters of the ASCII table.
- Checksum: A string which will be used as callback for a method which does the checksum validation.
Your custom barcode validator must extend Zend\Validator\Barcode\AbstractAdapter
or implement
Zend\Validator\Barcode\AdapterInterface
.
As an example, let’s create a validator that expects an even number of characters that include all digits and the letters ‘ABCDE’, and which requires a checksum.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | class My\Barcode\MyBar extends Zend\Validator\Barcode\AbstractAdapter
{
protected $length = 'even';
protected $characters = '0123456789ABCDE';
protected $checksum = 'mod66';
protected function mod66($barcode)
{
// do some validations and return a boolean
}
}
$valid = new Zend\Validator\Barcode('My\Barcode\MyBar');
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Between¶
Zend\Validator\Between
allows you to validate if a given value is between two other values.
Note
Zend\Validator\Between supports only number validation
It should be noted that Zend\Validator\Between
supports only the validation of numbers. Strings or dates can
not be validated with this validator.
Supported options for Zend\Validator\Between¶
The following options are supported for Zend\Validator\Between
:
- inclusive: Defines if the validation is inclusive the minimum and maximum border values or exclusive. It
defaults to
TRUE
. - max: Sets the maximum border for the validation.
- min: Sets the minimum border for the validation.
Default behaviour for Zend\Validator\Between¶
Per default this validator checks if a value is between min
and max
where both border values are allowed as
value.
1 2 3 4 | $valid = new Zend\Validator\Between(array('min' => 0, 'max' => 10));
$value = 10;
$result = $valid->isValid($value);
// returns true
|
In the above example the result is TRUE
due to the reason that per default the search is inclusively the border
values. This means in our case that any value from ‘0’ to ‘10’ is allowed. And values like ‘-1’ and ‘11’ will
return FALSE
.
Validation exclusive the border values¶
Sometimes it is useful to validate a value by excluding the border values. See the following example:
1 2 3 4 5 6 7 8 9 10 | $valid = new Zend\Validator\Between(
array(
'min' => 0,
'max' => 10,
'inclusive' => false
)
);
$value = 10;
$result = $valid->isValid($value);
// returns false
|
The example is almost equal to our first example but we excluded the border value. Now the values ‘0’ and ‘10’ are
no longer allowed and will return FALSE
.
Callback¶
Zend\Validator\Callback
allows you to provide a callback with which to validate a given value.
Supported options for Zend\Validator\Callback¶
The following options are supported for Zend\Validator\Callback
:
- callback: Sets the callback which will be called for the validation.
- options: Sets the additional options which will be given to the callback.
Basic usage¶
The simplest usecase is to have a single function and use it as a callback. Let’s expect we have the following function.
1 2 3 4 5 | function myMethod($value)
{
// some validation
return true;
}
|
To use it within Zend\Validator\Callback
you just have to call it this way:
1 2 3 4 5 6 | $valid = new Zend\Validator\Callback('myMethod');
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Usage with closures¶
PHP 5.3 introduces closures, which are basically self-contained or anonymous functions. PHP considers
closures another form of callback, and, as such, may be used with Zend\Validator\Callback
. As an example:
1 2 3 4 5 6 7 8 9 10 | $valid = new Zend\Validator\Callback(function($value){
// some validation
return true;
});
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Usage with class-based callbacks¶
Of course it’s also possible to use a class method as callback. Let’s expect we have the following class method:
1 2 3 4 5 6 7 8 | class MyClass
{
public function myMethod($value)
{
// some validation
return true;
}
}
|
The definition of the callback is in this case almost the same. You have just to create an instance of the class before the method and create an array describing the callback:
1 2 3 4 5 6 7 | $object = new MyClass;
$valid = new Zend\Validator\Callback(array($object, 'myMethod'));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
You may also define a static method as a callback. Consider the following class definition and validator usage:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | class MyClass
{
public static function test($value)
{
// some validation
return true;
}
}
$valid = new Zend\Validator\Callback(array('MyClass', 'test'));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Finally, if you are using PHP 5.3, you may define the magic method __invoke()
in your class. If you do so,
simply providing an instance of the class as the callback will also work:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | class MyClass
{
public function __invoke($value)
{
// some validation
return true;
}
}
$object = new MyClass();
$valid = new Zend\Validator\Callback($object);
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Adding options¶
Zend\Validator\Callback
also allows the usage of options which are provided as additional arguments to the
callback.
Consider the following class and method definition:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | class MyClass
{
function myMethod($value, $option)
{
// some validation
return true;
}
//if a context is present
function myMethod($value, $context, $option)
{
// some validation
return true;
}
}
|
There are two ways to inform the validator of additional options: pass them in the constructor, or pass them to the
setOptions()
method.
To pass them to the constructor, you would need to pass an array containing two keys, “callback” and “options”:
1 2 3 4 5 6 7 8 9 10 | $valid = new Zend\Validator\Callback(array(
'callback' => array('MyClass', 'myMethod'),
'options' => $option,
));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Otherwise, you may pass them to the validator after instantiation:
1 2 3 4 5 6 7 8 | $valid = new Zend\Validator\Callback(array('MyClass', 'myMethod'));
$valid->setOptions($option);
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
When there are additional values given to isValid()
then these values will be added immediately after
$value
.
1 2 3 4 5 6 7 8 | $valid = new Zend\Validator\Callback(array('MyClass', 'myMethod'));
$valid->setOptions($option);
if ($valid->isValid($input, $additional)) {
// input appears to be valid
} else {
// input is invalid
}
|
When making the call to the callback, the value to be validated will always be passed as the first argument to the
callback followed by all other values given to isValid()
; all other options will follow it. The amount and type
of options which can be used is not limited.
CreditCard¶
Zend\Validator\CreditCard
allows you to validate if a given value could be a credit card number.
A credit card contains several items of metadata, including a hologram, account number, logo, expiration date,
security code and the card holder name. The algorithms for verifying the combination of metadata are only known to
the issuing company, and should be verified with them for purposes of payment. However, it’s often useful to know
whether or not a given number actually falls within the ranges of possible numbers prior to performing such
verification, and, as such, Zend\Validator\CreditCard
simply verifies that the credit card number provided is
well-formed.
For those cases where you have a service that can perform comprehensive verification, Zend\Validator\CreditCard
also provides the ability to attach a service callback to trigger once the credit card number has been deemed
valid; this callback will then be triggered, and its return value will determine overall validity.
The following issuing institutes are accepted:
- American Express
- China UnionPay
- Diners Club Card Blanche
- Diners Club International
- Diners Club US & Canada
- Discover Card
- JCB
- Laser
- Maestro
- MasterCard
- Solo
- Visa
- Visa Electron
Note
Invalid institutes
The institutes Bankcard and Diners Club enRoute do not exist anymore. Therefore they are treated as invalid.
Switch has been rebranded to Visa and is therefore also treated as invalid.
Supported options for Zend\Validator\CreditCard¶
The following options are supported for Zend\Validator\CreditCard
:
- service: A callback to an online service which will additionally be used for the validation.
- type: The type of credit card which will be validated. See the below list of institutes for details.
Basic usage¶
There are several credit card institutes which can be validated by Zend\Validator\CreditCard
. Per default, all
known institutes will be accepted. See the following example:
1 2 3 4 5 6 | $valid = new Zend\Validator\CreditCard();
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
The above example would validate against all known credit card institutes.
Accepting defined credit cards¶
Sometimes it is necessary to accept only defined credit card institutes instead of all; e.g., when you have a
webshop which accepts only Visa and American Express cards. Zend\Validator\CreditCard
allows you to do exactly
this by limiting it to exactly these institutes.
To use a limitation you can either provide specific institutes at initiation, or afterwards by using setType()
.
Each can take several arguments.
You can provide a single institute:
1 2 3 | $valid = new Zend\Validator\CreditCard(
Zend\Validator\CreditCard::AMERICAN_EXPRESS
);
|
When you want to allow multiple institutes, then you can provide them as array:
1 2 3 4 | $valid = new Zend\Validator\CreditCard(array(
Zend\Validator\CreditCard::AMERICAN_EXPRESS,
Zend\Validator\CreditCard::VISA
));
|
And as with all validators, you can also pass an associative array of options or an instance of Traversable
. In
this case you have to provide the institutes with the type
array key as simulated here:
1 2 3 | $valid = new Zend\Validator\CreditCard(array(
'type' => array(Zend\Validator\CreditCard::AMERICAN_EXPRESS)
));
|
Institute | Constant |
---|---|
American Express | ZendValidatorCreditCard::AMERICAN_EXPRESS |
China UnionPay | ZendValidatorCreditCard::UNIONPAY |
Diners Club Card Blanche | ZendValidatorCreditCard::DINERS_CLUB |
Diners Club International | ZendValidatorCreditCard::DINERS_CLUB |
Diners Club US & Canada | ZendValidatorCreditCard::DINERS_CLUB_US |
Discover Card | ZendValidatorCreditCard::DISCOVER |
JCB | ZendValidatorCreditCard::JCB |
Laser | ZendValidatorCreditCard::LASER |
Maestro | ZendValidatorCreditCard::MAESTRO |
MasterCard | ZendValidatorCreditCard::MASTERCARD |
Solo | ZendValidatorCreditCard::SOLO |
Visa | ZendValidatorCreditCard::VISA |
Visa Electron | ZendValidatorCreditCard::VISA |
You can also set or add institutes afterward instantiation by using the methods setType()
, addType()
and
getType()
.
1 2 3 4 5 | $valid = new Zend\Validator\CreditCard();
$valid->setType(array(
Zend\Validator\CreditCard::AMERICAN_EXPRESS,
Zend\Validator\CreditCard::VISA
));
|
Note
Default institute
When no institute is given at initiation then ALL
will be used, which sets all institutes at once.
In this case the usage of addType()
is useless because all institutes are already added.
Validation by using foreign APIs¶
As said before Zend\Validator\CreditCard
will only validate the credit card number. Fortunately, some
institutes provide online APIs which can validate a credit card number by using algorithms which are not
available to the public. Most of these services are paid services. Therefore, this check is deactivated per
default.
When you have access to such an API, then you can use it as an add on for Zend\Validator\CreditCard
and
increase the security of the validation.
To do so, you simply need to give a callback which will be called when the generic validation has passed. This prevents the API from being called for invalid numbers, which increases the performance of the application.
setService()
sets a new service, and getService()
returns the set service. As a configuration option, you
can give the array key ‘service
‘ at initiation. For details about possible options take a look into
Callback.
1 2 3 4 5 6 7 8 9 10 11 12 13 | // Your service class
class CcService
{
public function checkOnline($cardnumber, $types)
{
// some online validation
}
}
// The validation
$service = new CcService();
$valid = new Zend\Validator\CreditCard(Zend\Validator\CreditCard::VISA);
$valid->setService(array($service, 'checkOnline'));
|
As you can see the callback method will be called with the credit card number as the first parameter, and the accepted types as the second parameter.
Ccnum¶
Note
The Ccnum
validator has been deprecated in favor of the CreditCard
validator. For security reasons you
should use CreditCard instead of Ccnum.
Date¶
Zend\Validator\Date
allows you to validate if a given value contains a date. This validator validates also
localized input.
Supported options for Zend\Validator\Date¶
The following options are supported for Zend\Validator\Date
:
- format: Sets the format which is used to write the date.
- locale: Sets the locale which will be used to validate date values.
Default date validation¶
The easiest way to validate a date is by using the default date format. It is used when no locale and no format has been given.
1 2 3 4 | $validator = new Zend\Validator\Date();
$validator->isValid('2000-10-10'); // returns true
$validator->isValid('10.10.2000'); // returns false
|
The default date format for Zend\Validator\Date
is ‘yyyy-MM-dd’.
Localized date validation¶
Zend\Validator\Date
validates also dates which are given in a localized format. By using the locale
option
you can define the locale which the date format should use for validation.
1 2 3 4 | $validator = new Zend\Validator\Date(array('locale' => 'de'));
$validator->isValid('10.Feb.2010'); // returns true
$validator->isValid('10.May.2010'); // returns false
|
The locale
option sets the default date format. In the above example this is ‘j.M.Y’ which is defined as
default date format for ‘de’.
Self defined date validation¶
Zend\Validator\Date
supports also self defined date formats. When you want to validate such a date you can use
the format
option. This option accepts format as specified in the standard PHP function date().
1 2 3 4 | $validator = new Zend\Validator\Date(array('format' => 'Y'));
$validator->isValid('2010'); // returns true
$validator->isValid('May'); // returns false
|
Of course you can combine format
and locale
. In this case you can also use localized month or day names.
1 2 3 4 | $validator = new Zend\Validator\Date(array('format' => 'Y F', 'locale' => 'de'));
$validator->isValid('2010 Dezember'); // returns true
$validator->isValid('2010 June'); // returns false
|
Db\RecordExists and Db\NoRecordExists¶
Zend\Validator\Db\RecordExists
and Zend\Validator\Db\NoRecordExists
provide a means to test whether a
record exists in a given table of a database, with a given value.
Supported options for Zend\Validator\Db\*¶
The following options are supported for Zend\Validator\Db\NoRecordExists
and
Zend\Validator\Db\RecordExists
:
- adapter: The database adapter that will be used for the search.
- exclude: Sets records that will be excluded from the search.
- field: The database field within this table that will be searched for the record.
- schema: Sets the schema that will be used for the search.
- table: The table that will be searched for the record.
Note
In ZF1 it was possible to set an application wide default database adapter that was consumed by this class. As this is not possible in ZF2, it is now always required to supply an adapter.
Basic usage¶
An example of basic usage of the validators:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | //Check that the email address exists in the database
$validator = new Zend\Validator\Db\RecordExists(
array(
'table' => 'users',
'field' => 'emailaddress',
'adapter' => $dbAdapter
)
);
if ($validator->isValid($emailaddress)) {
// email address appears to be valid
} else {
// email address is invalid; print the reasons
foreach ($validator->getMessages() as $message) {
echo "$message\n";
}
}
|
The above will test that a given email address is in the database table. If no record is found containing the value
of $emailaddress
in the specified column, then an error message is displayed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | //Check that the username is not present in the database
$validator = new Zend\Validator\Db\NoRecordExists(
array(
'table' => 'users',
'field' => 'username',
'adapter' => $dbAdapter
)
);
if ($validator->isValid($username)) {
// username appears to be valid
} else {
// username is invalid; print the reason
$messages = $validator->getMessages();
foreach ($messages as $message) {
echo "$message\n";
}
}
|
The above will test that a given username is not in the database table. If a record is found containing the value
of $username
in the specified column, then an error message is displayed.
Excluding records¶
Zend\Validator\Db\RecordExists
and Zend\Validator\Db\NoRecordExists
also provide a means to test the
database, excluding a part of the table, either by providing a where clause as a string, or an array with the keys
“field” and “value”.
When providing an array for the exclude clause, the != operator is used, so you can check the rest of a table for a value before altering a record (for example on a user profile form)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | //Check no other users have the username
$user_id = $user->getId();
$validator = new Zend\Validator\Db\NoRecordExists(
array(
'table' => 'users',
'field' => 'username',
'exclude' => array(
'field' => 'id',
'value' => $user_id
)
)
);
if ($validator->isValid($username)) {
// username appears to be valid
} else {
// username is invalid; print the reason
$messages = $validator->getMessages();
foreach ($messages as $message) {
echo "$message\n";
}
}
|
The above example will check the table to ensure no records other than the one where id = $user_id
contains the
value $username.
You can also provide a string to the exclude clause so you can use an operator other than !=. This can be useful for testing against composite keys.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $email = 'user@example.com';
$clause = $dbAdapter->quoteIdentifier('email') . ' = ' . $dbAdapter->quoteValue($email);
$validator = new Zend\Validator\Db\RecordExists(
array(
'table' => 'users',
'field' => 'username',
'adapter' => $dbAdapter,
'exclude' => $clause
)
);
if ($validator->isValid($username)) {
// username appears to be valid
} else {
// username is invalid; print the reason
$messages = $validator->getMessages();
foreach ($messages as $message) {
echo "$message\n";
}
}
|
The above example will check the ‘users’ table to ensure that only a record with both the username $username
and with the email $email
is valid.
Database Schemas¶
You can specify a schema within your database for adapters such as PostgreSQL and DB/2 by simply supplying an array
with table
and schema
keys. As in the example below:
1 2 3 4 5 6 7 | $validator = new Zend\Validator\Db\RecordExists(
array(
'table' => 'users',
'schema' => 'my',
'field' => 'id'
)
);
|
Using a Select object¶
It is also possible to supply the validators with a Zend\Db\Sql\Select
object in place of options.
The validator then uses this object instead of building its own. This allows for greater flexibility with selection
of records used for validation.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | $select = new Zend\Db\Sql\Select();
$select->from('users')
->where->equalTo('id', $user_id)
->where->equalTo('email', $email);
$validator = new Zend\Validator\Db\RecordExists($select);
// We still need to set our database adapter
$validator->setAdapter($dbAdapter);
// Validation is then performed as usual
if ($validator->isValid($username)) {
// username appears to be valid
} else {
// username is invalid; print the reason
$messages = $validator->getMessages();
foreach ($messages as $message) {
echo "$message\n";
}
}
The above example will check the 'users' table to ensure that only a record with both the username ``$username``
and with the email ``$email`` is valid.
|
Digits¶
Zend\Validator\Digits
validates if a given value contains only digits.
Supported options for Zend\Validator\Digits¶
There are no additional options for Zend\Validator\Digits
:
Validating digits¶
To validate if a given value contains only digits and no other characters, simply call the validator like shown in this example:
1 2 3 4 5 | $validator = new Zend\Validator\Digits();
$validator->isValid("1234567890"); // returns true
$validator->isValid(1234); // returns true
$validator->isValid('1a234'); // returns false
|
Note
Validating numbers
When you want to validate numbers or numeric values, be aware that this validator only validates digits. This
means that any other sign like a thousand separator or a comma will not pass this validator. In this case you
should use Zend\I18n\Validator\Int
or Zend\I18n\Validator\Float
.
EmailAddress¶
Zend\Validator\EmailAddress
allows you to validate an email address. The validator first splits the email
address on local-part @ hostname and attempts to match these against known specifications for email addresses and
hostnames.
Basic usage¶
A basic example of usage is below:
1 2 3 4 5 6 7 8 9 | $validator = new Zend\Validator\EmailAddress();
if ($validator->isValid($email)) {
// email appears to be valid
} else {
// email is invalid; print the reasons
foreach ($validator->getMessages() as $message) {
echo "$message\n";
}
}
|
This will match the email address $email
and on failure populate getMessages()
with useful error messages.
Options for validating Email Addresses¶
Zend\Validator\EmailAddress
supports several options which can either be set at initiation, by giving an array
with the related options, or afterwards, by using setOptions()
. The following options are supported:
- allow: Defines which type of domain names are accepted. This option is used in conjunction with the hostname
option to set the hostname validator. For more information about possible values of this option, look at
Hostname and possible
ALLOW
* constants. This option defaults toALLOW_DNS
. - deep: Defines if the servers MX records should be verified by a deep check. When this option is set to
TRUE
then additionally to MX records also the A, A6 andAAAA
records are used to verify if the server accepts emails. This option defaults toFALSE
. - domain: Defines if the domain part should be checked. When this option is set to
FALSE
, then only the local part of the email address will be checked. In this case the hostname validator will not be called. This option defaults toTRUE
. - hostname: Sets the hostname validator with which the domain part of the email address will be validated.
- mx: Defines if the MX records from the server should be detected. If this option is defined to
TRUE
then the MX records are used to verify if the server accepts emails. This option defaults toFALSE
.
1 2 | $validator = new Zend\Validator\EmailAddress();
$validator->setOptions(array('domain' => false));
|
Complex local parts¶
Zend\Validator\EmailAddress
will match any valid email address according to RFC2822. For example, valid emails
include bob@domain.com, bob+jones@domain.us, “bob@jones”@domain.com and “bob jones”@domain.com
Some obsolete email formats will not currently validate (e.g. carriage returns or a “\” character in an email address).
Validating only the local part¶
If you need Zend\Validator\EmailAddress
to check only the local part of an email address, and want to disable
validation of the hostname, you can set the domain
option to FALSE
. This forces
Zend\Validator\EmailAddress
not to validate the hostname part of the email address.
1 2 | $validator = new Zend\Validator\EmailAddress();
$validator->setOptions(array('domain' => FALSE));
|
Validating different types of hostnames¶
The hostname part of an email address is validated against Zend\Validator\Hostname. By default only DNS hostnames of the form domain.com
are accepted, though if
you wish you can accept IP addresses and Local hostnames too.
To do this you need to instantiate Zend\Validator\EmailAddress
passing a parameter to indicate the type of
hostnames you want to accept. More details are included in Zend\Validator\Hostname
, though an example of how to
accept both DNS and Local hostnames appears below:
1 2 3 4 5 6 7 8 9 10 11 | $validator = new Zend\Validator\EmailAddress(
Zend\Validator\Hostname::ALLOW_DNS |
Zend\Validator\Hostname::ALLOW_LOCAL);
if ($validator->isValid($email)) {
// email appears to be valid
} else {
// email is invalid; print the reasons
foreach ($validator->getMessages() as $message) {
echo "$message\n";
}
}
|
Checking if the hostname actually accepts email¶
Just because an email address is in the correct format, it doesn’t necessarily mean that email address actually exists. To help solve this problem, you can use MX validation to check whether an MX (email) entry exists in the DNS record for the email’s hostname. This tells you that the hostname accepts email, but doesn’t tell you the exact email address itself is valid.
MX checking is not enabled by default. To enable MX checking you can pass a second parameter to the
Zend\Validator\EmailAddress
constructor.
1 2 3 4 5 6 | $validator = new Zend\Validator\EmailAddress(
array(
'allow' => Zend\Validator\Hostname::ALLOW_DNS,
'useMxCheck' => true
)
);
|
Note
MX Check under Windows
Within Windows environments MX checking is only available when PHP 5.3 or above is used. Below PHP 5.3 MX checking will not be used even if it’s activated within the options.
Alternatively you can either pass TRUE
or FALSE
to setValidateMx()
to enable or disable MX validation.
By enabling this setting network functions will be used to check for the presence of an MX record on the hostname of the email address you wish to validate. Please be aware this will likely slow your script down.
Sometimes validation for MX records returns FALSE
, even if emails are accepted. The reason behind this
behaviour is, that servers can accept emails even if they do not provide a MX record. In this case they can provide
A, A6 or AAAA
records. To allow Zend\Validator\EmailAddress
to check also for these other records, you need
to set deep MX validation. This can be done at initiation by setting the deep
option or by using
setOptions()
.
1 2 3 4 5 6 7 | $validator = new Zend\Validator\EmailAddress(
array(
'allow' => Zend\Validator\Hostname::ALLOW_DNS,
'useMxCheck' => true,
'useDeepMxCheck' => true
)
);
|
Sometimes it can be useful to get the server’s MX information which have been used to do further processing. Simply
use getMXRecord()
after validation. This method returns the received MX record including weight and sorted by
it.
Warning
Performance warning
You should be aware that enabling MX check will slow down you script because of the used network functions. Enabling deep check will slow down your script even more as it searches the given server for 3 additional types.
Note
Disallowed IP addresses
You should note that MX validation is only accepted for external servers. When deep MX validation is enabled,
then local IP addresses like 192.168.*
or 169.254.*
are not accepted.
Validating International Domains Names¶
Zend\Validator\EmailAddress
will also match international characters that exist in some domains. This is known
as International Domain Name (IDN) support. This is enabled by default, though you can disable this by changing the
setting via the internal Zend\Validator\Hostname
object that exists within Zend\Validator\EmailAddress
.
1 | $validator->getHostnameValidator()->setValidateIdn(false);
|
More information on the usage of setValidateIdn()
appears in the Zend\Validator\Hostname
documentation.
Please note IDNs are only validated if you allow DNS hostnames to be validated.
Validating Top Level Domains¶
By default a hostname will be checked against a list of known TLDs. This is enabled by default, though you can
disable this by changing the setting via the internal Zend\Validator\Hostname
object that exists within
Zend\Validator\EmailAddress
.
1 | $validator->getHostnameValidator()->setValidateTld(false);
|
More information on the usage of setValidateTld()
appears in the Zend\Validator\Hostname
documentation.
Please note TLDs are only validated if you allow DNS hostnames to be validated.
Setting messages¶
Zend\Validator\EmailAddress
makes also use of Zend\Validator\Hostname
to check the hostname part of a given
email address. As with Zend Framework 1.10 you can simply set messages for Zend\Validator\Hostname
from within
Zend\Validator\EmailAddress
.
1 2 3 4 5 6 | $validator = new Zend\Validator\EmailAddress();
$validator->setMessages(
array(
Zend\Validator\Hostname::UNKNOWN_TLD => 'I don\'t know the TLD you gave'
)
);
|
Before Zend Framework 1.10 you had to attach the messages to your own Zend\Validator\Hostname
, and then set
this validator within Zend\Validator\EmailAddress
to get your own messages returned.
GreaterThan¶
Zend\Validator\GreaterThan
allows you to validate if a given value is greater than a minimum border value.
Note
Zend\Validator\GreaterThan supports only number validation
It should be noted that Zend\Validator\GreaterThan
supports only the validation of numbers. Strings or dates
can not be validated with this validator.
Supported options for Zend\Validator\GreaterThan¶
The following options are supported for Zend\Validator\GreaterThan
:
- inclusive: Defines if the validation is inclusive the minimum border value or exclusive. It defaults to
FALSE
. - min: Sets the minimum allowed value.
Basic usage¶
To validate if a given value is greater than a defined border simply use the following example.
1 2 3 4 | $valid = new Zend\Validator\GreaterThan(array('min' => 10));
$value = 8;
$return = $valid->isValid($value);
// returns false
|
The above example returns TRUE
for all values which are greater than 10.
Validation inclusive the border value¶
Sometimes it is useful to validate a value by including the border value. See the following example:
1 2 3 4 5 6 7 8 9 | $valid = new Zend\Validator\GreaterThan(
array(
'min' => 10,
'inclusive' => true
)
);
$value = 10;
$result = $valid->isValid($value);
// returns true
|
The example is almost equal to our first example but we included the border value. Now the value ‘10’ is allowed
and will return TRUE
.
Hex¶
Zend\Validator\Hex
allows you to validate if a given value contains only hexadecimal characters. These are all
characters from 0 to 9 and A to F case insensitive. There is no length limitation for the input you want to
validate.
1 2 3 4 5 6 | $validator = new Zend\Validator\Hex();
if ($validator->isValid('123ABC')) {
// value contains only hex chars
} else {
// false
}
|
Note
Invalid characters
All other characters will return false, including whitespace and decimal point. Also unicode zeros and numbers from other scripts than latin will not be treated as valid.
Supported options for Zend\Validator\Hex¶
There are no additional options for Zend\Validator\Hex
:
Hostname¶
Zend\Validator\Hostname
allows you to validate a hostname against a set of known specifications. It is possible
to check for three different types of hostnames: a DNS Hostname (i.e. domain.com
), IP address (i.e. 1.2.3.4),
and Local hostnames (i.e. localhost). By default only DNS hostnames are matched.
Supported options for Zend\Validator\Hostname¶
The following options are supported for Zend\Validator\Hostname
:
- allow: Defines the sort of hostname which is allowed to be used. See Hostname types for details.
- idn: Defines if IDN domains are allowed or not. This option defaults to
TRUE
. - ip: Allows to define a own IP validator. This option defaults to a new instance of
Zend\Validator\Ip
. - tld: Defines if TLDs are validated. This option defaults to
TRUE
.
Basic usage¶
A basic example of usage is below:
1 2 3 4 5 6 7 8 9 | $validator = new Zend\Validator\Hostname();
if ($validator->isValid($hostname)) {
// hostname appears to be valid
} else {
// hostname is invalid; print the reasons
foreach ($validator->getMessages() as $message) {
echo "$message\n";
}
}
|
This will match the hostname $hostname
and on failure populate getMessages()
with useful error messages.
Validating different types of hostnames¶
You may find you also want to match IP addresses, Local hostnames, or a combination of all allowed types. This can
be done by passing a parameter to Zend\Validator\Hostname
when you instantiate it. The parameter should be an
integer which determines what types of hostnames are allowed. You are encouraged to use the
Zend\Validator\Hostname
constants to do this.
The Zend\Validator\Hostname
constants are: ALLOW_DNS
to allow only DNS hostnames, ALLOW_IP
to allow
IP addresses, ALLOW_LOCAL
to allow local network names, ALLOW_URI
to allow RFC3986-compliant addresses,
and ALLOW_ALL
to allow all four above types.
Note
Additional Information on ALLOW_URI
ALLOW_URI
allows to check hostnames according to RFC3986. These are registered names which are used by
WINS, NetInfo and also local hostnames like those defined within your .hosts
file.
To just check for IP addresses you can use the example below:
1 2 3 4 5 6 7 8 9 | $validator = new Zend\Validator\Hostname(Zend\Validator\Hostname::ALLOW_IP);
if ($validator->isValid($hostname)) {
// hostname appears to be valid
} else {
// hostname is invalid; print the reasons
foreach ($validator->getMessages() as $message) {
echo "$message\n";
}
}
|
As well as using ALLOW_ALL
to accept all common hostnames types you can combine these types to allow for
combinations. For example, to accept DNS and Local hostnames instantiate your Zend\Validator\Hostname
class
as so:
1 2 | $validator = new Zend\Validator\Hostname(Zend\Validator\Hostname::ALLOW_DNS |
Zend\Validator\Hostname::ALLOW_IP);
|
Validating International Domains Names¶
Some Country Code Top Level Domains (ccTLDs), such as ‘de’ (Germany), support international characters in domain
names. These are known as International Domain Names (IDN). These domains can be matched by
Zend\Validator\Hostname
via extended characters that are used in the validation process.
Note
IDN domains
Until now more than 50 ccTLDs support IDN domains.
To match an IDN domain it’s as simple as just using the standard Hostname validator since IDN matching is
enabled by default. If you wish to disable IDN validation this can be done by either passing a parameter to the
Zend\Validator\Hostname
constructor or via the setValidateIdn()
method.
You can disable IDN validation by passing a second parameter to the Zend\Validator\Hostname
constructor in
the following way.
1 2 3 4 5 6 7 | $validator =
new Zend\Validator\Hostname(
array(
'allow' => Zend\Validator\Hostname::ALLOW_DNS,
'useIdnCheck' => false
)
);
|
Alternatively you can either pass TRUE
or FALSE
to setValidateIdn()
to enable or disable IDN
validation. If you are trying to match an IDN hostname which isn’t currently supported it is likely it will fail
validation if it has any international characters in it. Where a ccTLD file doesn’t exist in
Zend/Validator/Hostname
specifying the additional characters a normal hostname validation is performed.
Note
IDN validation
Please note that IDNs are only validated if you allow DNS hostnames to be validated.
Validating Top Level Domains¶
By default a hostname will be checked against a list of known TLDs. If this functionality is not required it
can be disabled in much the same way as disabling IDN support. You can disable TLD validation by passing a
third parameter to the Zend\Validator\Hostname
constructor. In the example below we are supporting IDN
validation via the second parameter.
1 2 3 4 5 6 7 8 | $validator =
new Zend\Validator\Hostname(
array(
'allow' => Zend\Validator\Hostname::ALLOW_DNS,
'useIdnCheck' => true,
'useTldCheck' => false
)
);
|
Alternatively you can either pass TRUE
or FALSE
to setValidateTld()
to enable or disable TLD
validation.
Note
TLD validation
Please note TLDs are only validated if you allow DNS hostnames to be validated.
Iban¶
Zend\Validator\Iban
validates if a given value could be a IBAN number. IBAN is the abbreviation for
“International Bank Account Number”.
Supported options for Zend\Validator\Iban¶
The following options are supported for Zend\Validator\Iban
:
- country_code: Sets the country code which is used to get the IBAN format for validation.
IBAN validation¶
IBAN numbers are always related to a country. This means that different countries use different formats for their
IBAN numbers. This is the reason why IBAN numbers always need a country code. By knowing this we already know how to
use Zend\Validator\Iban
.
Ungreedy IBAN validation¶
Sometime it is useful, just to validate if the given value is a IBAN number or not. This means that you don’t
want to validate it against a defined country. This can be done by using a FALSE
as locale.
1 2 3 4 5 6 7 8 | $validator = new Zend\Validator\Iban(array('country_code' => false));
// Note: you can also set a FALSE as single parameter
if ($validator->isValid('AT611904300234573201')) {
// IBAN appears to be valid
} else {
// IBAN is not valid
}
|
So any IBAN number will be valid. Note that this should not be done when you accept only accounts from a single country.
Region aware IBAN validation¶
To validate against a defined country, you just need to give the wished country code. You can do this by the option
country_code
and also afterwards by using setCountryCode()
.
1 2 3 4 5 6 7 | $validator = new Zend\Validator\Iban(array('country_code' => 'AT'));
if ($validator->isValid('AT611904300234573201')) {
// IBAN appears to be valid
} else {
// IBAN is not valid
}
|
Identical¶
Zend\Validator\Identical
allows you to validate if a given value is identical with a set token.
Supported options for Zend\Validator\Identical¶
The following options are supported for Zend\Validator\Identical
:
- strict: Defines if the validation should be done strict. The default value is
TRUE
. - token: Sets the token with which the input will be validated against.
- literal: If set to
TRUE
, the validation will skip the lookup for elements in the form context, and validate the token just the way it was provided. The default value isFALSE
.
Basic usage¶
To validate if two values are identical you need to set the origin value as the token. See the following example which validates a string against the given token.
1 2 3 4 | $valid = new Zend\Validator\Identical('origin');
if ($valid->isValid($value)) {
return true;
}
|
The validation will only then return TRUE
when both values are 100% identical. In our example, when $value
is ‘origin’.
You can set the wished token also afterwards by using the method setToken()
and getToken()
to get the
actual set token.
Identical objects¶
Of course Zend\Validator\Identical
can not only validate strings, but also any other variable type like
Boolean, Integer, Float, Array or even Objects. As already noted Token and Value must be identical.
1 2 3 4 5 6 | $valid = new Zend\Validator\Identical(123);
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
Note
Type comparison
You should be aware that also the type of a variable is used for validation. This means that the string ‘3’
is not identical with the integer 3. When you want such a non strict validation you must set the strict
option to false
.
Form elements¶
Zend\Validator\Identical
supports also the comparison of form elements. This can be done by using the element’s
name as token
. See the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | $form->add(array(
'name' => 'elementOne',
'type' => 'Password',
));
$form->add(array(
'name' => 'elementTwo',
'type' => 'Password',
'validators' => array(
array(
'name' => 'Identical',
'options' => array(
'token' => 'elementOne',
),
),
),
));
|
By using the elements name from the first element as token
for the second element, the validator validates if
the second element is equal with the first element. In the case your user does not enter two identical values, you
will get a validation error.
Validating a Value From a Fieldset¶
Sometimes you will need to validate an input that lives inside a fieldset, and this can be accomplished, see the following example.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 | use Zend\Form\Element;
use Zend\Form\Fieldset;
use Zend\Form\Form;
use Zend\InputFilter\Input;
use Zend\InputFilter\InputFilter;
$userFieldset = new Fieldset('user'); // (1)
$userFieldset->add(array(
'name' => 'email', // (2)
'type' => 'Email',
));
// Let's add one fieldset inside the 'user' fieldset,
// so we can see how to manage the token in a different deepness
$deeperFieldset = new Fieldset('deeperFieldset'); // (3)
$deeperFieldset->add(array(
'name' => 'deeperFieldsetInput', // (4)
'type' => 'Text',
'options' => array(
'label' => 'What validator are we testing?',
),
));
$userFieldset->add($deeperFieldset);
$signUpForm = new Form('signUp');
$signUpForm->add($userFieldset);
// Add an input that will validate the 'email' input from 'user' fieldset
$signUpForm->add(array(
'name' => 'confirmEmail', // (5)
'type' => 'Email',
));
// Add an input that will validate the 'deeperFieldsetInput' from 'deeperFieldset'
// that lives inside the 'user' fieldset
$signUpForm->add(array(
'name' => 'confirmTestingValidator', // (6)
'type' => 'Text',
));
$inputFilter = new InputFilter();
// This will ensure the user enter the same email in 'email' (2) and 'confirmEmail' (5)
$inputFilter->add(array(
'name' => 'confirmEmail', // references (5)
'validators' => array(
array(
'name' => 'Identical',
'options' => array(
// 'user' key references 'user' fieldset (1), and 'email' references 'email' element inside
// 'user' fieldset (2)
'token' => array('user' => 'email'),
),
),
),
));
// This will ensure the user enter the same string in 'deeperFieldsetInput' (4)
// and 'confirmTestingValidator' (6)
$inputFilter->add(array(
'name' => 'confirmTestingValidator', // references (6)
'validators' => array(
array(
'name' => 'Identical',
'options' => array(
'token' => array(
'user' => array( // references 'user' fieldset (1)
// 'deeperFieldset' key references 'deeperFieldset' fieldset (3)
// 'deeperFieldsetInput' references 'deeperFieldsetInput' element (4)
'deeperFieldset' => 'deeperFieldsetInput'
)
),
),
),
),
));
$signUpForm->setInputFilter($inputFilter);
|
Note
Aways make sure that your token array have just one key per level all the way till the leaf, otherwise you can end up with unexpected results.
Strict validation¶
As mentioned before Zend\Validator\Identical
validates tokens strict. You can change this behaviour by using
the strict
option. The default value for this property is TRUE
.
1 2 3 4 5 6 7 | $valid = new Zend\Validator\Identical(array('token' => 123, 'strict' => FALSE));
$input = '123';
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
The difference to the previous example is that the validation returns in this case TRUE
, even if you compare a
integer with string value as long as the content is identical but not the type.
For convenience you can also use setStrict()
and getStrict()
.
Configuration¶
As all other validators, Zend\Validator\Identical
also supports the usage of configuration settings as input
parameter. This means that you can configure this validator with a Traversable
object.
There is a case which you should be aware of. If you are using an array as token, and it contains a 'token'
key, you should wrap it within another 'token'
key. See the examples below to undestand this situation.
1 2 3 4 5 6 7 | // This will not validate array('token' => 123), it will actually validate the integer 123
$valid = new Zend\Validator\Identical(array('token' => 123));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
The reason for this special case is that you can configure the token which has to be used by giving the 'token'
key.
So, when you are using an array as token, and it contains one element with a 'token'
key, then you have to wrap
it like shown in the example below.
1 2 3 4 5 6 7 | // Unlike the previous example, this will validate array('token' => 123)
$valid = new Zend\Validator\Identical(array('token' => array('token' => 123)));
if ($valid->isValid($input)) {
// input appears to be valid
} else {
// input is invalid
}
|
If the array you are willing to validate does not have a 'token'
key, you do not need to wrap it.
InArray¶
Zend\Validator\InArray
allows you to validate if a given value is contained within an array. It is also able to validate multidimensional arrays.
Supported options for Zend\Validator\InArray¶
The following options are supported for Zend\Validator\InArray
:
haystack: Sets the haystack for the validation.
recursive: Defines if the validation should be done recursive. This option defaults to
FALSE
.strict: Three modes of comparison are offered owing to an often overlooked, and potentially dangerous security issue when validating string input from user input.
InArray::COMPARE_STRICT
This is a normal in_array strict comparison that checks value and type.
InArray::COMPARE_NOT_STRICT
This is a normal in_array non-strict comparison that checks value only.
Warning
This mode may give false positives when strings are compared against ints or floats owing to in_array’s behaviour of converting strings to int in such cases. Therefore, “foo” would become 0, “43foo” would become 43, while “foo43” would also become 0.
InArray::COMPARE_NOT_STRICT_AND_PREVENT_STR_TO_INT_VULNERABILITY
To remedy the above warning, this mode offers a middle-ground which allows string representations of numbers to be successfully matched against either their string or int counterpart and vice versa. For example: “0” will successfully match against 0, but “foo” would not match against 0 as would be true in the
*COMPARE_NOT_STRICT*
mode. This is the safest option to use when validating web input, and is the default.
Defines if the validation should be done strict. This option defaults to FALSE
.
Simple array validation¶
The simplest way, is just to give the array which should be searched against at initiation:
1 2 3 4 5 6 | $validator = new Zend\Validator\InArray(array('haystack' => array('value1', 'value2',...'valueN')));
if ($validator->isValid('value')) {
// value found
} else {
// no value found
}
|
This will behave exactly like PHP‘s in_array()
method.
Note
Per default this validation is not strict nor can it validate multidimensional arrays.
Alternatively, you can define the array to validate against after object construction by using the setHaystack()
method.
getHaystack()
returns the actual set haystack array.
1 2 3 4 5 6 7 8 | $validator = new Zend\Validator\InArray();
$validator->setHaystack(array('value1', 'value2',...'valueN'));
if ($validator->isValid('value')) {
// value found
} else {
// no value found
}
|
Array validation modes¶
As previously mentioned, there are possible security issues when using the default non-strict comparison mode, so rather than restricting the developer, we’ve chosen to offer both strict and non-strict comparisons and adding a safer middle-ground.
It’s possible to set the strict mode at initialisation and afterwards with the setStrict
method. InArray::COMPARE_STRICT
equates to true
and InArray::COMPARE_NOT_STRICT_AND_PREVENT_STR_TO_INT_VULNERABILITY
equates to false.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | // defaults to InArray::COMPARE_NOT_STRICT_AND_PREVENT_STR_TO_INT_VULNERABILITY
$validator = new Zend\Validator\InArray(
array(
'haystack' => array('value1', 'value2',...'valueN'),
)
);
// set strict mode
$validator = new Zend\Validator\InArray(
array(
'haystack' => array('value1', 'value2',...'valueN'),
'strict' => InArray::COMPARE_STRICT // equates to ``true``
)
);
// set non-strict mode
$validator = new Zend\Validator\InArray(
array(
'haystack' => array('value1', 'value2',...'valueN'),
'strict' => InArray:COMPARE_NOT_STRICT // equates to ``false``
)
);
// or
$validator->setStrict(InArray::COMPARE_STRICT);
$validator->setStrict(InArray::COMPARE_NOT_STRICT);
$validator->setStrict(InArray::COMPARE_NOT_STRICT_AND_PREVENT_STR_TO_INT_VULNERABILITY);
|
Note
Note that the strict setting is per default FALSE
.
Recursive array validation¶
In addition to PHP‘s in_array()
method this validator can also be used to validate multidimensional arrays.
To validate multidimensional arrays you have to set the recursive option.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | $validator = new Zend\Validator\InArray(
array(
'haystack' => array(
'firstDimension' => array('value1', 'value2',...'valueN'),
'secondDimension' => array('foo1', 'foo2',...'fooN')),
'recursive' => true
)
);
if ($validator->isValid('value')) {
// value found
} else {
// no value found
}
|
Your array will then be validated recursively to see if the given value is contained. Additionally you could use
setRecursive()
to set this option afterwards and getRecursive()
to retrieve it.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | $validator = new Zend\Validator\InArray(
array(
'firstDimension' => array('value1', 'value2',...'valueN'),
'secondDimension' => array('foo1', 'foo2',...'fooN')
)
);
$validator->setRecursive(true);
if ($validator->isValid('value')) {
// value found
} else {
// no value found
}
|
Note
Default setting for recursion
Per default the recursive validation is turned off.
Note
Option keys within the haystack
When you are using the keys ‘haystack
‘, ‘strict
‘ or ‘recursive
‘ within your haystack, then you must
wrap the haystack
key.
Ip¶
Zend\Validator\Ip
allows you to validate if a given value is an IP address. It supports the IPv4, IPv6 and
IPvFeature definitions.
Supported options for Zend\Validator\Ip¶
The following options are supported for Zend\Validator\Ip
:
- allowipv4: Defines if the validator allows IPv4 addresses. This option defaults to
TRUE
. - allowipv6: Defines if the validator allows IPv6 addresses. This option defaults to
TRUE
. - allowipvfuture: Defines if the validator allows IPvFuture addresses. This option defaults to
false
. - allowliteral: Defines if the validator allows IPv6 or IPvFuture with URI literal style (the IP surrounded by
brackets). This option defaults to
true
.
Basic usage¶
A basic example of usage is below:
1 2 3 4 5 6 | $validator = new Zend\Validator\Ip();
if ($validator->isValid($ip)) {
// ip appears to be valid
} else {
// ip is invalid; print the reasons
}
|
Note
Invalid IP addresses
Keep in mind that Zend\Validator\Ip
only validates IP addresses. Addresses like ‘mydomain.com
‘ or
‘192.168.50.1/index.html
‘ are no valid IP addresses. They are either hostnames or valid URLs but not IP
addresses.
Note
IPv6/IPvFuture validation
Zend\Validator\Ip
validates IPv6/IPvFuture addresses with regex. The reason is that the filters and methods
from PHP itself don’t follow the RFC. Many other available classes also don’t follow it.
Validate IPv4 or IPV6 alone¶
Sometimes it’s useful to validate only one of the supported formats. For example when your network only supports IPv4. In this case it would be useless to allow IPv6 within this validator.
To limit Zend\Validator\Ip
to one protocol you can set the options allowipv4
or allowipv6
to FALSE
.
You can do this either by giving the option to the constructor or by using setOptions()
afterwards.
1 2 3 4 5 6 | $validator = new Zend\Validator\Ip(array('allowipv6' => false));
if ($validator->isValid($ip)) {
// ip appears to be valid ipv4 address
} else {
// ip is no ipv4 address
}
|
Note
Default behaviour
The default behaviour which Zend\Validator\Ip
follows is to allow both standards.
Isbn¶
Zend\Validator\Isbn
allows you to validate an ISBN-10 or ISBN-13 value.
Supported options for Zend\Validator\Isbn¶
The following options are supported for Zend\Validator\Isbn
:
- separator: Defines the allowed separator for the ISBN number. It defaults to an empty string.
- type: Defines the allowed type of ISBN numbers. It defaults to
Zend\Validator\Isbn::AUTO
. For details take a look at this section.
Basic usage¶
A basic example of usage is below:
1 2 3 4 5 6 | $validator = new Zend\Validator\Isbn();
if ($validator->isValid($isbn)) {
// isbn is valid
} else {
// isbn is not valid
}
|
This will validate any ISBN-10 and ISBN-13 without separator.
Setting an explicit ISBN validation type¶
An example of an ISBN type restriction is below:
1 2 3 4 5 6 7 8 9 10 11 12 | $validator = new Zend\Validator\Isbn();
$validator->setType(Zend\Validator\Isbn::ISBN13);
// OR
$validator = new Zend\Validator\Isbn(array(
'type' => Zend\Validator\Isbn::ISBN13,
));
if ($validator->isValid($isbn)) {
// this is a valid ISBN-13 value
} else {
// this is an invalid ISBN-13 value
}
|
The above will validate only ISBN-13 values.
Valid types include:
Zend\Validator\Isbn::AUTO
(default)Zend\Validator\Isbn::ISBN10
Zend\Validator\Isbn::ISBN13
Specifying a separator restriction¶
An example of separator restriction is below:
1 2 3 4 5 6 7 8 9 10 11 12 | $validator = new Zend\Validator\Isbn();
$validator->setSeparator('-');
// OR
$validator = new Zend\Validator\Isbn(array(
'separator' => '-',
));
if ($validator->isValid($isbn)) {
// this is a valid ISBN with separator
} else {
// this is an invalid ISBN with separator
}
|
Note
Values without separator
This will return FALSE
if $isbn
doesn’t contain a separator or if it’s an invalid ISBN value.
Valid separators include:
- “” (empty) (default)
- “-” (hyphen)
- ” ” (space)
LessThan¶
Zend\Validator\LessThan
allows you to validate if a given value is less than a maximum border value.
Note
Zend\Validator\LessThan supports only number validation
It should be noted that Zend\Validator\LessThan
supports only the validation of numbers. Strings or dates
can not be validated with this validator.
Supported options for Zend\Validator\LessThan¶
The following options are supported for Zend\Validator\LessThan
:
- inclusive: Defines if the validation is inclusive the maximum border value or exclusive. It defaults to
FALSE
. - max: Sets the maximum allowed value.
Basic usage¶
To validate if a given value is less than a defined border simply use the following example.
1 2 3 4 | $valid = new Zend\Validator\LessThan(array('max' => 10));
$value = 12;
$return = $valid->isValid($value);
// returns false
|
The above example returns TRUE
for all values which are lower than 10.
Validation inclusive the border value¶
Sometimes it is useful to validate a value by including the border value. See the following example:
1 2 3 4 5 6 7 8 9 | $valid = new Zend\Validator\LessThan(
array(
'max' => 10,
'inclusive' => true
)
);
$value = 10;
$result = $valid->isValid($value);
// returns true
|
The example is almost equal to our first example but we included the border value. Now the value ‘10’ is allowed
and will return TRUE
.
NotEmpty¶
This validator allows you to validate if a given value is not empty. This is often useful when working with form elements or other user input, where you can use it to ensure required elements have values associated with them.
Supported options for Zend\Validator\NotEmpty¶
The following options are supported for Zend\Validator\NotEmpty
:
- type: Sets the type of validation which will be processed. For details take a look into this section.
Default behaviour for Zend\Validator\NotEmpty¶
By default, this validator works differently than you would expect when you’ve worked with PHP‘s empty()
function. In particular, this validator will evaluate both the integer 0 and string ‘0‘ as empty.
1 2 3 4 | $valid = new Zend\Validator\NotEmpty();
$value = '';
$result = $valid->isValid($value);
// returns false
|
Note
Default behaviour differs from PHP
Without providing configuration, Zend\Validator\NotEmpty
‘s behaviour differs from PHP.
Changing behaviour for Zend\Validator\NotEmpty¶
Some projects have differing opinions of what is considered an “empty” value: a string with only whitespace might
be considered empty, or 0 may be considered non-empty (particularly for boolean sequences). To accommodate
differing needs, Zend\Validator\NotEmpty
allows you to configure which types should be validated as empty and
which not.
The following types can be handled:
- boolean: Returns
FALSE
when the boolean value isFALSE
. - integer: Returns
FALSE
when an integer 0 value is given. Per default this validation is not activated and returnsTRUE
on any integer values. - float: Returns
FALSE
when an float 0.0 value is given. Per default this validation is not activated and returnsTRUE
on any float values. - string: Returns
FALSE
when an empty string ‘’ is given. - zero: Returns
FALSE
when the single character zero (‘0’) is given. - empty_array: Returns
FALSE
when an empty array is given. - null: Returns
FALSE
when anNULL
value is given. - php: Returns
FALSE
on the same reasons where PHP methodempty()
would returnTRUE
. - space: Returns
FALSE
when an string is given which contains only whitespaces. - object: Returns
TRUE
.FALSE
will be returned whenobject
is not allowed but an object is given. - object_string: Returns
FALSE
when an object is given and it’s__toString()
method returns an empty string. - object_count: Returns
FALSE
when an object is given, it has anCountable
interface and it’s count is 0. - all: Returns
FALSE
on all above types.
All other given values will return TRUE
per default.
There are several ways to select which of the above types are validated. You can give one or multiple types and add them, you can give an array, you can use constants, or you can give a textual string. See the following examples:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | // Returns false on 0
$validator = new Zend\Validator\NotEmpty(Zend\Validator\NotEmpty::INTEGER);
// Returns false on 0 or '0'
$validator = new Zend\Validator\NotEmpty(
Zend\Validator\NotEmpty::INTEGER + Zend\Validator\NotEmpty::ZERO
);
// Returns false on 0 or '0'
$validator = new Zend\Validator\NotEmpty(array(
Zend\Validator\NotEmpty::INTEGER,
Zend\Validator\NotEmpty::ZERO
));
// Returns false on 0 or '0'
$validator = new Zend\Validator\NotEmpty(array(
'integer',
'zero',
));
|
You can also provide an instance of Traversable
to set the desired types. To set types after instantiation, use
the setType()
method.
PostCode¶
Zend\Validator\PostCode
allows you to determine if a given value is a valid postal code. Postal codes are
specific to cities, and in some locales termed ZIP codes.
Zend\Validator\PostCode
knows more than 160 different postal code formats. To select the correct format there
are 2 ways. You can either use a fully qualified locale or you can set your own format manually.
Using a locale is more convenient as Zend Framework already knows the appropriate postal code format for each
locale; however, you need to use the fully qualified locale (one containing a region specifier) to do so. For
instance, the locale “de” is a locale but could not be used with Zend\Validator\PostCode
as it does not include
the region; “de_AT”, however, would be a valid locale, as it specifies the region code (“AT”, for Austria).
1 | $validator = new Zend\Validator\PostCode('de_AT');
|
When you don’t set a locale yourself, then Zend\Validator\PostCode
will use the application wide set locale,
or, when there is none, the locale returned by Locale
.
1 2 3 4 | // application wide locale within your bootstrap
Locale::setDefault('de_AT');
$validator = new Zend\Validator\PostCode();
|
You can also change the locale afterwards by calling setLocale()
. And of course you can get the actual used
locale by calling getLocale()
.
1 2 | $validator = new Zend\Validator\PostCode('de_AT');
$validator->setLocale('en_GB');
|
Postal code formats are simply regular expression strings. When the international postal code format, which is used
by setting the locale, does not fit your needs, then you can also manually set a format by calling setFormat()
.
1 2 | $validator = new Zend\Validator\PostCode('de_AT');
$validator->setFormat('AT-\d{5}');
|
Note
Conventions for self defined formats
When using self defined formats you should omit the starting ('/^'
) and ending tags ('$/'
). They are
attached automatically.
You should also be aware that postcode values are always be validated in a strict way. This means that they have to be written standalone without additional characters when they are not covered by the format.
Constructor options¶
At it’s most basic, you may pass a string representing a fully qualified locale to the constructor of
Zend\Validator\PostCode
.
1 2 | $validator = new Zend\Validator\PostCode('de_AT');
$validator = new Zend\Validator\PostCode($locale);
|
Additionally, you may pass either an array or a Traversable
instance to the constructor. When you do so, you
must include either the key “locale” or “format”; these will be used to set the appropriate values in the validator
object.
1 2 3 4 | $validator = new Zend\Validator\PostCode(array(
'locale' => 'de_AT',
'format' => 'AT_\d+'
));
|
Supported options for Zend\Validator\PostCode¶
The following options are supported for Zend\Validator\PostCode
:
- format: Sets a postcode format which will be used for validation of the input.
- locale: Sets a locale from which the postcode will be taken from.
Regex¶
This validator allows you to validate if a given string conforms a defined regular expression.
Supported options for Zend\Validator\Regex¶
The following options are supported for Zend\Validator\Regex
:
- pattern: Sets the regular expression pattern for this validator.
Validation with Zend\Validator\Regex¶
Validation with regular expressions allows to have complicated validations being done without writing a own validator. The usage of regular expression is quite common and simple. Let’s look at some examples:
1 2 3 4 5 | $validator = new Zend\Validator\Regex(array('pattern' => '/^Test/');
$validator->isValid("Test"); // returns true
$validator->isValid("Testing"); // returns true
$validator->isValid("Pest"); // returns false
|
As you can see, the pattern has to be given using the same syntax as for preg_match()
. For details about
regular expressions take a look into PHP’s manual about PCRE pattern syntax.
Pattern handling¶
It is also possible to set a different pattern afterwards by using setPattern()
and to get the actual set
pattern with getPattern()
.
1 2 3 4 5 6 | $validator = new Zend\Validator\Regex(array('pattern' => '/^Test/');
$validator->setPattern('ing$/');
$validator->isValid("Test"); // returns false
$validator->isValid("Testing"); // returns true
$validator->isValid("Pest"); // returns false
|
Sitemap Validators¶
The following validators conform to the Sitemap XML protocol.
Sitemap\Changefreq¶
Validates whether a string is valid for using as a ‘changefreq’ element in a Sitemap XML document. Valid values are: ‘always’, ‘hourly’, ‘daily’, ‘weekly’, ‘monthly’, ‘yearly’, or ‘never’.
Returns TRUE
if and only if the value is a string and is equal to one of the frequencies specified above.
Sitemap\Lastmod¶
Validates whether a string is valid for using as a ‘lastmod’ element in a Sitemap XML document. The lastmod element should contain a W3C date string, optionally discarding information about time.
Returns TRUE
if and only if the given value is a string and is valid according to the protocol.
Sitemap Lastmod Validator
1 2 3 4 5 6 7 8 9 10 11 12 | $validator = new Zend\Validator\Sitemap\Lastmod();
$validator->isValid('1999-11-11T22:23:52-02:00'); // true
$validator->isValid('2008-05-12T00:42:52+02:00'); // true
$validator->isValid('1999-11-11'); // true
$validator->isValid('2008-05-12'); // true
$validator->isValid('1999-11-11t22:23:52-02:00'); // false
$validator->isValid('2008-05-12T00:42:60+02:00'); // false
$validator->isValid('1999-13-11'); // false
$validator->isValid('2008-05-32'); // false
$validator->isValid('yesterday'); // false
|
Sitemap\Loc¶
Validates whether a string is valid for using as a ‘loc’ element in a Sitemap XML document. This uses
Zend\Uri\Uri::isValid()
internally. Read more at URI Validation.
Sitemap\Priority¶
Validates whether a value is valid for using as a ‘priority’ element in a Sitemap XML document. The value should be a decimal between 0.0 and 1.0. This validator accepts both numeric values and string values.
Sitemap Priority Validator
1 2 3 4 5 6 7 8 9 10 11 12 | $validator = new Zend\Validator\Sitemap\Priority();
$validator->isValid('0.1'); // true
$validator->isValid('0.789'); // true
$validator->isValid(0.8); // true
$validator->isValid(1.0); // true
$validator->isValid('1.1'); // false
$validator->isValid('-0.4'); // false
$validator->isValid(1.00001); // false
$validator->isValid(0xFF); // false
$validator->isValid('foo'); // false
|
Supported options for Zend\Validator\Sitemap_*¶
There are no supported options for any of the Sitemap validators.
Step¶
Zend\Validator\Step
allows you to validate if a given value is a valid step value. This validator requires the
value to be a numeric value (either string, int or float).
Supported options for Zend\Validator\Step¶
The following options are supported for Zend\Validator\Step
:
- baseValue: This is the base value from which the step should be computed. This option defaults to
0
- step: This is the step value. This option defaults to
1
Basic usage¶
A basic example is the following one:
1 2 3 4 5 6 | $validator = new Zend\Validator\Step();
if ($validator->isValid(1)) {
// value is a valid step value
} else {
// false
}
|
Using floating-point values¶
This validator also supports floating-point base value and step value. Here is a basic example of this feature:
1 2 3 4 5 6 7 8 9 | $validator = new Zend\Validator\Step(array(
'baseValue' => 1.1,
'step' => 2.2
));
echo $validator->isValid(1.1); // prints true
echo $validator->isValid(3.3); // prints true
echo $validator->isValid(3.35); // prints false
echo $validator->isValid(2.2); // prints false
|
StringLength¶
This validator allows you to validate if a given string is between a defined length.
Note
Zend\Validator\StringLength supports only string validation
It should be noted that Zend\Validator\StringLength
supports only the validation of strings. Integers,
floats, dates or objects can not be validated with this validator.
Supported options for Zend\Validator\StringLength¶
The following options are supported for Zend\Validator\StringLength
:
- encoding: Sets the
ICONV
encoding which has to be used for this string. - min: Sets the minimum allowed length for a string.
- max: Sets the maximum allowed length for a string.
Default behaviour for Zend\Validator\StringLength¶
Per default this validator checks if a value is between min
and max
. But for min
the default value is
0 and for max
it is NULL which means unlimited.
So per default, without giving any options, this validator only checks if the input is a string.
Limiting the maximum allowed length of a string¶
To limit the maximum allowed length of a string you need to set the max
property. It accepts an integer value
as input.
1 2 3 4 | $validator = new Zend\Validator\StringLength(array('max' => 6));
$validator->isValid("Test"); // returns true
$validator->isValid("Testing"); // returns false
|
You can set the maximum allowed length also afterwards by using the setMax()
method. And getMax()
to
retrieve the actual maximum border.
1 2 3 4 5 | $validator = new Zend\Validator\StringLength();
$validator->setMax(6);
$validator->isValid("Test"); // returns true
$validator->isValid("Testing"); // returns false
|
Limiting the minimal required length of a string¶
To limit the minimal required length of a string you need to set the min
property. It accepts also an integer
value as input.
1 2 3 4 | $validator = new Zend\Validator\StringLength(array('min' => 5));
$validator->isValid("Test"); // returns false
$validator->isValid("Testing"); // returns true
|
You can set the minimal requested length also afterwards by using the setMin()
method. And getMin()
to
retrieve the actual minimum border.
1 2 3 4 5 | $validator = new Zend\Validator\StringLength();
$validator->setMin(5);
$validator->isValid("Test"); // returns false
$validator->isValid("Testing"); // returns true
|
Limiting a string on both sides¶
Sometimes it is required to get a string which has a maximal defined length but which is also minimal chars long. For example when you have a textbox where a user can enter his name, then you may want to limit the name to maximum 30 chars but want to get sure that he entered his name. So you limit the minimum required length to 3 chars. See the following example:
1 2 3 4 5 | $validator = new Zend\Validator\StringLength(array('min' => 3, 'max' => 30));
$validator->isValid("."); // returns false
$validator->isValid("Test"); // returns true
$validator->isValid("Testing"); // returns true
|
Note
Setting a lower maximum border than the minimum border
When you try to set a lower maximum value as the actual minimum value, or a higher minimum value as the actual maximum value, then an exception will be raised.
Encoding of values¶
Strings are always using a encoding. Even when you don’t set the encoding explicit, PHP uses one. When your application is using a different encoding than PHP itself then you should set an encoding yourself.
You can set your own encoding at initiation with the encoding
option, or by using the setEncoding()
method.
We assume that your installation uses ISO and your application it set to ISO. In this case you will see the
below behaviour.
1 2 3 4 5 6 7 8 9 10 11 12 | $validator = new Zend\Validator\StringLength(
array('min' => 6)
);
$validator->isValid("Ärger"); // returns false
$validator->setEncoding("UTF-8");
$validator->isValid("Ärger"); // returns true
$validator2 = new Zend\Validator\StringLength(
array('min' => 6, 'encoding' => 'UTF-8')
);
$validator2->isValid("Ärger"); // returns true
|
So when your installation and your application are using different encodings, then you should always set an encoding yourself.