.:° JsDir °:. JavaScript .:° Tutorials: piccoli corsi concentrati su un argomento per imparare di piu'. °:. Bring Your Site To Life®

Questo tutorial è basato su un articolo di Peter-Paul Koch per sua gentile concessione.
La pagina originale di PPK è a questo link: http://www.xs4all.nl/~ppk/js/mailcheck.html
In alcuni punti è semplicemente tradotto, per la maggior parte il contenuto è mio, comunque se ci trovate qualche fesseria... prendetevela con me! :-)

Il Webmaster

Errata corrige 23/02/2002
Andrea Baldon mi fa giustamente notare che il nome del server dev'essere lungo almeno due caratteri e così il TLD.
Una casistica non prevista da PPK ed alla quale non avevo pensato.
Per chi avesse già letto il tutorial prima di oggi, la modifica al pattern è consistita nell'aggiunta di {2,} che significa appunto "almeno due...".

Sull'argomento "Validazione Form" sono presenti altre risorse nel sito, sia sulla validazioe in generale che per specifiche necessità-
Per la validazione consultare lo StaffScripts "From Validator" che mostrerà una maniera molto semplice e veloce per validare un form ed informare l'utente di quali sono i campi che deve controllare.
Tra le faq è sufficiente fare una ricerca con la parola "valid", mentre fra i tutorial segnalo quello per validare il codice fiscale con una RegExp.

Questo piccolo script controlla se un utente ha inserito un indirizzo di e-mail valido.
Naturalmente non può controllare che l'indirizzo inserito esista realmente, si limita semplicemente a verificare se è giusto da un punto di vista formale.

Usa le Regular Expressions che non sono ancora trattate nel sito (ndR: nel sito dell'autore e neanche in JsDir :-). Naturalmente un semplice script non è sufficiente per imparare ad usarle, se anche non capite appieno lo script usatelo comunque... sulla fiducia.
Le RegExp sono comunque un argomento molto particolare e totalmente nuovo ed... inaspettato a chi non le ha mai viste. Chi le usa regolarmente (in particolare i programmatori PERL) afferma che non potrebbe farne a meno! Mi fido sulla parola, ma se c'è qualcuno in grado di scrivere un tutorial (o una serie) sull'argomento che mi scriva! perché anch'io vorrei saperne di più.

Torniamo a noi analizzando per primo il seguente form:


<HTML>
  <BODY>
   <FORM NAME="modulo" ACTION="..." onSubmit="return ControllaMail()">
    <INPUT TYPE="text" NAME="email">
    <INPUT TYPE="submit" VALUE="Invia">
   </FORM>
  </BODY>
</HTML>

Il classico modulo il cui invio dipende dal risultato della funzione di validazine che nel nostro caso sarà:


<SCRIPT>
<!--
function ControllaMail()
   {
   EmailAddr = document.modulo.email.value;
   Filtro = /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-]{2,})+\.)+([a-zA-Z0-9]{2,})+$/;
   if (Filtro.test(EmailAddr))
      return true;
   else
      {
      alert("Controlla l'indirizzo di e-mail inserito");
      document.modulo.email.focus();
      return false;
      }
   }
//-->
</SCRIPT>

Naturalmente quel che ci interessa è la Regular Expression evidenziata in rosso.
La funzione per il resto si comporta come qualsiasi altra funzione di validazione restituendo true al form, che può così essere inviato, se il controllo è OK, altrimenti avverte l'utente che ha commesso un errore nell'indirizzo e-mail e poi riposiziona il cursore sul campo di inserimento restituendo false al form che non sarà inviato.
Il cardine dello script (oltre alla RegExp) è quel test() che ho evidenziato in grassetto, e che è un metodo tipico delle Regular Expression.
Viene usato con sintassi: RegExp.test(stringa) e significa in pratica "controlla la stringa usando la RegExp.
Il metodo restituisce true se il controllo ha esito positivo, altrimenti restituisce false.

Si ma quale "controllo" direte voi?
Vediamo cosa significa quella... cosa strana, ossia la Regular Expression! :-)
Cominciamo col dire che come gli apici (o doppi apici) sono delimitatori di stringa per le stringhe normali, nelle RegExp il delimitatore è lo slash: [ / ].
Il backslash [ \ ] viene usato come al solito in JavaScript: serve per inserire nella stringa (quindi nella RegExp) dei caratteri che hanno un significato particolare perché vengano "interpretati così come sono". Mi spiego: se abbiamo una stringa racchiusa fra apici singoli in cui è necessario inserire un apostrofo (quindi un apice) scriveremmo in questo modo: 'JavaScript e\' bello'; cioè useremmo il backsladh. Nello stesso modo ad esempio il punto [ . ] è stato preceduto dal backslash perché altrimenti avrebbe cambiato il funzionamento della RegExp... Non chiedetemi perché il backslash sia stato messo anche davanti al "meno" ed alla "chiocciola", non lo so ma lo lascio! :-)

Vediamo gli altri caratteri principali:
- il "caret" ( ^ ) acc. circonflesso significa "all'inizio della stringa";
- il simbolo del "dollaro" ( $ ) significa "alla fine della stringa";
- il segno "più" ( + ) significa "almeno una o più occorrenze" [...della stringa con caratteristiche uguali al filtro che precede];

Dunque fino adesso sappiamo che la stringa "passata" alla RegExp viene controllata dall'inizio (^) alla fine ($): /^ ... $/

Subito dopo il [ ^ ] comincia la RegExp vera e propria... e comincia anche il divertimento!
Premesso che in questo caso la RegExp viene usata per controllare una stringa, di fatto possiamo pensare alla RegExp come ad un "modello" sul quale viene verificato l'indirizzo di e-mail dell'utente.
Con quest'ordine d'idee, questa notazione ([a-zA-Z0-9_\.\-])+ (che d'ora in poi chiamo pattern) significa "una stringa composta da lettere minuscole e/o lettere maiuscole e/o numeri e/o underscore e/o puntini e/o trattini. Con il segno [ + ] davanti e la logica del "modello", il pattern significa più o meno "controlla che l'inizio della stringa (l'email) sia composta da uno o più gruppi di minuscole e/o maiuscole... etc..

Subito dopo vogliamo che ci sia una chiocciola: [\@ ]. Una sola (non abbiamo messo il segno [ + ]) e solo in questa posizione, cioà dopo il primo gruppo di caratteri. Questo è importante: ad esempio se l'utente non inserisce la chicciola, non verrà trovata in questa posizione, ed il controllo fallirà; analogamente se dovesse inserirne un'altra dopo il controllo fallisce lo stesso perché la chiocciola non è contenuta nei pattern che seguono... sembra facile eh? :-)

Dopo la chiocciola abbiamo un altro pattern un po' diverso: (([a-zA-Z0-9\-]{2,})+\.)+. A parte il fatto che manca l'underscore, notiamo che il punto è stato portato fuori della prima parentesi e che è comparso un {2,}.
Considerando anche i due segni [ + ] questo pattern significa: uno o più (gruppi di) almeno due minuscole e/o maiuscole e/o numeri e/o trattini seguiti da un punto, il tutto una o più volte
Un po' più complicato, cmq ora che finiamo vi farò un esempio concreto usando il mio indirizzo di e-mail come verifica di tutto compresi i [ + ].

Infine l'ultimo pattern (che ormai dovrebbe essere chiaro: uno o più (gruppi di) almeno due minuscole e/o maiuscole e/o numeri) e che deve obbligatoriamente terminare la stringa (per il simbolo del [ $ ]).

Tutto qua... si fa per dire. Se ancora non è chiaro basta considerare che un tipico indirizzo e-mail è fatto in questo modo:

username@provider.tld

In pratica il primo pattern verifica la correttezza formale dell'username, dopo questo viene controllato se è presente il simbolo [ @ ], poi il provider viene confrontato con il modello sel secondo pattern, ed infine il TopLevelDomain (.it o .com o .net etc...) con l'ultimo pattern.
Ad esempio il mio indirizzo di email: NOwebmasterATjsdir.com è verificato perché contiene per prime due lettere, poi un punto (siamo nel primo pattern), poi altre lettere, il tutto più di una volta; dopo viene la chiocciola, poi due gruppi "lettere/numeri/trattino più il punto" (e cioè jsdir.), ed infine un ulteriore gruppo di lettere e/o numeri, e cioè il .it.

Finito. Resta solo da capire perché sono stati contemplati i numeri dopo la chiocciola e perché la lunghezza del tld non è stata limitata a 2 o 3 caratteri.
I numeri sono stati usati perché anche se noi siamo "umanamente" abituati ad usare le lettere per indicare un server, comunque i computer continuano ad usare gli IP Address, quindi inviare una e-mail a NOwebmasterSPAM@jsdir.com oppure a NOwebmasterSPAM@217.194.0.21 è la stessa identica cosa.
Semmai anche un indirizzo come questo: NOwebmasterSPAM@[217.194.0.21] sarebbe formalmente corretto (anzi la sintassi assolutamente esatta è proprio questa), ma lo script non la verifica e comunque probabilmente non esiste più alcun server di posta che la usi.
Inoltre anche se non è consentito, indirizzi in cui il "provider" comincia o è costituito da numeri sono stati usati nella storia di Internet, quindi e-mail come questa: qualcuno@12345.com anche se vietate potrebbero essere valide e funzionanti.
Infine non avrebbe senso limitare il tld a 2 o tre caratteri perché comunque 3 caratteri non è il limite massimo previsto per il TopLevelDomain. Se fino a qualche mese fa aveva senso limitarsi a 3 caratteri (.com), da quando l'ICANN ha approvato i ".info" i caratteri sono diventati quattro! Probabilmente in giro per la rete c'è qualche script di validazione che... non fa il suo dovere :-))

Basta così, spero di non aver scritto qualche castroneria, in tal caso non mancate di segnalarmelo per e-mail.

Per provare lo script usate questo campo testo realizzato esattamente con la sintassi vista sopra. Se l'indirizzo è valido la pagina sarà ricaricata (a simulare l'effettivo invio del form), altrimenti vi sarà chiesto di controllare.

	Parli JavaScript? Non tenerlo per te! JsDir cerca collaboratori. Se gli UserScript ti stanno stretti e vuoi inserire delle FAQ, dei Tips&Tricks, o anche uno StaffScript, se vuoi scrivere un tutorial o recensire un libro... insomma se parli JavaScript segui questo link. È un'occasione per farti conoscere e dimostrare le tue capacità!!!