WordPress e core PHP
La is_email()
funzione Source è una tipica implementazione di WordPress e non funziona completamente con ciò che RFC 6531 consente. Un motivo potrebbe essere che la FILTER_VALIDATE_EMAIL
costante PHP predefinita per filter_var()
non è molto meglio nel validare qualcosa secondo le linee guida IETF® .
Standards
Il punto è che RFC 6531 consente "Caratteri Unicode oltre l'intervallo ASCII" . Vale a dire quelli sono (per la parte locale - prima del @
):
- Lettere inglesi maiuscole e minuscole (a – z, A – Z) (ASCII: 65–90, 97-122)
- Cifre
0
su 9
(ASCII: 48–57)
- Questi personaggi speciali:
! # $ % & ' * + - / = ? ^ _ ` { | } ~
- Carattere
.
(punto, punto, punto e virgola) (ASCII: 46) purché non sia il primo o l'ultimo carattere e purché non appaia consecutivamente (ad es. John..Doe@example.com
Non consentito).
- Sono ammessi caratteri speciali con restrizioni. Loro sono:
- Spazio e
"(),:;<>@[\]
(ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91–93)
- Le restrizioni per i caratteri speciali sono che devono essere usate solo se racchiuse tra virgolette e che 2 di esse (la barra rovesciata \ e le virgolette "(ASCII: 92, 34)) devono anche essere precedute da una barra rovesciata
\
(ad es. "\\"
E "\""
) .
- Sono consentiti commenti tra parentesi alle estremità della parte locale; ad esempio
john.smith(comment)@example.com
e (comment)john.smith@example.com
sono entrambi equivalenti a "john.smith@example.com"
, ma non john.(comment)smith@example.com
sarebbero validi.
- I caratteri internazionali sopra
U+007F
, codificati come UTF-8, sono consentiti da RFC 6531, sebbene i sistemi di posta elettronica possano limitare quali caratteri usare quando si assegnano parti locali.
e per la parte globale / dominio:
La parte del nome di dominio di un indirizzo e-mail deve essere conforme a rigide linee guida: deve corrispondere ai requisiti per un nome host, costituito da lettere, cifre, trattini e punti. Inoltre, la parte del dominio può essere un indirizzo IP letterale, circondata da parentesi quadre, come jsmith@[192.168.2.1]
o jsmith@[IPv6:2001:db8::1]
[…]
Fonte: Wikipedia
Cosa è valido
Questo può portare a indirizzi di posta elettronica strani ma validi come i seguenti:
localpart.ending.with.dot.@example.com
(comment)localpart@example.com
"this is v@lid!"@example.com
"much.more unusual"@example.com
postbox@com
admin@mailserver1
"()<>[]:,;\\@\"\\\\!#$%&\'*+-/=?^_`{}| ~.a"@example.org
" "@example.org
Fonte: php.net / autore gt@kani.hu - esempio risolto dall'autore di questo post
limiti
Esistono anche limiti di lunghezza locali e di dominio:
Il formato degli indirizzi e-mail è local-part@domain
dove la parte locale può contenere fino a 64 caratteri e il nome di dominio può avere un massimo di 253 caratteri , ma la lunghezza massima di 256 caratteri di un percorso in avanti o indietro limita l'intero indirizzo e-mail a non deve contenere più di 254 caratteri . [2] Le definizioni formali sono in RFC 5322 (sezioni 3.2.3 e 3.4.1) e RFC 5321 - con una forma più leggibile fornita nell'informativa RFC 3696 [3] e gli errori associati .
Fonte: Wikipedia
Restrizioni di WordPress
E questo è ciò che WordPress controlla per:
- Prova per la lunghezza minima che l'e-mail può essere:
strlen( $email ) < 3
- Prova un carattere @ dopo la prima posizione:
strpos( $email, '@', 1 ) === false
- Test per caratteri non validi:
!preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local )
- Test per sequenze di periodi:
preg_match( '/\.{2,}/', $domain )
- Test per periodi iniziali e finali e spazi bianchi:
trim( $domain, " \t\n\r\0\x0B." ) !== $domain
- Supponiamo che il dominio abbia almeno due sottotitoli:
$subs = explode( '.', $domain );
e quindi
2 > count( $subs )
trim( $sub, " \t\n\r\0\x0B-" ) !== $sub
!preg_match('/^[a-z0-9-]+$/i', $sub )
Fonte: WP Core v4.0
Filtri e convalida personalizzata
Tutti i casi sopra menzionati si innescheranno is_email()
per restituire false. Il risultato è in grado di filtrare (è possibile allegare un callback) e il filtro avrà tre argomenti, dove l'ultimo argomento è il motivo. Esempio:
return apply_filters( 'is_email', false, $email, 'sub_hyphen_limits' );
ciò significa che è possibile ignorare i risultati restituiti da controlli specifici.
Ciò consente di aggiungere controlli speciali, ad esempio per consentire domini Umlaut, parti di dominio solo TLD, ecc.
Conclusione
WordPress è sicuro per la maggior parte dei casi, ma più restrittivo in quanto i server di posta devono effettivamente essere conformi a RFC. Tenere presente che non tutti i server di posta si allineano alle linee guida RF 6531.
modificare
Funny sidefact: ci sono due funzioni correlate all'interno ~/wp-includes/formatting
: is_email()
e sanitize_email()
. Sono praticamente la stessa funzione. Non ho idea del perché qualcuno abbia deciso che sarebbe una buona idea copiare il contenuto della funzione da uno all'altro invece di aggiungere semplicemente uno come callback ai filtri che l'altro fornisce. Dal momento che v0.71 e poiché v1.5 sono uguali, personalmente userei il successivo quando otterrai una stringa pulita. Si noti che afferma persino che non è conforme a RFC.is_email()
sanitize_email()
is_email()