Email Regex: الگوهایی برای اعتبارسنجی آدرس‌های ایمیل

شما یک فرم ثبت نام ساخته‌اید و شخصی عبارت «john@» را در فیلد ایمیل وارد می‌کند. اگر اعتبارسنجی انجام نشود، آن مقدار مستقیماً وارد پایگاه داده شما می‌شود، انگار که هیچ مشکلی وجود ندارد. سپس کمپین بعدی شما به آن ارسال می‌کند، ESP شما یک پرش شدید را ثبت می‌کند و اعتبار فرستنده شما به دلیل خطایی که کاملاً قابل اجتناب بود، ضربه کوچکی می‌خورد.

عبارت منظم ایمیل اولین لایه دفاعی در برابر این نوع داده‌های بد است. این یک قانون تطبیق الگو است که بررسی می‌کند آیا یک ورودی قبل از ذخیره یا پردازش، شبیه یک آدرس ایمیل با ساختار صحیح است یا خیر. درک نحوه کار عبارت منظم ایمیل و همچنین نقاط ضعف آن، به شما کمک می‌کند تا اعتبارسنجی قابل اعتمادتری را در سیستم‌های خود ایجاد کنید.

ایمیل با ریجکس چیست؟

یک عبارت منظم (regex) دنباله ای از کاراکترها است که یک الگوی جستجو را تعریف می کند. یک عبارت منظم ایمیل الگویی است که به طور خاص برای مطابقت با رشته هایی که با ساختار یک آدرس ایمیل معتبر مطابقت دارند، نوشته شده است.

وقتی کاربر فرمی را ارسال می‌کند، عبارت منظم (regex) بر اساس ورودی اجرا می‌شود. اگر رشته با الگو مطابقت داشته باشد (کاراکترهای صحیح، نماد @ در جای مناسب، ساختار دامنه معتبر)، پذیرفته می‌شود. اگر مطابقت نداشته باشد، فرم می‌تواند ورودی را رد کند و از کاربر بخواهد آن را اصلاح کند.

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

چرا ایمیل‌های با عبارات منظم (Regex) اهمیت دارند؟

هر آدرس نامعتبری که وارد پایگاه داده شما می‌شود، یک مشکل در مراحل بعدی ایجاد می‌کند. این امر به افزایش نرخ پرش (bounce rate)، اختلال در گزارش‌دهی شما و هدر رفتن اعتبار ارسال برای مخاطبینی که هرگز نمی‌توانند پیام‌های شما را دریافت کنند، کمک می‌کند.

اعتبارسنجی Regex واضح‌ترین خطاها را در منبع شناسایی می‌کند: از دست دادن علامت @، خالی بودن قسمت‌های محلی و نام‌های دامنه‌ی ناقص. با فیلتر کردن این موارد در نقطه‌ی ورود، پایگاه داده‌ی خود را بدون ایجاد هیچ گونه اصطکاکی در فرآیندهای backend خود، تمیزتر نگه می‌دارید.

این تأثیر در چندین تیم اجرا می‌شود. برای بازاریابان، دریافت پاک‌تر به معنای قابلیت تحویل بهتر از ابتدا است. برای مهندسان محصول، این یک بررسی ساده و با تأخیر کم است که بدون هیچ گونه فراخوانی API خارجی، در سمت کلاینت یا سمت سرور اجرا می‌شود. برای تیم‌های داده، حجم رکوردهایی را که نیاز به بررسی دستی یا اصلاح در مراحل بعدی دارند، کاهش می‌دهد.

با این اوصاف، regex دقیقاً به این دلیل کارآمد است که سبک است؛ فقط فرمت را بررسی می‌کند. برای هر چیزی فراتر از آن، به لایه‌های اضافی نیاز دارید.

نحوه کار ایمیل Regex

Regex با تطبیق یک رشته متنی با یک الگوی تعریف شده، کاراکتر به کاراکتر، کار می‌کند. هر بخش از الگو، آنچه را که مجاز است شرح می‌دهد: کاراکترهای خاص، کلاس‌های کاراکتر، قوانین تکرار یا توالی‌های مورد نیاز.

برای یک آدرس ایمیل، الگو باید سه بخش ساختاری را در نظر بگیرد:

1. بخش محلی: هر چیزی قبل از نماد @ (مثلاً john.doe)
2. علامت @: دقیقاً یکی، در موقعیت درست
3. دامنه: نام دامنه و TLD بعد از @ (مثلاً example.com)

یک عبارت منظم (regex) ساده برای ایمیل، بررسی می‌کند که هر سه بخش وجود داشته باشند و کاراکترهای هر بخش مجاز باشند. برای مثال، الگوی ^[^\s@]+@[^\s@]+\.[^\s@]+$ به این صورت خوانده می‌شود: شروع رشته، یک یا چند کاراکتر که فاصله یا @ نیستند، سپس یک @، سپس کاراکترهای غیر فاصله/غیر @ بیشتر، سپس یک نقطه، سپس کاراکترهای غیر فاصله/غیر @ بیشتر، پایان رشته.

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

قوانین رایج مورد استفاده در Regex ایمیل

الگوهای regex ایمیل از مجموعه‌ای از قوانین عملی پیروی می‌کنند که ظاهر یک آدرس معتبر را تعریف می‌کنند. این قوانین تمام موارد خاص را پوشش نمی‌دهند، اما ساختاری را که اکثر سیستم‌ها برای اعتبارسنجی روزمره استفاده می‌کنند، منعکس می‌کنند.

قوانین محلی بخش (قبل از @):

• حروف (a-z، A-Z) و اعداد (0-9) مجاز هستند.
• کاراکترهای ویژه می‌توانند شامل نقطه (.)، زیرخط (_)، خط فاصله (-) و علامت جمع (+) باشند.
• بخش محلی نمی‌تواند با نقطه شروع یا پایان یابد.
• نقطه‌های پشت سر هم (..) مجاز نیستند.
• طول از نظر فنی طبق مشخصات RFC مربوطه، ۶۴ کاراکتر است.

قوانین دامنه (بعد از @):

• دامنه باید حداقل شامل یک نقطه باشد که نام دامنه را از TLD جدا کند (مثلاً example.com).
• برچسب‌های بین نقطه‌ها می‌توانند شامل حروف، ارقام و خط تیره باشند، اما نمی‌توانند با خط تیره شروع یا پایان یابند.
• دامنه سطح بالا (TLD) باید حداقل دو کاراکتر داشته باشد. اکثر الگوهای مدرن، دامنه‌های سطح بالا (TLD) با طول‌های مختلف را می‌پذیرند تا پسوندهای جدیدتری مانند .io، .museum یا .photography را پوشش دهند.

محدودیت‌های عمومی در کل آدرس:

• هیچ فاصله‌ای در هیچ کجای آدرس مجاز نیست.
• علامت @ باید دقیقاً یک بار ظاهر شود.
• طبق RFC 5321، طول کل آدرس نباید از 254 کاراکتر تجاوز کند.

انواع الگوهای Regex ایمیل

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

الگوهای ساده اصول اولیه را پوشش می‌دهند: یک بخش محلی، یک @، یک دامنه و یک TLD. نوشتن آنها سریع، خواندن آنها آسان است و برای اکثر موارد استفاده استاندارد مانند فرم‌های ثبت نام و فیلدهای تماس به خوبی کار می‌کنند. نکته منفی این است که آنها ممکن است برخی رشته‌ها را بپذیرند که از نظر فنی با قوانین حاشیه‌ای مطابقت ندارند و همچنین ممکن است به طور تصادفی آدرس‌های غیرمعمول اما معتبر را رد کنند.

یک الگوی ساده و پرکاربرد در جاوا اسکریپت به شکل زیر است:

/^[^\s@]+@[^\s@]+\.[^\s@]+$/

الگوهای پیچیده سعی می‌کنند مشخصات کامل ایمیل را دقیق‌تر پیاده‌سازی کنند. آن‌ها کاراکترهای مجاز را به صراحت تعریف می‌کنند، قوانین قرارگیری نقطه را اعمال می‌کنند، رشته‌های دارای علامت نقل قول را در بخش محلی در نظر می‌گیرند و حروف آدرس IP را در دامنه مدیریت می‌کنند. این الگوها دقیق‌تر هستند اما خواندن و نگهداری آن‌ها به طور قابل توجهی دشوارتر است.

الگویی با جزئیات بیشتر که در بسیاری از سیستم‌های تولیدی استفاده می‌شود:

/^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/

این مورد به صراحت کاراکترهای مجاز در بخش محلی را فهرست می‌کند، استفاده از خط فاصله در برچسب‌های دامنه را مجاز می‌داند و به یک TLD با حداقل دو کاراکتر نیاز دارد.

بده‌بستان عملی

الگوهای ساده راحت‌تر نگهداری می‌شوند و احتمال رد شدن کاذب کمتری دارند. الگوهای پیچیده، اجرای قالب دقیق‌تری را ارائه می‌دهند، اما سربار پیاده‌سازی را افزایش می‌دهند. برای اکثر موارد بازاریابی و استفاده از محصول، یک الگوی با پیچیدگی متوسط ​​که به خوبی آزمایش شده باشد، زمینه مورد نیاز شما را پوشش می‌دهد و تأیید بلادرنگ بقیه کار را انجام می‌دهد.

بهترین روش‌ها برای اعتبارسنجی ایمیل با Regex

Regex زمانی بهترین عملکرد را دارد که به عنوان بخشی از یک فرآیند اعتبارسنجی گسترده‌تر در نظر گرفته شود. الگویی که بیش از حد سختگیرانه باشد می‌تواند کاربران معتبر را مسدود کند، در حالی که الگویی که بیش از حد سست باشد، داده‌های نامناسب را عبور می‌دهد. هدف، ایجاد تعادلی است که در آن بررسی‌های قالب بدون ایجاد اصطکاک، قابل اعتماد باشند.

• الگوی خود را خوانا نگه دارید: یک عبارت منظم که هیچ‌کس در تیم شما بدون یک راهنما نمی‌تواند آن را تفسیر کند، یک ریسک نگهداری است. در بیشتر موارد، یک الگوی واضح و با جزئیات متوسط، کاربردی‌تر از الگویی است که سعی می‌کند با هر مورد حاشیه‌ای تعریف‌شده در استانداردهای RFC مطابقت داشته باشد.

• قبل از استقرار، طیف وسیعی از ورودی‌ها را آزمایش کنید: موارد حاشیه‌ای مانند آدرس‌هایی که در قسمت محلی علامت + دارند را لحاظ کنید ([ایمیل محافظت شده])، زیر دامنه‌ها ([ایمیل محافظت شده]) و TLD های جدیدتر ([ایمیل محافظت شده]الگویی که در ورودی‌های مشروع با شکست مواجه می‌شود، برای کاربران واقعی مشکل ایجاد می‌کند.
• ترکیب regex با تأیید اعتبار اضافی: Regex فرمت را تأیید می‌کند؛ اما نمی‌تواند وجود آدرس را تأیید کند. برای جریان‌های ثبت‌نام و وارد کردن لیست، اعتبارسنجی فرمت را با یک ایمیل تأیید یا یک درخواست آنی جفت کنید. تأیید ایمیل بررسی کنید. این آدرس‌های یکبار مصرف، غلط‌های املایی در دامنه و آدرس‌هایی که به درستی قالب‌بندی شده‌اند اما وجود ندارند را شناسایی می‌کند.
• اولویت بندی تجربه کاربری: اگر regex شما یک آدرس معتبر، مثلاً آدرسی با علامت بعلاوه یا یک TLD جدیدتر را رد کند، شما بدون اینکه بدانید یک مشترک واقعی را از دست می‌دهید. امن‌تر این است که در مرحله قالب‌بندی، ورودی کمی گسترده‌تر را مجاز کنید و برای فیلتر کردن آدرس‌هایی که قابل استفاده نیستند، به بررسی‌های بعدی تکیه کنید.

اشتباهات رایج و محدودیت‌های Regex ایمیل

درک اینکه regex ایمیل چه کارهایی را نمی‌تواند انجام دهد، به اندازه دانستن نحوه نوشتن آن مهم است.

• Regex فرمت را اعتبارسنجی می‌کند، نه وجود آن را: رشته ای مثل [ایمیل محافظت شده] از اکثر الگوهای regex ایمیل عبور می‌کند، اما این بدان معنا نیست که آدرس واقعی، فعال یا قابل تحویل است. regex هیچ اطلاعی از DNS، سرورهای ایمیل یا وجود واقعی صندوق پستی ندارد. بررسی‌های قالب و بررسی‌های قابلیت تحویل دو چیز جداگانه هستند.
• منفی‌های کاذب، رد آدرس‌های معتبر: برخی از آدرس‌های مشروع با الگوهای بیش از حد سختگیرانه شکست می‌خورند. آدرس‌هایی که در قسمت محلی آنها علامت + ([ایمیل محافظت شده]) برای اهداف فیلترینگ رایج هستند و کاملاً معتبر می‌باشند. اگر الگوی شما محدودیت TLD دو کاراکتری را اعمال کند، TLD های جدیدتر مانند .museum، .io یا .agency نیز ممکن است رد شوند. هر رد کاذب به معنای یک شخص واقعی است که نتوانسته ثبت نام کند.
• مثبت کاذب، پذیرش رشته‌های نامعتبر: الگوهای ساده می‌توانند رشته‌هایی را که به نظر درست می‌آیند اما درست نیستند، عبور دهند. برای مثال، user@example بسیاری از بررسی‌های اولیه را با موفقیت پشت سر می‌گذارد اما هیچ TLD معتبری ندارد. الگویی که حداقل طول TLD را اعمال نمی‌کند، آن را پذیرفته و یک آدرس غیرقابل تحویل ذخیره می‌کند.

• الگوهای بیش از حد پیچیده از هم می‌پاشند: الگوهایی که سعی در پیاده‌سازی مشخصات کامل ایمیل RFC 5322 دارند، می‌توانند تا صدها کاراکتر اجرا شوند و همچنان در موارد خاص با شکست مواجه شوند. آزمایش آنها دشوار است، اشکال‌زدایی آنها دشوار است و اغلب در تلاش برای حل مشکلات قدیمی، مشکلات جدیدی ایجاد می‌کنند. مشخصات ایمیل به خودی خود به اندازه‌ای پیچیده است که هیچ regex واحدی آن را به طور کامل پوشش نمی‌دهد.
• Regex اولین فیلتر است، نه راه حل کامل: این ابزار خطاهای قالب‌بندی را به سرعت و با هزینه کم تشخیص می‌دهد. برای هر چیزی فراتر از قالب‌بندی، از جمله اعتبار دامنه، رکوردهای MX، وجود صندوق پستی و تشخیص آدرس یکبار مصرف، به یک لایه تأیید نیاز دارید. بررسی‌هایی مانند جستجوی رکوردهای MX و اعتبارسنجی کامل ایمیل فراتر از regex می‌رود و تأیید می‌کند که آیا یک آدرس واقعاً می‌تواند پیام‌ها را دریافت کند یا خیر، نه اینکه فقط درست به نظر برسد.

خط پایین

regex ایمیل روشی سریع و سبک برای شناسایی خطاهای قالب‌بندی قبل از ورود آنها به سیستم شما ارائه می‌دهد. پیاده‌سازی آن روی هر فرم و نقطه پایانی API که ورودی ایمیل را می‌پذیرد، ارزشش را دارد. اما این اولین قدم در یک گردش کار اعتبارسنجی است، نه آخرین قدم.

یک آدرس با فرمت صحیح می‌تواند همچنان غیرفعال، یکبار مصرف، مرتبط با یک دامنه فراگیر یا به سادگی وجود نداشته باشد. این آدرس‌ها هر بار از regex عبور می‌کنند. هنگامی که در پایگاه داده شما قرار می‌گیرند، نرخ پرش شما را افزایش می‌دهند، بر روی بازدید شما تأثیر می‌گذارند. امنیت ایمیل وضعیت بدن، و کاهش قابلیت اطمینان کلی اطلاعات تماس شما.

لیست خود را در DeBounce آپلود کنید و فراتر از بررسی‌های قالب عمل کنید. DeBounce نحو را با استانداردهای RFC تأیید می‌کند، رکوردهای DNS و MX را بررسی می‌کند، وجود صندوق پستی را آزمایش می‌کند و انواع آدرس‌های یکبار مصرف و پرخطر را علامت‌گذاری می‌کند و آنچه را که regex نمی‌تواند تشخیص دهد، تشخیص می‌دهد. با ۱۰۰ تأیید رایگان شروع کنید تا قبل از ارسال بعدی، دقیقاً ببینید چه چیزی در لیست شما وجود دارد.