Gli indirizzi e-mail sono autorizzati a contenere caratteri non alfanumerici?

Sto costruendo un sito web usando `Django. Il sito Web potrebbe avere utenti significativi da paesi che non parlano inglese.

Voglio solo sapere se ci sono restrizioni tecniche sui tipi di caratteri che un indirizzo email potrebbe contenere.

Gli indirizzi e-mail possono contenere solo alfabeti, numeri, “_”, “@” e “.”?

Sono autorizzati a contenere alfabeti non inglesi come “é” o “ü”?

Sono autorizzati a contenere caratteri cinesi o giapponesi o altri caratteri Unicode?

L’indirizzo email è composto da due parti local prima di @ e dal domain che segue.

Le regole per queste parti sono diverse:

Per local part puoi usare ASCII:

  • Lettere latine A – Z a – z
  • cifre da 0 a 9
  • caratteri speciali! # $% & ‘* + – / =? ^ _ `{|} ~
  • punto., che non è il primo o l’ultimo e non in sequenza
  • spazio e i caratteri “(),:; <> @ [] sono consentiti con restrizioni (sono consentiti solo all’interno di una stringa quotata, una barra rovesciata o una virgoletta devono essere preceduti da una barra rovesciata)
  • Inoltre dal 2012 è ansible utilizzare i caratteri internazionali sopra U+007F , codificati come UTF-8 .

Domain part è più limitata:

  • Lettere latine A – Z a – z
  • cifre da 0 a 9
  • trattino -, che non è il primo o l’ultimo, sono consentiti più trattini in sequenza.

Regex da convalidare

^(([^<>()\[\]\.,;:\[email protected]\"]+(\.[^<>()\[\]\.,;:\[email protected]\"]+)*)|(\".+\"))@(([^<>()[\]\.,;:\[email protected]\"]+\.)+[^<>()[\]\.,;:\[email protected]\"]{2,})

Spero che questo ti salvi un po ‘di tempo.

Beh si. Leggi (almeno) questo articolo da Wikipedia.

Vivo in Argentina e qui sono consentite email come ñoñó[email protected]

La syntax consentita in un indirizzo di posta elettronica è descritta nella RFC 3696 ed è piuttosto coinvolta.

La regola esatta [per la parte locale; la parte prima di ‘@’] è che qualsiasi carattere ASCII, inclusi i caratteri di controllo, può apparire tra virgolette o in una stringa quotata. Quando è necessario quotare, il carattere backslash viene utilizzato per citare il seguente carattere
[…]
Senza virgolette, le parti locali possono essere composte da qualsiasi combinazione di caratteri alfabetici, cifre o uno qualsiasi dei caratteri speciali! # $% & ‘* + – / =? ^ _ `. {| } ~
[…]
Qualsiasi carattere o combinazione di bit (come ottetti) sono consentiti nei nomi DNS. Tuttavia, esiste una forma preferita richiesta dalla maggior parte delle applicazioni …

… e così via, in una certa misura.

Invece di preoccuparti di quali indirizzi email possono e non possono contenere, cosa a cui non ti importa, prova se la tua configurazione può inviarli via email o meno: questo è ciò che ti interessa davvero! Ciò significa in realtà l’invio di un’email di verifica.

Altrimenti, non puoi cogliere un caso molto più comune di refusi accidentali che rimangono all’interno di un set di caratteri che hai ideato. (Veloce: [email protected] è un indirizzo valido che posso usare sul tuo sito o no?) Evita anche di allontanare inutilmente e gratuitamente tutti gli utenti quando dici che il loro indirizzo perfettamente valido e corretto è sbagliato. Potresti ancora non essere in grado di elaborare alcuni indirizzi (questa è un’alienazione necessaria), come le altre risposte dicono: l’elaborazione dell’indirizzo email non è banale; ma è qualcosa che hanno bisogno di scoprire se vogliono fornirti un indirizzo email!

Tutto quello che dovresti controllare è che l’utente fornisce del testo prima di un @, del testo dopo, e l’indirizzo non è scandalosamente lungo (ad esempio 1000 caratteri). Se si desidera fornire un avviso (“questo sembra guai! C’è un refuso? Doppio controllo prima di continuare”), va bene, ma non dovrebbe bloccare il processo add-email-address.

Certo, se non ti interessa mandare mai una email a loro, prendi semplicemente tutto ciò che entrano. Ad esempio, l’indirizzo potrebbe essere utilizzato esclusivamente per Gravatar , ma Gravatar verifica comunque tutti gli indirizzi di posta elettronica.

C’è la possibilità di avere indirizzi email non ASCII, come mostrato da questo RFC: http://tools.ietf.org/html/rfc3490 ma penso che questo non sia stato impostato per tutti i paesi, e da quello che capisco solo uno il codice di lingua sarà consentito per ogni paese, e c’è anche un modo per trasformarlo in ASCII, ma questo non sarà un problema banale.

Ho incontrato indirizzi e-mail con virgolette singole e non di rado. Rifiutiamo lo spazio bianco (sebbene sia strettamente consentito), più di un ‘@’ stringhe di segno e indirizzo più corte di cinque caratteri in totale. Credo che questo risolva più problemi di quanti ne crei, e finora oltre dieci anni e diverse centinaia di migliaia di indirizzi ha funzionato per rifiutare molti indirizzi spazzatura. Inoltre c’è un trigger per il downcase di tutti gli indirizzi e-mail su insert o update.

Detto questo, è imansible convalidare un’e-mail senza un giro di andata al proprietario, ma almeno possiamo rifiutare dati estremamente sospetti.