Riconoscimento difficile dell’indirizzo email?

Recentemente ho letto da qualche parte che scrivere una espressione regolare per abbinare un indirizzo email, tenendo conto di tutte le variazioni e le possibilità dello standard è estremamente difficile ed è significativamente più complicato di quello che inizialmente si suppone.

Qualcuno può fornire qualche intuizione sul perché questo è?

Ci sono delle espressioni regolari conosciute e provate che effettivamente lo fanno completamente?

Quali sono alcune buone alternative all’uso delle espressioni regolari per gli indirizzi email corrispondenti?

Per le specifiche e-mail formali , sì, è tecnicamente imansible tramite Regex a causa della ricorsione di cose come i commenti (specialmente se non si rimuovono prima i commenti su whitespace), e i vari formati diversi (un indirizzo e-mail non è sempre [email protected]). È ansible avvicinarsi (con alcuni schemi Regex massicci e incomprensibili), ma un modo molto migliore di controllare una e-mail è di fare la stretta di mano molto familiare:

  • ti dicono la loro e-mail
  • Inviate loro via e-mail un link di confimazione con un Guid
  • quando cliccano sul link sai che:

    1. l’e-mail è corretta
    2. esiste
    3. loro lo possiedono

Molto meglio dell’accettazione cieca di un indirizzo e-mail.

Ci sono un certo numero di moduli Perl (per esempio) che fanno questo. Non provare e scrivere la tua espressione regolare per farlo. Guarda a

Mail::VRFY eseguirà controlli di syntax e di rete (lo fa e il server SMTP da qualche parte accetta questo indirizzo)

https://metacpan.org/pod/Mail::VRFY

RFC::RFC822::Address – un parser di indirizzo e-mail di discesa ricorsiva.

https://metacpan.org/pod/RFC::RFC822::Address

Mail::RFC822::Address – convalida dell’indirizzo basato su regexp, vale la pena guardare solo per la regexp folle

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

Esistono strumenti simili per altre lingue. Insane regexp sotto …

 (?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*) 

Convalidare gli indirizzi e-mail non è comunque molto utile. Non catturerà errori di battitura o indirizzi email inventati, poiché questi tendono a sembrare sintatticamente come indirizzi validi.

Se vuoi essere sicuro che un indirizzo sia valido, non hai altra scelta che inviare una mail di conferma.

Se vuoi solo essere sicuro che l’utente inserisca qualcosa che assomigli ad un’e-mail piuttosto che solo “asdf”, cerca un @. Una convalida più complessa non offre alcun vantaggio.

(So ​​che questo non risponde alle tue domande, ma penso che valga la pena menzionarlo comunque)

Ho ora raccolto i casi di test da Cal Henderson, Dave Child, Phil Haack, Doug Lovell e RFC 3696. 158 test indirizzi in tutto.

Ho eseguito tutti questi test contro tutti i validatori che ho trovato. Il confronto è qui: http://www.dominicsayers.com/isemail

Cercherò di mantenere questa pagina aggiornata man mano che le persone migliorano i loro validatori. Grazie a Cal, Dave e Phil per il loro aiuto e collaborazione nel compilare questi test e le critiche costruttive del mio validatore .

Le persone dovrebbero essere consapevoli dell’errata contro RFC 3696 in particolare. Tre degli esempi canonici sono in realtà indirizzi non validi. E la lunghezza massima di un indirizzo è 254 o 256 caratteri, non 320.

Tuttavia, non è una sciocchezza lasciare che caratteri come “+” possano essere molto utili per gli utenti che combattono lo spam, ad esempio [email protected] ( indirizzi Gmail monouso istantanei ).

Solo quando un sito lo accetta però.

Esiste una grammatica context free in BNF che descrive indirizzi email validi in RFC-2822 . È complesso Per esempio:

 " @ "@example.com 

è un indirizzo email valido Non conosco alcuna espressione regolare che lo faccia completamente; gli esempi solitamente forniti richiedono che i commenti vengano prima rimossi. Ho scritto un parser di discesa ricorsivo per farlo completamente una volta.

Se accettare o meno formati di indirizzi di posta elettronica bizzarri e non comuni dipende, a mio parere, da ciò che si vuole fare con loro.

Se stai scrivendo un server di posta, devi essere molto preciso e terribilmente corretto in ciò che accetti. La regex “folle” citata sopra è quindi appropriata.

Per il resto di noi, però, siamo principalmente interessati a garantire che qualcosa che un utente digita in un modulo Web abbia un aspetto ragionevole e non abbia una sorta di iniezione di SQL o buffer overflow in esso.

Francamente, a qualcuno importa davvero che qualcuno inserisca un indirizzo email di 200 caratteri con commenti, nuove righe, virgolette, spazi, parentesi o altri termini senza senso quando si iscrive a una mailing list, a una newsletter oa un sito web? La risposta corretta a tali pagliacci è “Torna più tardi quando hai un indirizzo che assomiglia a [email protected]“.

La convalida che faccio consiste nel garantire che esista esattamente una ‘@’; che non ci sono spazi, null o newline; che la parte a destra di “@” abbia almeno un punto (ma non due punti in una riga); e che non ci sono virgolette, parentesi, virgole, due punti, punti esclamativi, punti e virgola o barre rovesciate, che sono più probabilità di essere tentativi di hacker di parti di un vero indirizzo email.

Sì, questo significa che sto rifiutando gli indirizzi validi con cui qualcuno potrebbe provare a registrarsi sui miei siti Web – forse “erroneamente” rifiuto fino a 0,001% degli indirizzi reali! Posso vivere con quello.

Citando e varie altre parti raramente utilizzate ma valide della RFC rendono difficile. Non ne so abbastanza su questo argomento per commentare in modo definitivo, a parte “è difficile” – ma per fortuna altre persone ne hanno scritto a lungo.

Per quanto riguarda una regex valida per questo, il modulo Perl Mail :: Rfc822 :: Address contiene un’espressione regolare che apparentemente funzionerà , ma solo se qualche commento è già stato sostituito da spazi bianchi. (Commenti in un indirizzo email? Si vede perché è più difficile di quanto ci si potrebbe aspettare …)

Naturalmente, le regex semplificate che abbondano altrove valuteranno quasi ogni indirizzo email che viene effettivamente utilizzato …

Alcuni tipi di regex possono effettivamente corrispondere a parentesi annidate (ad esempio, quelle compatibili Perl). Detto questo, ho visto una regex che afferma di corrispondere correttamente a RFC 822 ed erano due pagine di testo senza spazi bianchi. Pertanto, il modo migliore per rilevare un indirizzo email valido è di inviarlo e vedere se funziona.

Solo per aggiungere un’espressione regolare meno pazza di quella elencata da @mmaibaum:

 ^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)[email protected]([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$ 

Non è a prova di proiettile, e certamente non copre l’intera specifica della posta elettronica, ma fa un lavoro decente di coprire la maggior parte dei requisiti di base. Ancora meglio, è piuttosto comprensibile e può essere modificato.

Estratto da una discussione su HouseOfFusion.com , una risorsa ColdFusion di class mondiale.

Un modo semplice e valido per controllare gli indirizzi email in Java è utilizzare l’EmailValidator della libreria Validator di Apache Commons .

Controllerei sempre un indirizzo email in un modulo di input con qualcosa di simile prima di inviare un’e-mail, anche se si verificano solo alcuni refusi. Probabilmente non si vuole scrivere uno scanner automatico per i messaggi di notifica “consegna non riuscita”. 🙂

È davvero difficile perché ci sono molte cose che possono essere valide in un indirizzo e-mail secondo le specifiche e-mail, RFC 2822 . Le cose che normalmente non vedi come + sono caratteri perfettamente validi per un indirizzo email .. secondo le specifiche.

C’è un’intera sezione dedicata agli indirizzi email su http://regexlib.com , che è una grande risorsa. Ti suggerirei di determinare quali criteri sono importanti per te e trovarne uno che corrisponda. La maggior parte delle persone non ha davvero bisogno di un supporto completo per tutte le possibilità consentite dalle specifiche.

Se stai lavorando su .NET Framework, prova a MailAddress un’istanza di un object MailAddress e ad FormatException se esplode o estrae l’ Address se riesce. Senza tralasciare le prestazioni delle eccezioni di cattura (in realtà, se questo è solo su un singolo modulo Web, non farà granché la differenza), la class MailAddress nel framework .NET passa attraverso un parsing abbastanza completo processo (non usa una RegEx). Apri Reflector e cerca MailAddress e MailBnfHelper.ReadMailAddress() per vedere tutte le cose fantasiose che fa. Qualcuno più intelligente di me ha passato molto tempo a sviluppare quel parser in Microsoft, lo userò quando invierò effettivamente una e-mail a quell’indirizzo, quindi potrei anche usarlo per convalidare anche l’indirizzo in arrivo.

Molti hanno provato e molti si avvicinano. Si consiglia di leggere l’ articolo di Wikipedia , e alcuni altri .

Nello specifico, vorrai ricordare che molti siti Web e server di posta elettronica hanno una convalida rilassata degli indirizzi email, quindi essenzialmente non implementano pienamente lo standard. Tuttavia, è abbastanza buono per l’email lavorare sempre.

Prova questo:

 "(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])" 

Dai un’occhiata qui per i dettagli.

Tuttavia, piuttosto che implementare lo standard RFC822, forse sarebbe meglio guardarlo da un altro punto di vista. Non importa ciò che dice lo standard se i server di posta non rispecchiano lo standard. Quindi direi che sarebbe meglio imitare ciò che i server di posta più popolari fanno quando convalida gli indirizzi email.

Questa class per Java ha un validatore in questo: http://www.leshazlewood.com/?p=23

Questo è scritto dal creatore di Shiro (formalmente Ki, formalmente JSecurity)

I pro ei contro del test per la validità dell’indirizzo e-mail:

Esistono due tipi di regex che convalidano le e-mail:

  1. Quelli che sono troppo lenti.
  2. Quelli che sono troppo severi.

Non è ansible che un’espressione regolare corrisponda a tutti gli indirizzi e-mail validi e nessun indirizzo e-mail non valido perché alcune stringhe potrebbero sembrare indirizzi e-mail validi ma in realtà non vanno nella posta in arrivo di nessuno. L’unico modo per verificare se una e-mail è effettivamente valida è inviare una e-mail a quell’indirizzo e vedere se si ottiene una sorta di risposta. Tenendo questo a mente, le espressioni regolari troppo rigide per la corrispondenza delle e-mail non sembrano avere un granché.

Penso che la maggior parte delle persone che chiedono una regex di e-mail stiano cercando la prima opzione, regex troppo loose. Vogliono testare una stringa e vedere se sembra un’e-mail, se non è sicuramente un’e-mail, allora possono dire all’utente: “Ehi, dovresti mettere una e-mail qui e questo è sicuramente non è un’e-mail valida. Forse non ti sei reso conto che questo campo è per un messaggio di posta elettronica o forse c’è un errore di battitura “.

Se un utente inserisce una stringa che assomiglia molto a una e-mail valida, ma in realtà non è una, allora questo è un problema che dovrebbe essere gestito da una parte diversa dell’applicazione.

Qualcuno può fornire qualche intuizione sul perché questo è?

Sì, è uno standard estremamente complicato che consente molte cose che nessuno usa veramente oggi. 🙂

Ci sono delle espressioni regolari conosciute e provate che effettivamente lo fanno completamente?

Ecco un tentativo di analizzare completamente l’intero standard …

http://ex-parrot.com/~pdw/Mail-RFC822-Address.html

Quali sono alcune buone alternative all’uso delle espressioni regolari per gli indirizzi email corrispondenti?

Immagino che usi un framework esistente per esso in qualsiasi lingua tu stia utilizzando? Anche se quelli probabilmente useranno regexp internamente. È una stringa complessa. I regexps sono progettati per analizzare stringhe complesse, quindi è davvero la scelta migliore.

Edit : dovrei aggiungere che la regexp a cui mi sono collegato era solo per divertimento. Non sostengo l’uso di una regexp complessa come quella – alcune persone dicono che “se il tuo regexp è più di una riga, è garantito che ci sia un bug da qualche parte”. L’ho collegato per illustrare quanto sia complesso lo standard.

Aggiungendo la risposta di Wayne , c’è anche una sezione su http://www.regular-expressions.info dedicata alla posta elettronica, con alcuni esempi.

Puoi sempre chiedertene se ne valga la pena o se in effetti una regexp inferiore al 100% contribuisca solo a un falso senso di sicurezza.

Alla fine, in realtà l’ invio dell’e-mail è ciò che fornirà la vera convalida finale. (-si scoprirai se il tuo server di posta ha bug 😉

Per completezza di questo post, anche per PHP esiste una funzione integrata di linguaggio per convalidare le e-mail.

Per PHP Usa il bel filter_var con il tipo di convalida EMAIL specifico 🙂

Non è più necessaria un’e-mail pazza su php: D

 var_dump(filter_var('[email protected]', FILTER_VALIDATE_EMAIL)); 

http://www.php.net/filter_var