Just wondering if anyone could assist (please).
The problem i most see is the user enters a phone number and it is either missing a digit or has an extra digit
I would like to limit and check the length of the predefined regx validator for a phone number.

it appears that any length is valid by using the predefined phone number validator

- i know that i can select the predifined regx phone number validator
- i know that if i them select custom i can then modify the predefined phone number validator

but what is the easiest way to check that there is only 11 digits, constructing 11 [0-9] 's would be easiest but i am guessing not the most efficient - sorry regx is something that i have limited knowledge in

Thanks in Advance

RegEx is not easy.


And phone format also.
It depends if you want an international format, or specific.

Cook do not provide a lot of them.

I can only advice you this good regex library :
regexlib.com/

Hi @BTB3000,

You can simply limit the length usingalthough, telephone numbers are some of the trickiest things to validate properly...

Lots of questions like, do you want to support;

1. international prefixes (with and/or without parentheses)
2. Geographic area codes (with and/or without parentheses)
3. Non-geographic prefixes - 0800/800/1800 depending on which country (again with and/or without parentheses)
4. Mobiles

???

These are just some too... It really is a mine field... Especially here in the UK where there are many combinations of old and new 'standards'.

RegexLib is a very good source of help but only if there is a valid regex for the territory your working in/for...

I use this basic one for UK telephone numbers but it's not perfect...but it will allow you to put in numbers that technically don't exist. What I mean is, say in a regional code area of 01234 there aren't actually numbers beginning with 7, this particular regex will validate it as long as it meets the formatting/length specifications.

To validate UK telephone numbers 'properly', it's a 4-stage procecss with much larger, more complicated expressions to test for every real phone number, formatting pattern and so on...

Anyway, hope this gets you started!

Gez

audibleid wrote: Many of the patterns on RegExLib are badly coded and inefficient. You should not blindly cut and paste any code but should strive to fully understand it, test it (both with valid and non-valid numbers) and improve it.
audibleid wrote: If you want very detailed patterns for extracting, validating and formatting UK telephone numbers you should look here: www.aa-asterisk.org.uk/index.php/Regular...GB_Telephone_Numbers
The data is fully up to date as of November 2012.

@g1smd,

To be frank, I don't like the critical tone of your post. It is completely unfounded and taken completely out of the context of this thread: ORIGINAL TOPIC - Limiting the length of regx phone number.
Ironically, you've not explained anything to do with the expression that has clearly offended you so much, nor have you improved it. Instead, you've posted a link and quite a curt message.

Furthermore, I'd previously found the page that you linked to via a series of 4 regex's on regexlib that I believe that you wrote(???) - I referred to this here in my original post:audibleid wrote: .

To clarify, I was not suggesting that users paste Regex's blindly having copied them from there (or anywhere else), merely that in my experience, it's been a good resource. There are ratings on the expressions which are helpful in discerning whether or not they are likely to be useful or even work.

Like anything you find on the internet, some (or a lot) of research will be needed as - let's face it - any idiot can post opinions, code or whatever... It's up to everyone who 'consumes' that information to further read around it to gain more insight and experience in applying it.

I'm no expert at any of this stuff, especially regex. I just post things within the scope of my ever expanding knowledge from reading, testing and testing some more, in the hope that it is useful to someone. You'll also note that I've posted a number of regex's with quite detailed explanations of what each part of the expression is doing in layman's terms. Again, let me re-iterate, I am no expert.

I think the other important thing to note about validation of any sort is that, different developers/clients have completely different needs. This is why I explained the scope of the regex that I provided... It suits my needs perfectly as I'm not really interested in validating to the nth degree as my telephone numbers come from trusted sources and are not user entered in this case.

You clearly have skills in regex validation so please, If you find anything in those posts (or any others) that you can improve , further explain or expand upon (which I'm sure you can), please feel free to post a reply in the relevant thread.

Kind Regards

Gez

g1smd wrote:
Interesting and useful article, thanks.

@audibleid Sorry if you took offense at any of my remarks. None was intended. None whatsoever. When I say "you" I am not addressing "you" personally, but all future readers of this thread. I write a lot of stuff and I guess the style is probably at the terse end of things. I have commented on many of the RegEx patterns over at RegEx library and have offered to moderate over there to weed out the worst of the flagrently incorrect stuff. I am quite happy to help you improve your RegEx patterns here, so I'll look back from time to time with that in mind. I wasn't aware that you'd already referred to the stuff I wrote earlier. I'll take a look at the earlier posts in the thread.

This allows 0 to 5 digits, an optional space, 0 to 6 digits.

As each part can have 0 length, this accepts blank input!

The [ ]{0,1} simplifies to \s? here.

The pattern will not match UK 2+8 or 3+7 format numbers but will match numbers with missing digits.

Off the top of my head, a simple pattern such as
will allow only the correct number of digits while being flexible with punctuation.

The pattern matches optional opening parentheses, literal 0, two digits (the shortest area code), followed by 7 or 8 groups that can consist of "optional closing parentheses, and optional space or hyphen, and mandatory digit".

This allows 020 3555 7788, (020) 3555 7888, and 016977 3555, (016977) 3555 etc.

It also allows for people to write their number in the wrong format and still be accepted, e.g. 02035 557 788 and this is a good thing.

It also allows stuff like (01750) 3) 4) 5) 6) 7) 8 but that's not much of an issue as the number does contain the right number of digits.

It's the digits that are the important thing.

The spaces and punctuation should be dumped before validating the number is in a valid range, stored only as unformatted digits with country code, e.g. 441750345678, and reformatted as +44 1750 345678 or as (01750) 345678 for display.

Modifying that RegEx to also allow +44, with optional parentheses and spaces, in place of 0 yields this:
If you want to also allow 00 44 and 011 44, with optional parentheses and spaces, then it becomes:
The (01750) 3) 4) 5) 6) 7) 8 problem is partially solved using:orlimiting the optional closing brackets to only after the 2nd to 5th digits of the NSN.


The big problem with GB numbers is that the area code length varies from 2 to 5 digits around the country, and the subscriber number can be 8, 7, 6, 5, or 4 digits for a total length of 9 or 10 digits (not including the 0 trunk code). There's a LOT of history as to how it came to be this way.

The valid combinations are 2+8 (in 5 areas), 3+7 (in 12 areas), 3+6 (all 0500 and some 0800 numbers), 4+6 (in ~480 areas), 4+5 (in 40 areas: these 40 areas have a mix of 4+6 and 4+5 numbers), 5+5 (in 12 areas), 5+4 (in one area, and this area has a mix of 5+5 and 5+4 numbers).

Someone else has explained it far better over here:
www.aa-asterisk.org.uk/index.php/Number_format
www.aa-asterisk.org.uk/index.php/01_numbers
www.aa-asterisk.org.uk/index.php/Mixed_areas
www.aa-asterisk.org.uk/index.php/(0)
and other pages.

Regular expressions that attempt to validate and format in one go are doomed to failure. Splitting the task into matching and extraction, cleaning, validation and formatting makes for simpler patterns at each stage and easier management (and less bugs!).

Hi @g1smd

Thank you for clarifying that - I really appreciate it!!! Also, I apologise if my response was too strong with your clarification taken into consideration!!!

Regular Expressions are really quite complex beasts and I'm sure most of us here would appreciate any help or pointers from someone in-the-know like yourself so thank you for the kind offer!

Are you not a joomla 'COOK' yourself - I mean, aren't you using COOK to build Joomla components?

Many thanks,

Gez

My only previous work with Joomla code was re-building the htaccess file for it and looking at various additional options for including in that.

Yeah, more RegEx stuff.

_{I added more stuff to my previous post after you posted.}


I have also provided a very detailed review of one RegEx pattern picked at random from RegExLib. It can be found here: www.j-cook.pro/forum/34-regular-expressi...r-expression-library

Thanks @g1smd karma+1!

I'd be really interested to see/hear your recommendations on implementing the 4-step procedure for validating UK telephone numbers that you have written, within COOK if you ever find yourself building a joomla component here!

Presumably, it would start out by adding the first step to a custom regex in the builder, then editing the rule class for that to account for continuing through steps 2-4, right...?

Anyway, thanks for the extra info! I'm sure that will help a hell of a lot of people here, myself included!

Best wishes,

Gez

I'm not familiar with COOK but I'll have a look at it and see how it works.

Validating phone numbers isn't as simple as matching, say, email addresses.

With email addresses you're looking for characters and maybe hyphens and periods and other puncuation, then the @ sign once, then characters and periods and maybe hyphens and other characters.

With phone numbers there's a whole load of possible dial prefixes or the + sign before the country code, or the number may not have any of that and instead may just begin with a trunk code. The next part is usually the area code and number, but some countries don't use area codes. There may be various punctuation in and around the various parts, and each of the various parts can be different lengths: country code is 1 to 3 digits, area code 0 to 6 digits and number from 3 to 12 digits for a total of less than 15 digits.

There might be an unwanted (0) after the country code and before the area code that will have to be dumped. It's a headache.

The only bits you are interested in are the country code and the NSN (national signicant number). The rest can be dumped. Once you have the NSN, that is the only part that gets validated.

Storage is usually done with country and NSN together, in E.164 format.

When you want to show the number on screen, a whole separate load of rules come into play to format it in the right way. That's a simple job for the US and Canada, relatively simple for France and Spain, and much more complicated for the UK and Germany.

Don't worry audibleid, you are doing a good job. A moderator must be able to react when it is necessary. You are doing both amazing help, and forum management. Thank you.
It hapened to me as well to overload of myself sometimes. The most important is to go forward and to continue on a positive and contructing way.

Thank you g1smd for the very usefull link.