Angular.js: مدقق البريد الإلكتروني خاطئ

نعم ، أنت على حق ، يبدو أن EMAIL_REGEX خاطئ.

وفقًا لـ http://dev.w3.org/html5/markup/input.email.html ، يمكننا استخدام

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

ويبدو أنه يجب أن يعمل بشكل أفضل نظرًا لعدم تضمين . بعد @

سأحاول إرسال تصحيح سريع لهذا الغرض.

... في الواقع ، هذا أكثر تعقيدًا قليلاً مما كنت أعتقد أنه سيكون ، قد يستغرق المزيد من العمل. يبدو أنه سيقبل أيضًا regexps التي تبدأ بنقطة أيضًا. لذا أعتقد أن هناك القليل من العمل للقيام به هنا.

إذا تمكنت من حل هذا قبلي ، فلا تتردد في إرسال طلب سحب

شكرا لتقرير الشوائب. في العرض التوضيحي للمستندات ، لن تلاحظ هذا الإصلاح حتى يسقط 1.2.10 ، لأنه يقوم بتحميل البرنامج النصي الزاوي 1.2.9 طوال الوقت. ولكن في غضون أيام قليلة ، من المفترض أن ترى هذا تم تناوله في العرض التوضيحي للمستند (ما لم يتم التراجع عن الالتزام ، وهو ما قد يحدث O_O)

عظيم ، 10x!

يوم الأربعاء 22 كانون الثاني (يناير) 2014 الساعة 5:32 صباحًا ، كتبت كايتلين بوتر إخطارات github.com:

شكرا لتقرير الشوائب. في العرض التوضيحي للمستندات ، لن تلاحظ هذا الإصلاح
حتى يسقط 1.2.10 ، لأنه يقوم بتحميل البرنامج النصي الزاوي 1.2.9 طوال الوقت
ولكن في غضون أيام قليلة ، من المفترض أن ترى هذا العنوان في العرض التوضيحي للمستند

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/angular/angular.js/issues/5899#issuecomment -32990587
.

ماذا كان تعبير وجهي عندما لاحظت أن " dummy @ ferferfe " (بدون أي مجال) يعتبر بريدًا صالحًا ؛)

@ mica16 لكن dummy@ferferfe عنوان بريد إلكتروني صالح. لا تحتاج المجالات إلى امتداد ، فقط فكر في localhost .

Zequez صحيح ، ولكن من بحق الجحيم يستخدم عنوان المضيف

mbeckenbach استخدم
ng-pattern = "/ ^ [a-z0-9! # $٪ & '* + / =؟ ^ _` {|} ~ .-] + @ [a-z0-9 -] +. [a-z0 -9 -] / "
ليست مثالية ولكنها تعمل.

mbeckenbach نعم ، صحيح. لكن ضع في اعتبارك أن اسم المجال بدون نقاط هو مجال صالح. أن ICANN لن تسمح لك بتسجيل مجال مع THEM ، لا يعني أن اسم المجال غير صالح.

6 @ 6 ليس عنوان بريد إلكتروني. إن حقيقة أنه يمكن أن يكون عنوان بريد إلكتروني مناسبًا في ظروف خاصة لا ينبغي ، في رأيي ، أن تقودنا إلى السماح بذلك. احتمالات حدوث خطأ عبر هذا النمط المتساهل هي أوامر من حيث الحجم أكبر من احتمالات استبعاد شخص ما بعنوان بريد إلكتروني كهذا.

+1 لجيف

jeffmcmahan أنا آسف ولكن يبدو أنه يجب عليك تقديم مشكلة إلى IETF أو WHATWG. بمجرد أن يتغير تعريف شكل عنوان البريد الإلكتروني ، يجب تغييره في Angular ، لكننا نحتاج حقًا إلى اتباع ما هو موصوف في توصيات RFC و WHATWG.

الآن ، إذا كنت تريد أن تكون أكثر صرامة ، يمكنك أيضًا إضافة مدقق نمط ، سيكون ذلك جيدًا.

caitp أنت الرئيس.

ماذا عن جعل EMAIL_REGEXP قابلاً للتهيئة؟ التحقق من جانب الخادم الخاص بنا أكثر صرامة من angularjs. على وجه التحديد ، يتطلب ذلك ، على سبيل المثال ، ألا يزيد الجزء الذي يظهر قبل العلامة @ عن 63 حرفًا. الآن يتعين علينا إنشاء توجيه مخصص لجميع مدخلات البريد الإلكتروني أو تذكر إضافة نمط ng إلى كل إدخال بريد إلكتروني.

يمكنك استخدام نمط ng بالإضافة إلى type = email ، rjokelai - أيضًا ، سيؤدي تغيير خط أنابيب التحقق من صحة

"الآن ، إذا كنت تريد أن تكون أكثر صرامة بعض الشيء ، يمكنك أيضًا إضافة مدقق نمط ، سيكون ذلك جيدًا."

ماذا عن المدقق الافتراضي لا يقبل إلا رسائل البريد الإلكتروني العادية التي تحتوي على نقطة فيها ، وإذا أراد شخص ما في الأقلية الصغيرة أن يكون أقل صرامة ، فيمكنه عمل مدقق خاص به. لماذا يجب على الغالبية العظمى من المطورين أن يصنعوا نمطهم الخاص فقط حتى لا تضطر الأقلية الصغيرة إلى ذلك؟ هذه هي معايير النقاء سخيفة

لأن هذا في الأساس عبارة عن polyfill للتحقق من صحة قيود html5 ، لهذا السبب. نأمل في الأسبوع المقبل أن نشحن ميزة ستجعل تخصيص هذا أسهل بكثير

هل رسائل البريد الإلكتروني بدون منطقة المجال صالحة؟ أنا أختبر حقل إدخال بسيط من النوع = "email" وتقوم Angular بالتحقق من صحة _foo @ bar_ البريد الإلكتروني بنجاح. (الزاوي v1.3.0)

أوه ، هناك مشكلة مغلقة بالفعل - https://github.com/angular/angular.js/issues/9463

هل رسائل البريد الإلكتروني بدون منطقة المجال صالحة؟ أنا أختبر حقل إدخال بسيط من النوع = "email" وتقوم Angular بالتحقق من صحة البريد الإلكتروني foo @ bar بنجاح. (الزاوي v1.3.0)

إنها رسائل بريد إلكتروني صالحة ، حسب المواصفات. تمت الإجابة على هذا السؤال مرات عديدة في أداة تعقب هذه المشكلة ، ولا يوجد شيء غير صالح في البريد الإلكتروني بدون TLD.

استخدم أداة مصادقة مخصصة لطلب TLDs المحددة التي تريدها

caitp ، أدرك أننا كنا _0 @ 0_. وهذا يعني أنه سيتم استخدامه في حالة تسجيل النموذج القياسي ، وسيؤدي إلى مشاكل في العديد من هذه المواقف. وقد قيل لنا أن أهمية الالتزام بالمواصفات تفوق تلك المشكلات. حسنًا - رائع. لكن لماذا؟

لأنه سيكون غريبًا حقًا عندما يقول متصفحك أنه صالح ويقول الزاوي أنه ليس كذلك

أنت لا تبحث عن التحقق من صحة البريد الإلكتروني ، فأنت تبحث عن التحقق من صحة النمط فوق التحقق من صحة البريد الإلكتروني --- تريد عناوين بريد إلكتروني صالحة (يتم التعامل معها بواسطة الزاوية) والتي تطابق نمطًا معينًا (يحتوي على TLD)

1. هل سيكون الأمر غريبًا عندما تضيف التحقق من صحة النمط ثم "يقول متصفحك أنه صالح و [أ] يقول ngular أنه ليس كذلك"؟ لا ، فلماذا سيكون غريبًا إذا تم تضمين هذا التحقق من صحة النمط؟
2. نحن ندرك جميعًا أن ما يمر لبريد إلكتروني صالح في حالة الاستخدام الذي نهتم به أضيق من المواصفات.

_ أريد فقط معرفة سبب عدم استخدام Angular لحالة الاستخدام التي أهتم بها ، نظرًا لأنها الحالة العامة ._

فلماذا سيكون غريبًا إذا تم تضمين هذا التحقق من صحة النمط؟

في الواقع ، تحصل على نفس السلوك من المتصفح. http://jsfiddle.net/t6rdmngo/ إذا قمت بتشغيل هذا في متصفح حديث ، فلن تتمكن من إرسال النموذج العلوي بسبب عدم تطابق النمط إذا لم تقم بتضمين TLD.

في الإصدار الزاوي ، تحصل على نفس السلوك. هذا جيد. هذا ما نريده. السلوك المتطابق بين السلوك المحلي وسلوك الإطار. لا ينبغي أن يكون لإطار العمل خلافات مع النظام الأساسي

فهمت الان. شكرا لطرح معي!

يمكنك إصلاح هذا بسرعة باستخدام ng-pattern

<input type="email" ng-pattern="/^[_a-z0-9]+(\.[_a-z0-9]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$/">

إذا قمت بتغيير الأخير * إلى + في regex فإنه يعمل كما هو متوقع

http://w3c.github.io/html-reference/input.email.html

/ ^[a-zA-Z0-9.!#$٪&'*+/=؟]_`{|}~-]+@[a-zA-Z0-9-]+(؟:. -zA-Z0-9 -] +) + $ /