چرا اعتبارسنجی ایمیل با Regex هیچ‌وقت کامل نیست
آموزش

چرا اعتبارسنجی ایمیل با Regex هیچ‌وقت کامل نیست

هر regexی که برای ایمیل بنویسید یا کاربرهای واقعی را رد می‌کند یا ورودی خراب را قبول؛ نمی‌شود هر دو را داشت

تحریریه‌ی دینا کد
نویسنده
۳ دقیقه مطالعه۱ بازدید
اشتراک گذاری۱
فهرست مطالب
  1. ۱regexی که کلاس‌ها یاد می‌دهد، کاربر واقعی را رد می‌کند
  2. ۲یک regex شل‌تر، اکثر موارد واقعی را می‌گیرد
  3. ۳ولی این هم چیزهایی را که باید رد نمی‌کند
  4. ۴راهی که واقعاً جواب می‌دهد
  5. ۵اگر فرم HTML دارید، یک لایه‌ی رایگان از قبل هست

با regex فقط فرمت ایمیل را چک کنید؛ اینکه واقعاً وجود دارد یا نه را نمی‌شود فهمید. آن regex را هم عمداً شل بگیرید؛ سخت‌گیری بیشتر معمولاً یعنی رد کردن کاربرهای واقعی، نه گرفتن ورودی خراب بیشتر.

regexی که کلاس‌ها یاد می‌دهد، کاربر واقعی را رد می‌کند

jsconst naive = /^[a-zA-Z0-9]+@[a-zA-Z0-9]+\.[a-zA-Z]+$/;

naive.test('sara.ahmadi@example.com');     // false، نقطه در قسمت قبل از @ مجاز نیست
naive.test('reza+newsletter@example.com'); // false، + هم همین‌طور
naive.test('user@mail.example.co');        // false، دو نقطه در دامنه رد می‌شود

هر سه شکل رایجِ آدرس ایمیل واقعی رد می‌شوند: آدرس با نقطه در قسمت اول، آدرس با + برای فیلتر کردن (خیلی‌ها همین را برای ایمیل‌های موقت استفاده می‌کنند) و آدرس با ساب‌دامین. کاربری که این خطا را می‌بیند فکر می‌کند فرم خراب است، نه اینکه خودش اشتباه کرده.

یک regex شل‌تر، اکثر موارد واقعی را می‌گیرد

jsconst better = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

better.test('sara.ahmadi@example.com');     // true
better.test('reza+newsletter@example.com'); // true
better.test('user@mail.example.co');        // true

قانونش ساده است: هر چیزی که فاصله و @ نداشته باشد، بعد یک @، بعد هر چیزی که فاصله و @ نداشته باشد و حداقل یک نقطه در آن باشد.

ولی این هم چیزهایی را که باید رد نمی‌کند

jsbetter.test('trailing-dot@example.com.'); // true، درحالی‌که نقطه‌ی اضافه در آخر دامنه دارد

هیچ regex عملی‌ای نیست که همه‌ی موارد نامعتبر واقعی را بگیرد و هیچ کاربر واقعی را رد نکند. استانداردی که «ایمیل معتبر» را تعریف می‌کند (RFC 5322 و پیشینه‌اش RFC 822) چنان پیچیده است که regexی کاملاً منطبق بر آن چند هزار کاراکتر طول می‌کشد؛ نویسنده‌ی مشهورترین پیاده‌سازی هم صریح نوشته بود که اعتبارسنجی ایمیل با regex از مرزِ عقلانی‌بودنِ کار با این ابزار عبور می‌کند.

راهی که واقعاً جواب می‌دهد

فرمت را با یک regex شل چک کنید و هدفش فقط گرفتن غلط‌های تایپی آشکار باشد، مثل ایمیل بدون @. بعد واقعاً بفرستید؛ یک لینک تأیید به همان آدرس. این تنها راهی است که ثابت می‌کند آدرس هم درست است و هم متعلق به همان کاربر؛ چیزی که هیچ regexی، هرقدر هم پیچیده، نمی‌تواند تضمین کند.

اگر فرم HTML دارید، یک لایه‌ی رایگان از قبل هست

html<input type="email" required>

مرورگرها برای type="email" یک بررسی فرمت داخلی دارند و قبل از submit شدن فرم جلوی خیلی از ورودی‌های آشکارا خراب را بدون هیچ regexی می‌گیرند. این جای‌گزین چک سمت سرور نیست (کاربر می‌تواند جاوااسکریپت را دور بزند)، ولی برای تجربه‌ی کاربر یک قدم رایگان است که خیلی از پروژه‌ها فراموشش می‌کنند.

اگر می‌خواهید خودِ regex را عمیق‌تر یاد بگیرید (گروه‌ها، quantifierها، lookahead)، دوره‌ی Regex با تمرین‌های واقعی همین الگوها را جا می‌اندازد.

تحریریه‌ی دینا کد
نویسنده

نظرها

اولین نفری باشید که نظر می‌دهد
برای ثبت نظر وارد شوید

سؤالتان را بپرسید یا تجربه‌تان را بنویسید تا نویسنده‌ی مطلب پاسخ بدهد.

مطالب مرتبط

از همین دسته
مدیریت خطا با try و except در پایتون
آموزش

مدیریت خطا با try و except در پایتون

راهنمای گام‌به‌گام مهار خطاهای زمان اجرا در پایتون با بلوک‌های try و except همراه با بررسی خطاهای رایج و ساختار اصولی.

تحریریه‌ی دینا کد۵ دقیقه
مدیریت خطا در Rust با Result و Option
آموزش

مدیریت خطا در Rust با Result و Option

زبان Rust به جای ساختارهای سنتی استثنا از نوع‌های Result و Option برای مدیریت شفاف و پیش‌بینی‌پذیر خطاها در زمان کامپایل استفاده می‌کند.

تحریریه‌ی دینا کد۶ دقیقه
تفاوت واحدهای px و em و rem در CSS و کاربرد هرکدام
آموزش

تفاوت واحدهای px و em و rem در CSS و کاربرد هرکدام

واحدهای px، em و rem هرکدام برای بخش مشخصی از صفحه‌آرایی وب طراحی شده‌اند و انتخاب نادرست آن‌ها مقیاس‌پذیری و دسترسی‌پذیری سایت را مختل می‌کند.

تحریریه‌ی دینا کد۶ دقیقه