Riconoscimento del riconoscimento dell'indirizzo e-mail difficile?
https://stackoverflow.com/questions/156430
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Di recente ho letto da qualche parte che scrivere un regexp per abbinare un indirizzo e-mail, prendendo in considerazione tutte le variazioni e le possibilità dello standard è estremamente difficile ed è significativamente più complicato di quanto si supponga inizialmente.
Qualcuno può fornire qualche idea sul perché?
Esistono regexps noti e comprovati che lo fanno davvero?
Quali sono alcune buone alternative all'uso di regexps per abbinare gli indirizzi e-mail?
Soluzione
Per le specifiche e-mail formali , sì, è tecnicamente impossibile tramite Regex a causa della ricorsione di cose come i commenti (soprattutto se non si rimuovono prima i commenti agli spazi bianchi) e il vari formati diversi (un indirizzo e-mail non è sempre qualcuno@somewhere.tld). Puoi avvicinarti (con alcuni schemi Regex enormi e incomprensibili), ma un modo molto migliore di controllare un'e-mail è fare la stretta di mano molto familiare:
- ti dicono la loro e-mail
- gli invii per e-mail un link di conferma con un Guid
-
quando fanno clic sul collegamento lo sai che:
- l'e-mail è corretta
- esiste
- lo possiedono
Molto meglio che accettare ciecamente un indirizzo e-mail.
Altri suggerimenti
Esistono diversi moduli Perl (ad esempio) che lo fanno. Non provare a scrivere il tuo regexp per farlo. Guarda
Mail::VRFY eseguirà i controlli di sintassi e di rete (il server SMTP da qualche parte accetta questo indirizzo)
https://metacpan.org/pod/Mail::VRFY
RFC::RFC822::Address - un parser di indirizzi e-mail di discendenza ricorsiva.
https://metacpan.org/pod/RFC::RFC822::Address
Mail::RFC822::Address - convalida dell'indirizzo basato su regexp, vale la pena guardare solo per la folle regexp
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*)
La convalida degli indirizzi e-mail non è comunque molto utile. Non catturerà errori di battitura comuni o indirizzi e-mail inventati, poiché questi tendono ad assomigliare sintatticamente a 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 a una e-mail piuttosto che solo " asdf " ;, quindi 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)
Ora ho raccolto i casi di test di Cal Henderson, Dave Child, Phil Haack, Doug Lovell e RFC 3696. 158 indirizzi di test 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 aggiornata questa pagina man mano che le persone miglioreranno i propri validatori. Grazie a Cal, Dave e Phil per l'aiuto e la cooperazione nella compilazione di questi test e critiche costruttive di il mio validatore .
Le persone dovrebbero essere a conoscenza delle errata contro RFC 3696 in particolare . Tre degli esempi canonici sono in realtà indirizzi non validi. E la lunghezza massima di un indirizzo è di 254 o 256 caratteri, non 320.
Non è una sciocchezza, dato che consentire caratteri come "+" può essere molto utile per gli utenti che combattono lo spam, ad es. myemail+sketchysite@gmail.com ( indirizzi Gmail usa e getta istantanei ).
Solo quando un sito lo accetta però.
Esiste una grammatica senza contesto in BNF che descrive indirizzi e-mail validi in RFC-2822 . È complesso. Ad esempio:
" @ "@example.com
è un indirizzo email valido. Non conosco alcuna regexps che lo faccia pienamente; gli esempi generalmente forniti richiedono che i commenti vengano prima rimossi. Ho scritto un parser di discesa ricorsivo per farlo completamente una volta.
L'accettazione o meno di formati di indirizzi e-mail bizzarri e non comuni dipende, a mio avviso, da cosa si vuole fare con loro.
Se stai scrivendo un server di posta, devi essere molto preciso ed estremamente preciso in ciò che accetti. Il & Quot; insane & Quot; regex citato sopra è quindi appropriato.
Per il resto di noi, tuttavia, siamo principalmente interessati a garantire che qualcosa che un utente digita in un modulo Web appaia ragionevole e non abbia una sorta di iniezione sql o buffer overflow in esso.
Francamente, qualcuno si preoccupa davvero di permettere a qualcuno di inserire un indirizzo e-mail di 200 caratteri con commenti, newline, citazioni, spazi, parentesi o altro senza senso quando si iscrive a una mailing list, newsletter o sito web? La risposta corretta a tali pagliacci è & Quot; Torna più tardi quando hai un indirizzo che assomiglia a username@domain.tld & Quot ;.
La convalida che faccio consiste nel garantire che esista esattamente un '@'; che non ci sono spazi, null o newline; che la parte a destra di "@" ha almeno un punto (ma non due punti di fila); e che non ci sono virgolette, parentesi, virgole, due punti, punti esclamativi, punti e virgola o barre rovesciate, che hanno più probabilità di essere tentativi di pirateria informatica rispetto a parti di un vero indirizzo e-mail.
Sì, questo significa che sto rifiutando indirizzi validi con i quali qualcuno potrebbe tentare di registrarsi sui miei siti Web - forse I " erroneamente " respingere fino allo 0,001% degli indirizzi del mondo reale! Posso conviverci.
La citazione e varie altre parti usate raramente ma valide della RFC rendono difficile. Non so abbastanza su questo argomento per commentare definitivamente, tranne & Quot; è difficile & Quot; - ma fortunatamente altre persone hanno scritto a lungo.
Per quanto riguarda una regex valida, 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? Capisci perché è più difficile di quanto ci si possa aspettare ...)
Naturalmente, le regex semplificate che abbondano altrove convalideranno quasi tutti gli indirizzi e-mail che vengono effettivamente utilizzati ...
Alcuni tipi di regex possono effettivamente corrispondere a parentesi nidificate (ad esempio, quelli compatibili con 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 e-mail valido è inviargli e-mail e vedere se funziona.
Solo per aggiungere una regex che è meno folle di quella elencata da @mmaibaum:
^[a-zA-Z]([.]?([a-zA-Z0-9_-]+)*)?@([a-zA-Z0-9\-_]+\.)+[a-zA-Z]{2,4}$
Non è a prova di proiettile e certamente non copre l'intera specifica e-mail, ma fa un buon lavoro nel soddisfare la maggior parte dei requisiti di base. Ancora meglio, è in qualche modo comprensibile e può essere modificato.
Paralizzato da una discussione in HouseOfFusion.com , una risorsa di classe mondiale di ColdFusion.
Un modo semplice e buono per controllare gli indirizzi e-mail in Java è utilizzare EmailValidator di Apache Commons Validator libreria.
Verificherei sempre un indirizzo e-mail in un modulo di input con qualcosa del genere prima di inviare un'e-mail, anche se si rilevano solo errori di battitura. Probabilmente non vorrai scrivere uno scanner automatico per & Quot; consegna non riuscita & Quot; mail di notifica. : -)
È 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 e-mail all'indirizzo http://regexlib.com , che è un'ottima risorsa. Ti suggerirei di determinare quali criteri sono importanti per te e di trovarne uno che corrisponda. La maggior parte delle persone non ha davvero bisogno del pieno supporto per tutte le possibilità consentite dalla specifica.
Se si esegue .NET Framework, provare a creare un'istanza di un oggetto MailAddress e catturare FormatException se esplode o estrarre Address se ha esito positivo. Senza avere alcuna assurdità riguardo alle prestazioni di rilevazione delle eccezioni (in realtà, se questo è solo su un singolo modulo Web, non farà molta differenza), la classe MailBnfHelper.ReadMailAddress() nel framework .NET attraversa un bel processo di analisi completo (non utilizza un RegEx). Apri Reflector e cerca <=> e <=> per vedere tutte le cose fantasiose che fa. Qualcuno più intelligente di me ha trascorso molto tempo a costruire quel parser presso Microsoft, lo userò quando invierò effettivamente un'e-mail a quell'indirizzo, quindi potrei anche usarlo per convalidare anche l'indirizzo in arrivo.
Molti ci hanno provato e molti si avvicinano. Potresti leggere articolo di Wikipedia e alcuni altri .
In particolare, ti consigliamo di ricordare che molti siti Web e server di posta elettronica hanno una convalida semplificata degli indirizzi e-mail, quindi essenzialmente non implementano completamente lo standard. È comunque sufficiente che l'e-mail funzioni 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 cosa dice lo standard se i server di posta non rispecchiano lo standard. Quindi direi che sarebbe meglio imitare ciò che fanno i server di posta più popolari durante la convalida degli indirizzi e-mail.
Questa classe per Java ha un validatore: http://www.leshazlewood.com/?p=23
Questo è scritto dal creatore di Shiro (formalmente Ki, formalmente JSecurity)
Pro e contro dei test per la validità dell'indirizzo e-mail:
Esistono due tipi di regex che convalidano le e-mail:
- Quelli troppo sciolti.
-
Quelli troppo severi.
Non è possibile che un'espressione regolare corrisponda a tutti gli indirizzi di posta elettronica validi e nessun indirizzo di posta elettronica che non sono validi perché alcune stringhe potrebbero apparire come indirizzi di posta elettronica validi ma in realtà non vanno alla posta in arrivo di nessuno. L'unico modo per verificare se un'e-mail è effettivamente valida è inviare un'e-mail a quell'indirizzo e vedere se si ottiene una sorta di risposta. Con questo in mente, le regex che sono troppo rigide nell'abbinare le e-mail non sembrano avere molto scopo.
Penso che la maggior parte delle persone che chiedono una regex di posta elettronica stiano cercando la prima opzione, regex troppo lente. Vogliono testare una stringa e vedere se assomiglia a un'e-mail, se non è sicuramente un'e-mail, quindi possono dire all'utente: & Quot; Ehi, dovresti mettere un'e-mail qui e questa sicuramente non è un'e-mail valida. Forse non ti sei reso conto che questo campo è per una e-mail o forse c'è un refuso & Quot ;.
Se un utente inserisce una stringa che assomiglia molto a un'e-mail valida, ma in realtà non lo è, questo è un problema che dovrebbe essere gestito da una parte diversa dell'applicazione.
Qualcuno può fornire qualche idea sul perché?
Sì, è uno standard estremamente complicato che consente molte cose che nessuno usa davvero oggi. :)
Esistono regexps noti e comprovati che lo fanno davvero?
Ecco un tentativo di analizzare completamente l'intero standard ...
http://ex-parrot.com/~pdw/Mail -RFC822-Address.html
Quali sono alcune buone alternative all'utilizzo di regexps per abbinare gli indirizzi e-mail?
Usando un framework esistente per esso in qualunque lingua tu stia usando immagino? Sebbene quelli probabilmente useranno regexp internamente. È una stringa complessa. I regexps sono progettati per analizzare stringhe complesse, quindi questa è davvero la scelta migliore.
Modifica : dovrei aggiungere che la regexp a cui mi collegavo era solo per divertimento. Non approvo l'uso di una regexp complessa come quella - alcune persone dicono che & Quot; se la tua regexp è più di una riga, è garantito che ci sia un bug da qualche parte & Quot ;. Ho collegato ad esso per illustrare quanto sia complesso lo standard.
Aggiungendo alla risposta di Wayne , c'è anche una sezione su www.regular-expressions.info dedicato alla posta elettronica, con alcuni esempi.
Puoi sempre chiederti se ne vale la pena o se in effetti qualsiasi regexp con copertura inferiore al 100% contribuisce solo a un falso senso di sicurezza.
Alla fine, in realtà invio l'e-mail è ciò che fornirà la vera validazione finale. (-vi scoprirai se il tuo mailserver ha dei bug ;-)
Per completezza di questo post, anche per PHP esiste una funzione integrata nella lingua per convalidare le e-mail.
Per PHP Usa il simpatico filter_var con il tipo di convalida EMAIL specifico :)
Non ci sono più regex email pazze in php: D
var_dump(filter_var('bob@example.com', FILTER_VALIDATE_EMAIL));
