Geoff Berrow wrote:
> On Tue, 20 Jul 2010 22:47:18 +1000, "rf" <rf@z.invalid> wrote:
>
>>> Same with (UK) postcodes. And addresses
>> Indeed.
>>
>>
>> I was skiing in California a few years ago. To obtain a lift ticket one was
>> required to fill in a survey form on some computers over in the corner. One
>> of the questions was "where do you live".
>>
>> The author of the (intranet but web based) survey form made the mission
>> critical error of deciding that the "zip code" needed to be valid to make
>> sure their demographics were not "tainted with invalid data".
>>
>> Well over here in .au we don't have zip codes, we have postcodes, four
>> digits long. Not five. This stupidly designed Californian system simply
>> would not let me proceed untill I had entered a valid AMERICAN five digit
>> zip code, and not just five random numbers but a *valid* US zip code, even
>> though I live in Australia.
>
> And in Eire they don't have postcodes at all. I've often had to point
> this out to people who thought that the postcode/zip code field should
> be mandatory.

I had an irish customer who filled it in tho. at least there was a 5
digit number in the address.

On Jul 20, 1:20pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
> rf wrote:
> > "The Natural Philosopher" <t...@invalid.invalid> wrote in message
> >news:i24299$jk6$3@news.albasani.net...
> >> rf wrote:
> >>> "MG" <nos...@nospam.com> wrote in message
> >>>news:i23pgl$6md$1@news.eternal-september.org...
> >>>> I am a newby just starting out with PHP.
>
> >>>> I am having difficulty validating a phone number. Let's say the phone
> >>>> number is entered like this:
> >>>> (011) 123-4567 Ext 1234
>
> >>>> I want to validate it by counting the number of digits.
> >>> What would the number of digits in a phone number have to do with its
> >>> validity?
>
> >> Only way to validate a phone number is to dial it.
>
> >> Or create a database of all the phone numbers in the world
>
> > Yes. But that'd be a real bitch to maintain :-)
>
> exactly.
>
> I gave up even trying to validate.
>
> Same with (UK) postcodes. And addresses
>
> I simply enter em in google, and if it finds (a house for sale on their
> street) then I know its valid!
>
> And usually get the CORRECT POSTAL address as well. Its amazing how many
> people cant spell their own addresses.

I think you're missing the distinction between validation and
verification. Validation needs to only ensure that some data is in
the correct format, for example a string of digits between 8 and 12
digits long. This doesn't mean that it's a real phone number, but it
does mean that it is in a format that approximates one.

Verification is taking the data and performing some more rigorous test
on it, such as looking it up in the phone book. As looking the
entered number up is more expensive in terms of work (you'll have to
connect to a database or flip through a phone book) and possibly money
(there are databases of UK post codes for example, but doing a lookup
costs money) it is worthwhile to filter out data that is obviously not
correct.

Therefore validation is still worth doing, even if it doesn't
guarantee that users will enter real phone numbers. And lets not
forget the need to protect your application from abusive input such as
SQL injection attempts!

"rf" <rf@z.invalid> wrote in message
news:Hug1o.1269$Yv.773@viwinnwfe01.internal.bigpon d.com...
> I can only speak for Australia but here all regular *land line* phone
> numbers have 8 digits, except if one is calling said number from
> interstate when it will have 10 digits, and also except when one is
> calling said number from overseas where the number will have 11 digits,
> unless one includes the international "get out of the country" access code
> which may add two or three or more extra numbers, but that is not part of
> the number anyway (even though the OP indicates it is, by providing an
> example which includes '(011)').

> I'm still waiting for MG to relate the correlation between the number of
> digits in a phone number and its validitiy. IMHO its like counting the
> number of characters in an email address.

In South Africa, both landlines and mobile numbers are 10 digits long. 011
is the landline code for Johannesburg.

For this project I will only be dealing with Johannesburg and surrounding
areas, so a 10 digit validation will be just fine.

MG

On 20/07/10 13:18, rf wrote:

> unless one includes the
> international "get out of the country" access code which may add two or
> three or more extra numbers, but that is not part of the number anyway (even
> though the OP indicates it is, by providing an example which includes
> '(011)').

011 is not the "international call" prefix everywhere. The number
supplied by the OP may have been in the format:

(area code) local-number

Rgds

Denis McMahon

On Tue, 20 Jul 2010 17:12:26 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:

>> And in Eire they don't have postcodes at all. I've often had to point
>> this out to people who thought that the postcode/zip code field should
>> be mandatory.
>
>I had an irish customer who filled it in tho. at least there was a 5
>digit number in the address.

Prolly made it up to get round the validator :-}

http://www.lookintoireland.com/mail.htm
--
Geoff Berrow (Put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs www.4theweb.co.uk/rfdmaker

El 20/07/2010 14:58, rf escribió/wrote:
>> > According to your previous explanation, a 7-digit Australian phone number
>> > is wrong.
> Yes, at the moment there are no 7 digit phone numbers. There used to be last
> century before they changed things.
>
> But so? My phone number is somewhere between 8 and 11 digits. OK, it's
> invalid if< 8 or> 11 but what if I want my "phone number" to be, as I said
> in another post: "5555 5555 and ask for Bob". That's quite valid, as far as
> I am concerned.

Yes, it is: it has eight digits and it's obvious that the user wrote a
phone number and not his e-mail address. It would pass the validation we
are talking about, as it should.

Why do you have such strong feelings about form validation? Of course we
cannot know whether the phone exists and belongs to that person but the
same happens with any other piece of data, yet no competent programmer
would accept "Yellow" for the field "Birthday". And if that's not your
concern them I'm afraid I cannot follow you.



--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

""Álvaro G. Vicario"" <alvaro.NOSPAMTHANX@demogracia.com.invalid> wrote in
message news:i264tt$8ap$1@news.eternal-september.org...
> El 20/07/2010 14:58, rf escribió/wrote:
>>> > According to your previous explanation, a 7-digit Australian phone
>>> > number
>>> > is wrong.
>> Yes, at the moment there are no 7 digit phone numbers. There used to be
>> last
>> century before they changed things.
>>
>> But so? My phone number is somewhere between 8 and 11 digits. OK, it's
>> invalid if< 8 or> 11 but what if I want my "phone number" to be, as I
>> said
>> in another post: "5555 5555 and ask for Bob". That's quite valid, as far
>> as
>> I am concerned.
>
> Yes, it is: it has eight digits and it's obvious that the user wrote a
> phone number and not his e-mail address. It would pass the validation we
> are talking about, as it should.

Ok.

> Why do you have such strong feelings about form validation?

Because designers often get it just plain wrong.

Zip codes that *must* be 5 digits because that is all the designer has ever
been exposed to, like those pelicans in California whose simple mistake
totally screwed their domographics. It would be far better to accept a, say,
1% failure rate on an invalid zip/post code than disallow *everyone* who
tried to use a postcode.

Phone numbers that must be between 8 and 11 digits inclusive, but parts of
the world use 7 digits. When I was a kid my phone number had two digits in
it, plus some descriptive prose.


> Of course we cannot know whether the phone exists and belongs to that
> person

Correct.

> but the same happens with any other piece of data, yet no competent
> programmer would accept "Yellow" for the field "Birthday".

And are you going to validate a birthday why?

> And if that's not your concern them I'm afraid I cannot follow you.

My concern is over validating stuff that does not need it. A phone number is
a free form field, just like a street address. It is up to the user to enter
the correct data.

El 21/07/2010 10:23, rf escribió/wrote:
>> but the same happens with any other piece of data, yet no competent
>> programmer would accept "Yellow" for the field "Birthday".
>
> And are you going to validate a birthday why?

Mainly, because I cannot insert "Yellow" in a DATETIME column. I won't
accept user input that's going to trigger a SQL error.



--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

The Natural Philosopher a écrit ce mardi 20 juillet 2010 18:12 dans
<i24hta$a1m$2@news.albasani.net> :

> I had an irish customer who filled it in tho. at least there was a 5
> digit number in the address.

Well, I used to Live and Work in Ireland.
You just can't imagine the amount of web sites for which I (and all Irish
people who purchase on the Internet) had(have) to "invent" a random bogus
post code in order to be delivered in Ireland...
And not also to mention a few (hopefully rare) Web sites which require a
"state" field to be filled in... even though they propose world-wide
deliveries.
Looks like there's a hell of a load of web designers that have never put a
foot outside their own country and know as much about "internationalization"
as just no more than the word itself without it's meaning.


I maintain an e-commerce site, now I've seen that:

ZIP/Post-Code:
==============
Some postcodes have "letters" (not only numbers, i.e. Canada).
You should allow this field to be empty (i.e. for Ireland, but also other
countries)

Phone:
======
Phone Numbers have a variable length. You should allow the + symbol as
prefix (i.e. some people write +353 or 00353 for Ireland, they are the
"same"):
http://www.exportbureau.com/telephon..._dialcode.html
You should also allow spaces, dash ("-") and parenthesis:
"+353 (0)2 12 34 56 78" or "00353 (0)212-345-678" is far more readable and
easy to dial than 00325212345678, the (0) is because you do not dial it if
you dial the prefix (00353) otherwise you DO dial it (local phone calls),
valid for both Germany, France and Ireland i.e. but I guess many other
countries.

Email:
======
You can since recently have any type of international characters in domain
names:
http://www.icann.org/en/topics/idn/
so traditional regular expressions to validate emails will soon begin to
fail more and more often.

Address:
========
Names and Addresses "commonly" have international characters!
(IMPORTANT)
So a preg_match('/[a-z]{2,}/i', $_POST['name']) like I've already seen will
surely fail. Also some names are "composed" names (i.e. Jean-Louis) with a
"dash" between them.
Also, I had a major problem with Greek customers because our delivery
platform did not handle non-latin characters... while our site does... Same
for Russia.
Also, this case is frequent:
Some addresses hold just a village name and a post-code or county/city near-
by, no street name, (i.e. very frequent in the French Country-side) and "NO
Street Number"!.
i.e.:
Mr John Doe
A-Village
12345 Some-Region-Or-City
France

Or:
Mrs Jane Doe
Country Road
Some-City Co.Cork
Ireland


Now Incredible but TRUE:
Some (rare) people do NOT have an email (nor internet) and perform the web
purchase from an Internet café :
http://en.wikipedia.org/wiki/Internet_caf%C3%A9 or from a friends internet
connection).

Worse: some people do NOT even have a phone (Yes, this is TRUE, some people
find it incredible), so it should be allowed to be kept empty (like above
case without internet)


So what do you need to "REQUIRE" to validate in a form?

Well:
a name and address to ship a "physical" product! Post code is optional.

An email address "ONLY" for a news-letter subscription, or if the product to
deliver is i.e. a software and that you send a download link and activation
key by email.



--
Web Dreamer

El 21/07/2010 13:52, Web Dreamer escribió/wrote:
> So what do you need to "REQUIRE" to validate in a form?
>
> Well:
> a name and address to ship a "physical" product! Post code is optional.
>
> An email address "ONLY" for a news-letter subscription, or if the product to
> deliver is i.e. a software and that you send a download link and activation
> key by email.

I enjoyed reading your analysis (I have my own success stories as
Spaniard, such as the classical "Please fill-in both your mobile phone
and land line") but I'm not sure I got this last point. You don't stop
validating a field just because it's optional. You just allow it be empty.



--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

""Álvaro G. Vicario"" <alvaro.NOSPAMTHANX@demogracia.com.invalid> wrote in
message news:i26i92$cn8$2@news.eternal-september.org...
> El 21/07/2010 10:23, rf escribió/wrote:
>>> but the same happens with any other piece of data, yet no competent
>>> programmer would accept "Yellow" for the field "Birthday".
>>
>> And are you going to validate a birthday why?
>
> Mainly, because I cannot insert "Yellow" in a DATETIME column. I won't
> accept user input that's going to trigger a SQL error.

That's not validating a "birthday". It's validating a field to ensure it
fits into a datetime column, just like you would validate an integer field
before putting it into an integer column.

It is also not validating the date just because it *should* be validated.
It's validating the date because it *needs* to be validated as a valid date.

I could envisage that somebody somewhere just might acually need to put the
string "Yellow" into a phone "number" field. My childhood phone number was
"Pinnacle Road 26". Yes, it really was, and that is how it appeared in the
telephone directory. How would you go about "validating" that? You
shouldn't. You don't need to.

Sure, validate things that *need* to be validated, like date fields, integer
fields and so on, but please don't arbitrarily "validate" textual fields to
your idea of what *you* think they should look like, because somebody,
sometime will come up with something perfectly valid from their point of
view that your validation will not pass.

Le 21/07/10 14:13, "Álvaro G. Vicario" a écrit :
> I'm not sure I got this last point. You don't stop
> validating a field just because it's optional. You just allow it be empty.

Indeed, this is exact, sorry If I got myself misunderstood on this
point. You validate it "if ( trim($field) == '')", but do not "require" it.
What I also meant is that due to different language characters (Latin,
VS Greek, VS Cyrillic,vs Arabic, VS Hebrew, VS etc...), traditional
regular expressions for character fields will fail... and it is
very-very difficult (does not mean impossible) to select a regular
expression pattern depending on the language...
And allowing all languages characters is not easy ESPECIALLY when you do
not "know" these languages. i.e. I know Russian exists, but I do not
know their alphabet, nor do I know the Arabian alphabet, and you can't
ask a webmaster to know all languages' alphabets in the world-wide-web,
he only needs to know they exist. The difficulty is to obtain
information on what characters to use in a regular expression to match
ALL world existing languages... So the best is to simply unallow special
characters with i.e. strip_tags(), but appart from this... it's a
brainstorming puzzling issue.
At least you know you need to use multibyte strings for regular
expressions to work on UTF-8 strings:
http://fr2.php.net/manual/en/book.mbstring.php
and set mb_internal_encoding("UTF-8")
But then... You pull your hair off... :-)

--
Web Dreamer

El 22/07/2010 2:14, Web Dreamer escribió/wrote:
> So the best is to simply unallow special
> characters with i.e. strip_tags(), but appart from this... it's a
> brainstorming puzzling issue.

Sorry, you've just touched one of my pet peeves. The strip_tags()
function is useful to extract plain text from HTML code but it makes
little sense when applied to plain text. However, the're like a zillion
programming blogs out there were your comments get mutilated as soon as
you type code.



--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

"Álvaro G. Vicario" a écrit ce jeudi 22 juillet 2010 08:30 dans
<i28oig$kan$1@news.eternal-september.org> :

> El 22/07/2010 2:14, Web Dreamer escribió/wrote:
>> So the best is to simply unallow special
>> characters with i.e. strip_tags(), but appart from this... it's a
>> brainstorming puzzling issue.
>
> Sorry, you've just touched one of my pet peeves. The strip_tags()
> function is useful to extract plain text from HTML code but it makes
> little sense when applied to plain text. However, the're like a zillion
> programming blogs out there were your comments get mutilated as soon as
> you type code.

A BLOG is a different thing compared to an e-commerce site.
We where talking about special fields holding specific and restricted types
of characters.
You can not properly filter a programming blog's text without mutilating the
content. There, the contents should only be "escaped" with a method
depending on the target. You are right about this.

--
Web Dreamer

>Why do you have such strong feelings about form validation? Of course we
>cannot know whether the phone exists and belongs to that person but the
>same happens with any other piece of data, yet no competent programmer
>would accept "Yellow" for the field "Birthday". And if that's not your
>concern them I'm afraid I cannot follow you.

If the field in question is for a *security question*, you certainly
should accept "Yellow" for "What is your father's birthday?". You
should also accept "None of your d**n business", "Fido the talking
weasel", "next Tuesday", and "CPE1704TKS".

IMHO, you should accept anything *but* a valid date. This makes it
a lot harder to guess. Not everyone uses security questions like I
do.