Maintenant que l'ICANN permet à l'ICANN des noms de domaine non latin-caractère, devrais-je vous préoccuper de la validation du courrier électronique? Actuellement, mes sites utilisent des fonctions PHP pour assurer un ensemble de caractères alphanumériques dans chaque segment d'une adresse électronique. Ces autres groupes de caractères seront-ils tels que la validation de la carte cyrillique, arabe et chinois? Existe-t-il des fonctions PHP recommandées à utiliser pour cela?
3 Réponses :
J'allais recommander d'utiliser filtre_var () < / Code> avec le filtre_validate_email filtre. Mais après une recherche Google, il se révèle ne prend pas en charge les multi-octets Personnages encore. On dirait que, pour l'instant, votre meilleur pari est de Dessier des caractères non latins et effectuer les validations habituelles contre cela (bien que checkdnsrr échouera évidemment depuis Vous avez changé le domaine en supprimant les caractères non latins et en les remplaçant par leurs équivalents latins afin que vous utilisiez cela pour vérifier les enregistrements MX du domaine de l'e-mail, vous devrez désactiver temporairement cela).
Filtre_validate_email semble également être excessivement strict, même lorsqu'il s'agit de caractères non multi-octets.
Filtre filtre_validate_email prend en charge Filtrer_flag_email_unicode Drapeau à partir de PHP 7.1. Veuillez noter que cela permet uniquement aux caractères Unicode dans la partie locale de l'adresse e-mail, comme indiqué dans la documentation ( php.net/manual/fr/... )
Je pense que le meilleur moyen d'utiliser une fonction IDN appropriée pour convertir la chaîne entrante en une chaîne ACE ( Il existe une fonction PHP nommée Il semble également y avoir une commande Linux externe nommée Si vous souhaitez utiliser des méthodes intégrées PHP uniquement, DelfueGo fournit une expression régulière dans question qui semble très bonne. xn-xyz-blah.com ). Si ce processus fonctionne, le nom de domaine est valide. Si ce n'est pas le cas, ce n'est pas le cas.
IDN_TO_ASCII ( ) qui fait cela, mais il a besoin de bibliothèques supplémentaires. Vous devriez voir s'il est disponible sur votre système.
IDN qui fait des conversions IDN. Je ne sais rien de plus à ce sujet, cependant.
Ce n'est pas l'ICANN permettant aux adresses électroniques non latines, mais l'arrivée de nouvelles normes provenant du corps de normalisation de l'IETF et de son groupe de travail "EAI".
Alors, oui, techniquement, aujourd'hui, Mais, beaucoup de codes existants, voire de nouveaux codes, n'accepteront pas ces cas. Bien sûr, il s'agit d'un problème de poulet et d'œufs parce que les personnes qui souhaitent utiliser cela et voir refus de nombreux sites reviendront à ASCII qui montrera une petite appétude pour non ASCII et donc peu d'évolution.
Il y a une initiative de l'ICANN à propos de tout cela appelé "acceptation universelle" qui se préoccupe non seulement avec des IDN, mais même avec de nouveaux GTLD, car il existe toujours des endroits difficiles à encadrer des TLDS et de ne pas réagir à de nouvelles TLD qui ont été ouverts de quelques années , ou avec une expression régulière idiote telle qu'un TLD doit être de 2 ou 3 caractères, ce qui ne va pas.
Vous pouvez le trouver à: https://uasg.tech/
C'est comme des conseils et des liens pour différents types de publics, à commencer par les développeurs et, par conséquent, la liste de choses à faire / ne pas faire.
Ils ont récemment publié un nouvel article, qui montrent les tendances de plus de 3 ans sur les sites visités les plus élevés basés sur Alexa et quels types d'adresses électroniques qu'ils permettent ou non: https://www.circleid.com/posts/20210712-Alception-On-All- noms de domaine-in-ouvert-source-logiciel /
Avec le rapport à https://uasg.tech /wp-content/uploads/documents/uasg033-fen-digital.pdf En plus de détails sur les bibliothèques Java et Python et leur manipulation des IDN. café@café.été est une adresse email valide: pièce de gauche non ASCII, domaine non ASCII, non ASCII TLD.
@John Conde: Vous l'avez déjà tapé, veuillez le poster afin que nous puissions uplifier autre chose que votre commentaire.
Eh bien, ce n'est pas une grande quantité d'une solution, mais au moins cela explique où PHP se tient actuellement avec cela. Espérons que le questionneur choisit des solutions pour leurs questions précédentes. Il y a de bonnes réponses en eux.
Pourquoi ne pas simplement envoyer un courrier électronique et que l'utilisateur confirme l'adresse en cliquant sur un lien? Vous allez vous épargnerez de gros mal de tête. Il n'y a pas de méthode sûre pour garantir que l'utilisateur vous donne une adresse appropriée. Même s'il est syntaxiquement correct, on peut toujours utiliser un mailinateur ou des services similaires pour fournir une adresse électronique valide (mais inutile pour vous). Alors, pourquoi la préoccupe la peine de vérifier?