These tasks are discussed next.
358 CHAPTER 13 ?– FORMS
Validating Form Input
As mentioned earlier in this chapter and elaborated further upon in Chapter 21, you
should never blindly accept user input. The cost of ignoring this advice could be the
integrity of your data, the destruction of your Web site, the loss of confidential user
information, or any number of other undesired outcomes.
But data validation is a tiresome and error-prone process, one in which incorrect
validation code can result in a dire situation, and one in which the developer must be
abundantly aware of the characteristics of the data he??™s trying to validate. For instance,
suppose you want to validate the syntax of an e-mail address according to the specification
as set forth in RFC 2822 (http://www.faqs.org/rfcs/rfc2822). But in creating
the rather complex regular expression required to properly validate an e-mail address,
you limit the domain extension to four characters, considering yourself particularly
Internet savvy for remembering the more recently available .mobi and .name toplevel
domains. However, you neglect to factor in the even more recently available
.museum and .travel domains, thereby preventing anybody using those addresses
from registering on your Web site.
Or take the simple example of ensuring the user enters what you perceive to be a
valid first name. Surely names should only consist of alphabetical characters and
won??™t consist of less than three or more than ten letters, right? But what about people
who go by initials, such as R.
Pages:
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434