ইমেল ঠিকানা প্রক্রিয়াকরণের জন্য Regex এর ব্যবহারিকতার উপর

একজন সহকর্মী সম্প্রতি আমাকে একটি ব্লগ পোস্টের দিকে নির্দেশ করেছেন: ইমেল রেজেক্স যাচাইকরণের অসারতার উপর । সংক্ষিপ্ততার জন্য, আমি এই নিবন্ধে এটিকে অসারতা হিসাবে উল্লেখ করব।

আমি স্বীকার করি যে একটি regex লেখার চ্যালেঞ্জ যা সফলভাবে সনাক্ত করতে পারে যে একটি স্ট্রিং একটি ইন্টারনেট মেসেজ হেডারের RFC 5322 সংজ্ঞার সাথে সামঞ্জস্যপূর্ণ কিনা তা একটি বিনোদনমূলক চ্যালেঞ্জ, কিন্তু বাস্তব প্রোগ্রামারদের জন্য Futility একটি দরকারী গাইড নয়।

কারণ এটি RFC 5322 বার্তা শিরোনামকে RFC 5321 ঠিকানা লিটারেলের সাথে একত্রিত করে; যার, সহজ ভাষায়, মানে হল যে একটি বৈধ SMTP ইমেল ঠিকানা যা সাধারণভাবে একটি বৈধ বার্তা শিরোনাম গঠন করে তার থেকে আলাদা।

এটি এমনও কারণ এটি পাঠককে প্রান্তের ক্ষেত্রে প্ররোচিত হতে উদ্বুদ্ধ করে যা তাত্ত্বিকভাবে মানদন্ডের দৃষ্টিকোণ থেকে সম্ভব, কিন্তু যা আমি প্রদর্শন করব, "বন্যে" ঘটার অসীম সম্ভাবনা রয়েছে।

এই নিবন্ধটি এই উভয় দাবির উপর প্রসারিত হবে, ইমেল রেজেক্সের জন্য কয়েকটি সম্ভাব্য ব্যবহারের ক্ষেত্রে আলোচনা করবে এবং ব্যবহারিক ইমেল রেজেক্সের টীকাযুক্ত "কুকবুক" উদাহরণ দিয়ে শেষ হবে।

RFC 5321 Supersedes 5322

ইমেল ট্রান্সমিশনের জন্য SMTP-এর সার্বজনীনতার অর্থ হল একটি ব্যবহারিক বিষয় হিসাবে, প্রাসঙ্গিক IETF RFC, যা 5321-এর কাছাকাছি পড়া ছাড়া ইমেল ঠিকানা বিন্যাসের কোনও পরীক্ষা সম্পূর্ণ হয় না।

5322 ইমেল ঠিকানাগুলিকে শুধুমাত্র একটি জেনেরিক বার্তা শিরোনাম হিসাবে বিবেচনা করে যেখানে এটিতে প্রযোজ্য কোনও বিশেষ ক্ষেত্রে নিয়ম নেই৷ এর মানে হল যে বন্ধনীতে আবদ্ধ মন্তব্যগুলি বৈধ, এমনকি একটি ডোমেন নামেও।

Futility- তে উল্লেখ করা টেস্ট স্যুটে 10টি পরীক্ষা রয়েছে যেগুলিতে মন্তব্য, অথবা ডায়াক্রিটিকাল বা ইউনিকোড অক্ষর রয়েছে এবং নির্দেশ করে যে তাদের মধ্যে 8টি বৈধ ইমেল ঠিকানার প্রতিনিধিত্ব করে।

এটি ভুল কারণ RFC 5321 স্পষ্টভাবে বলে যে ইমেল ঠিকানাগুলির ডোমেন নামের অংশগুলি " ASCII অক্ষর সেট থেকে আঁকা অক্ষর, অঙ্ক এবং হাইফেনের একটি ক্রম নিয়ে গঠিত SMTP উদ্দেশ্যে সীমাবদ্ধ। "

একটি রেগুলার এক্সপ্রেশন নির্মাণের প্রেক্ষাপটে, এই সীমাবদ্ধতাটি যে মাত্রায় বিষয়গুলিকে সরল করে, বিশেষ করে অত্যধিক স্ট্রিং দৈর্ঘ্য নির্ধারণের ক্ষেত্রে তা বাড়াবাড়ি করা কঠিন। উদাহরণগুলির টীকা নীচে এটি হাইলাইট করবে।

এটি বৈধকরণের প্রেক্ষাপটে কিছু অন্যান্য ব্যবহারিক বিবেচনাকেও বোঝায় যা আমরা আরও অন্বেষণ করব।

বন্য মধ্যে মেইলবক্স নাম

উভয় RFC অনুযায়ী, “@” চিহ্নের বাম দিকে ইমেল ঠিকানার অংশের প্রযুক্তিগত নাম হল “মেইলবক্স”। উভয় RFCই মেইলবক্স অংশে কোন অক্ষর অনুমোদনযোগ্য তা যথেষ্ট অক্ষাংশের অনুমতি দেয়।

একমাত্র উল্লেখযোগ্য ব্যবহারিক সীমাবদ্ধতা হল উদ্ধৃতি বা বন্ধনী অবশ্যই ভারসাম্যপূর্ণ হতে হবে, যা ভ্যানিলা রেজেক্সে যাচাই করা একটি বাস্তব চ্যালেঞ্জ।

তবে বাস্তব-বিশ্বের মেলবক্স বাস্তবায়ন আবার এমন একটি পরিমাপ যা ব্যবহারিক প্রোগ্রামারকে নিয়োগ করা উচিত।

একটি নিয়ম হিসাবে, যারা আমাদের বিলযোগ্য ঘন্টার 90% ভ্রুকুটি করেন তারা 10% তাত্ত্বিক প্রান্তের মামলাগুলি সমাধান করার জন্য নির্দেশিত হচ্ছে যা সম্ভবত বাস্তব জীবনে একেবারেই বিদ্যমান নাও হতে পারে।

আসুন প্রভাবশালী ইমেল মেইলবক্স প্রদানকারী, ভোক্তা এবং ব্যবসার দিকে তাকাই এবং বিবেচনা করি যে তারা কোন ধরনের ইমেল ঠিকানা অনুমোদন করে।

ভোক্তা ইমেলের জন্য, আমি টুইটার অ্যাকাউন্ট থেকে ফাঁস হওয়া 5,280,739 ইমেল ঠিকানাগুলির একটি তালিকা ব্যবহার করে কিছু প্রাথমিক গবেষণা করেছি।

115 মিলিয়ন টুইটার অ্যাকাউন্টের উপর ভিত্তি করে, এটি টুইটারের সমগ্র জনসংখ্যার জন্য ত্রুটির 0.055% মার্জিন সহ 99% আত্মবিশ্বাসের স্তর দেয়, যা সমস্ত ইন্টারনেট ইমেল ঠিকানার সাধারণ জনসংখ্যার খুব প্রতিনিধিত্ব করবে। আমি যা শিখেছি তা এখানে:

• 82% ঠিকানায় শুধুমাত্র ASCII আলফানিউমেরিক অক্ষর রয়েছে,

• 15% তে শুধুমাত্র ASCII বর্ণানুক্রমিক এবং বিন্দু (ASCII পিরিয়ড) রয়েছে, 97% সমস্ত ঠিকানার জন্য,

• নামমাত্র 100% ইমেল ঠিকানার জন্য 3%-এ শুধুমাত্র ASCII আলফানিউমেরিক, ডট এবং ড্যাশ রয়েছে।

যাইহোক, এটি একটি বৃত্তাকার 100%। সেখানে ট্রিভিয়া প্রেমীদের জন্য, আমি এটিও পেয়েছি:

• মোট 0.00072% আন্ডারস্কোর সহ 38 টি ঠিকানা

• 0.00051% এর জন্য প্লাস চিহ্ন সহ 27, এবং

• ইউনিকোড অক্ষর সহ 1 ঠিকানা মোটের 0.00002% প্রতিনিধিত্ব করে।

নেট ইফেক্ট হল যে অনুমান করা ইমেল ঠিকানা মেলবক্সে শুধুমাত্র ASCII বর্ণানুক্রমিক, ডট এবং ড্যাশ রয়েছে আপনাকে ভোক্তা ইমেলের জন্য 5 9 এর নির্ভুলতার চেয়ে ভাল দেবে।

ব্যবসায়িক ইমেলের জন্য, Datanyze রিপোর্ট করে যে 6,771,269 কোম্পানি 91টি ভিন্ন ইমেল হোস্টিং সমাধান ব্যবহার করে। তবে প্যারেটো ডিস্ট্রিবিউশন ধারণ করে, এবং সেই মেলবক্সগুলির 95.19% মাত্র 10 পরিষেবা প্রদানকারী দ্বারা হোস্ট করা হয়।

ব্যবসার জন্য Gmail (34.35% মার্কেট শেয়ার)

একটি মেলবক্স তৈরি করার সময় Google শুধুমাত্র ASCII অক্ষর, সংখ্যা এবং বিন্দুর অনুমতি দেয়৷ তবে ইমেল পাওয়ার সময় এটি প্লাস চিহ্নটি গ্রহণ করবে।

Microsoft Exchange অনলাইন (33.60%)

শুধুমাত্র ASCII অক্ষর, সংখ্যা এবং বিন্দুর অনুমতি দেয়।

GoDaddy ইমেল হোস্টিং (14.71%)

Microsoft 365 ব্যবহার করে, এবং শুধুমাত্র ASCII অক্ষর, সংখ্যা এবং বিন্দুকে অনুমতি দেয়।

7 অতিরিক্ত প্রদানকারী (12.53%)

নথিভুক্ত নয়।

দুর্ভাগ্যবশত, আমরা শুধুমাত্র 82% ব্যবসার বিষয়ে নিশ্চিত হতে পারি এবং আমরা জানি না যে কতগুলি মেলবক্স প্রতিনিধিত্ব করে। যাইহোক, আমরা জানি যে টুইটার ইমেল ঠিকানাগুলির মধ্যে, 173,467 ডোমেনের মধ্যে মাত্র 400টিতে 100 টিরও বেশি পৃথক ইমেল মেলবক্স প্রতিনিধিত্ব করা হয়েছে।

আমি বিশ্বাস করি যে 99% অবশিষ্ট ডোমেনের বেশিরভাগই ছিল ব্যবসায়িক ইমেল ঠিকানা।

সার্ভার বা ডোমেন স্তরে মেলবক্স নামকরণ নীতির পরিপ্রেক্ষিতে, আমি প্রস্তাব করছি যে এই 237,592 ইমেল ঠিকানাগুলিকে 1 বিলিয়ন ব্যবসায়িক ইমেল ঠিকানার জনসংখ্যার প্রতিনিধিত্বকারী হিসাবে গ্রহণ করা 99% আত্মবিশ্বাসের স্তর এবং 0.25% ত্রুটির মার্জিন, আমাদের দেওয়া যুক্তিসঙ্গত। 3 9 এর কাছাকাছি যখন অনুমান করা হয় যে একটি ইমেল ঠিকানা মেইলবক্সে শুধুমাত্র ASCII বর্ণানুক্রমিক, বিন্দু এবং ড্যাশ থাকে।

ব্যবহারের ক্ষেত্রে

আবার, আমাদের মনের মধ্যে ব্যবহারিকতার সাথে সর্বাগ্রে, আসুন আমরা বিবেচনা করি যে কোন পরিস্থিতিতে আমাদের একটি বৈধ ইমেল ঠিকানা প্রোগ্রাম্যাটিকভাবে সনাক্ত করতে হবে।

নতুন অ্যাকাউন্ট তৈরি/ব্যবহারকারী সাইনআপ

এই ব্যবহারের ক্ষেত্রে, একজন সম্ভাব্য নতুন গ্রাহক একটি অ্যাকাউন্ট তৈরি করার চেষ্টা করছেন। দুটি উচ্চ-স্তরের কৌশল রয়েছে যা আমরা বিবেচনা করতে পারি। প্রথম ক্ষেত্রে, আমরা যাচাই করার চেষ্টা করি যে নতুন ব্যবহারকারীর দেওয়া ইমেল ঠিকানাটি বৈধ এবং সিঙ্ক্রোনাসভাবে অ্যাকাউন্ট তৈরির সাথে এগিয়ে চলুন।

আপনি এই পদ্ধতিটি নিতে চান না কেন দুটি কারণ রয়েছে। প্রথমটি হল যদিও আপনি ইমেল ঠিকানার একটি বৈধ ফর্ম আছে তা যাচাই করতে সক্ষম হতে পারেন, তবুও এটি বিদ্যমান নাও থাকতে পারে।

অন্য কারণ হল যে কোনও ধরণের স্কেলে, সিঙ্ক্রোনাস হল একটি লাল পতাকা শব্দ, যা বাস্তববাদী প্রোগ্রামারকে একটি ফায়ার-এন্ড-ফোরগেট মডেল বিবেচনা করতে হবে যেখানে একটি স্টেটলেস ওয়েব ফ্রন্ট এন্ড একটি মাইক্রোসার্ভিস বা API এর কাছে ফর্ম তথ্য পাস করবে অ্যাসিঙ্ক্রোনাসভাবে একটি অনন্য লিঙ্ক পাঠিয়ে ইমেলটি যাচাই করুন যা অ্যাকাউন্ট তৈরির প্রক্রিয়াটি সম্পূর্ণ করতে ট্রিগার করবে।

যোগাযোগ ফর্ম

একটি সাধারণ যোগাযোগ ফর্মের ক্ষেত্রে, সাদা কাগজগুলি ডাউনলোড করতে প্রায়শই ব্যবহৃত হয়, এমন স্ট্রিংগুলি গ্রহণ করার সম্ভাব্য নেতিবাচক দিক যা একটি বৈধ ইমেলের মতো দেখায় কিন্তু তা নয় যে আপনি যাচাই করতে ব্যর্থ হয়ে আপনার বিপণন ডাটাবেসের গুণমান হ্রাস করছেন যদি ইমেল ঠিকানা সত্যিই বিদ্যমান.

তাই আবার, ফায়ার-এন্ড-ফোরগেট মডেলটি একটি ফর্মে প্রবেশ করা স্ট্রিংয়ের প্রোগ্রাম্যাটিক বৈধতার চেয়ে একটি ভাল বিকল্প।

রেফারার লগের পার্সিং এবং ডেটার অন্যান্য বড় ভলিউম।

এটি আমাদের সাধারণভাবে প্রোগ্রাম্যাটিক ইমেল ঠিকানা সনাক্তকরণের জন্য বাস্তব ব্যবহারের ক্ষেত্রে এবং বিশেষ করে রেজেক্সের দিকে নিয়ে যায়: অসংগঠিত পাঠ্যের বড় অংশ বেনামী করা বা মাইনিং করা।

আমি প্রথম এই ব্যবহারের ক্ষেত্রে একটি নিরাপত্তা গবেষককে সহায়তা করার জন্য এসেছি যাকে একটি জালিয়াতি সনাক্তকরণ ডাটাবেসে রেফারার লগ আপলোড করতে হবে৷ রেফারার লগগুলিতে এমন ইমেল ঠিকানা রয়েছে যা কোম্পানির দেয়াল ঘেরা বাগান ছেড়ে যাওয়ার আগে বেনামে থাকা দরকার।

এগুলি কয়েক মিলিয়ন লাইনের ফাইল ছিল এবং প্রতিদিন শত শত ফাইল ছিল। "লাইন" এক হাজার অক্ষরের কাছাকাছি হতে পারে।

একটি লাইনে অক্ষরের মাধ্যমে পুনরাবৃত্তি করা, জটিল পরীক্ষা প্রয়োগ করা (যেমন, এটি কি লাইনে @ এর প্রথম ঘটনা এবং এটি কি একটি ফাইল নামের অংশ যেমন [email protected] ?) লুপ ব্যবহার করে এবং স্ট্যান্ডার্ড স্ট্রিং ফাংশন তৈরি করা হত একটি সময় জটিলতা যা অসম্ভব বড় ছিল।

আসলে, এই (খুব বড়) কোম্পানির অভ্যন্তরীণ উন্নয়ন দল এটিকে একটি অসম্ভব কাজ বলে ঘোষণা করেছিল।

আমি নিম্নলিখিত সংকলিত regex লিখেছি:

search_pattern = re.compile("[a-zA-Z0-9\!\#\$\%\'\*\+\-\^\_\`\{\|\}\~\.]+@|\%40(?!(\w+\.)**(jpg|png))(([\w\-]+\.)+([\w\-]+)))")

এবং এটি নিম্নলিখিত পাইথন তালিকা বোঝার মধ্যে ফেলে দিয়েছে:

results = [(re.sub(search_pattern, "[email protected]", line)) for line in file]

আমি ঠিক কতটা দ্রুত মনে করতে পারি না, তবে এটি দ্রুত ছিল। আমার বন্ধু এটি একটি ল্যাপটপে চালাতে পারে এবং কয়েক মিনিটের মধ্যে এটি করা যেতে পারে। এটা সঠিক ছিল. আমরা এটা ঘড়ি 5 9 এ মিথ্যা নেতিবাচক এবং মিথ্যা ইতিবাচক উভয় দিকে তাকিয়ে.

রেফারার লগ হিসাবে আমার কাজ কিছুটা সহজ করা হয়েছিল; তারা শুধুমাত্র URL "আইনি" অক্ষর ধারণ করতে পারে, তাই আমি রেপো রিডমিতে নথিভুক্ত যে কোনও সংঘর্ষের মানচিত্র তৈরি করতে সক্ষম হয়েছি।

এছাড়াও, আমি এটিকে আরও সহজ (এবং দ্রুততর) করতে পারতাম যদি আমি ইমেল ঠিকানা বিশ্লেষণটি সম্পাদন করতাম এবং একটি আশ্বাসের সাথে শিখতাম যে 5 9 এর লক্ষ্যে পৌঁছানোর জন্য যা যা প্রয়োজন তা হল ASCII বর্ণানুক্রমিক, বিন্দু এবং ড্যাশ।

যাইহোক, এটি বাস্তবিক সমস্যা সমাধানের জন্য ব্যবহারিকতা এবং সমাধানের স্কোপিংয়ের একটি ভাল উদাহরণ।

সমস্ত প্রোগ্রামিং বিদ্যা এবং ইতিহাসের সর্বশ্রেষ্ঠ উদ্ধৃতিগুলির মধ্যে একটি হল মহান ওয়ার্ড কানিংহামের উপদেশ যা আপনি ঠিক কী অর্জন করার চেষ্টা করছেন তা মনে রাখতে এক সেকেন্ড সময় নিন এবং তারপর নিজেকে জিজ্ঞাসা করুন "সম্ভবত কাজ করতে পারে এমন সহজ জিনিসটি কী?"

প্রচুর পরিমাণে অসংগঠিত পাঠ্য থেকে একটি ইমেল ঠিকানা পার্সিং (এবং ঐচ্ছিকভাবে রূপান্তর করার) ব্যবহারের ক্ষেত্রে, এই সমাধানটি অবশ্যই সবচেয়ে সহজ জিনিস যা আমি ভাবতে পারি।

টীকাযুক্ত রান্নার বই

যেমনটি আমি শুরুতে বলেছিলাম, আমি একটি RFC 5322 কমপ্লায়েন্ট রেজেক্স তৈরির ধারণাটি মজাদার বলে মনে করেছি, তাই আমি আপনাকে স্ট্যান্ডার্ডের বিভিন্ন দিক মোকাবেলা করার জন্য রেজেক্সের সংমিশ্রণযোগ্য অংশগুলি দেখাব এবং কীভাবে রেজেক্স নীতিগুলি তা ব্যাখ্যা করব। শেষ পর্যন্ত, আমি আপনাকে দেখাব যে এটি সমস্ত একত্রিত হওয়ার মতো দেখাচ্ছে।

একটি ইমেল ঠিকানার গঠন হল:

1. ডাকবাক্স
2. আইনি অক্ষর
3. একক বিন্দু (ডবল ডট বৈধ নয়)
4. ভাঁজ করা সাদা স্থান (RFC 5322 পাগলামি)
5. (একটি সম্পূর্ণ রেজেক্স সমাধানের মধ্যে সুষম বন্ধনী এবং/অথবা উদ্ধৃতিও অন্তর্ভুক্ত থাকবে, কিন্তু আমার কাছে এটি এখনও নেই। এবং খুব সম্ভবত কখনই হবে না।)
6. ডিলিমিটার (@)
7. ডোমেইন নাম
8. স্ট্যান্ডার্ড ডিএনএস পার্সযোগ্য ডোমেন
9. IPv4 ঠিকানা আক্ষরিক
10. IPv6 ঠিকানা আক্ষরিক
11. IPv6-পূর্ণ
12. IPv6-comp (সংকুচিত জন্য)
13. 1ম ফর্ম (মাঝখানে শূন্যের 2+ 16-বিট গ্রুপ)
14. ২য় ফর্ম (শুরুতে শূন্যের 2+ 16-বিট গ্রুপ)
15. 3য় ফর্ম (শেষে শূন্যের 2 16-বিট গ্রুপ)
16. 4র্থ ফর্ম (শূন্যের 8 16-বিট গ্রুপ)
17. IPv6v4-পূর্ণ
18. IPv6v4-comp (সংকুচিত)
19. ১ম ফর্ম
20. ২য় ফর্ম
21. 3য় ফর্ম
22. ৪র্থ ফর্ম

এখন regex জন্য.

ডাকবাক্স

^(?<mailbox>(\[a-zA-Z0-9\\+\\!\\#\\$\\%\\&\\'\\\*\\-\\/\\=\\?\\+\\\_\\\{\\}\\|\\\~]|(?<singleDot>(?<!\\.)(?<!^)\\.(?!\\.))|(?<foldedWhiteSpace>\\s?\\&\\#13\\;\\&\\#10\\;.))\{1,64})

প্রথমত, আমাদের কাছে আছে ^ যা স্ট্রিং এর শুরুতে প্রথম অক্ষরটিকে "অ্যাঙ্কর" করে। এটি ব্যবহার করা হবে যদি একটি স্ট্রিংকে বৈধ করার জন্য যা একটি বৈধ ইমেল ছাড়া কিছুই ধারণ করে না। এটি নিশ্চিত করে যে প্রথম চরিত্রটি আইনি।

যদি ব্যবহার কেস এর পরিবর্তে একটি দীর্ঘ স্ট্রিং একটি ইমেল খুঁজে পেতে হয়, অ্যাঙ্কর বাদ দিন।

এর পরে, আমাদের আছে (?<mailbox> । সুবিধার জন্য এটি ক্যাপচার গ্রুপের নাম দেয়। ক্যাপচার করা গ্রুপের অভ্যন্তরে তিনটি রেজেক্স খণ্ড রয়েছে যা বিকল্প মিল চিহ্ন দ্বারা পৃথক করা হয়েছে | যার মানে একটি অক্ষর তিনটি অভিব্যক্তির যে কোনো একটির সাথে মেলে।

ভাল (কার্যকর এবং অনুমানযোগ্য) regex লেখার অংশ হল নিশ্চিত করা যে তিনটি অভিব্যক্তি পারস্পরিকভাবে একচেটিয়া। এর মানে হল যে একটি সাবস্ট্রিং যা একটির সাথে মেলে, অবশ্যই অন্য দুটির সাথে মিলবে না। এটি করার জন্য আমরা ভয়ঙ্কর .* এর পরিবর্তে নির্দিষ্ট অক্ষর ক্লাস ব্যবহার করি।

নিঃশর্ত আইনি চরিত্র

[a-zA-Z0-9\+\!\#\$\%\&\'\*\-\/\=\?\+\_\{\}\|\~]

প্রথম বিকল্প মিল হল বর্গাকার বন্ধনীতে আবদ্ধ একটি অক্ষর শ্রেণী, যা বিন্দু, "ভাঁজ করা সাদা স্থান", ডবল উদ্ধৃতি এবং বন্ধনী ছাড়া একটি ইমেল মেলবক্সে বৈধ সমস্ত ASCII অক্ষরগুলিকে ক্যাপচার করে৷

আমরা কেন তাদের বাদ দিয়েছি তার কারণ হল যে সেগুলি শুধুমাত্র শর্তসাপেক্ষে আইনি, যার মানে হল যে আপনি কীভাবে এগুলি ব্যবহার করতে পারেন সে সম্পর্কে নিয়ম রয়েছে যা যাচাই করতে হবে৷ আমরা পরবর্তী 2টি বিকল্প ম্যাচে তাদের পরিচালনা করব।

একক ডট

(?<singleDot>(?<!\.)(?<!^)\.(?!\.))

এই জাতীয় প্রথম নিয়মটি বিন্দু (পিরিয়ড) সম্পর্কিত। একটি মেলবক্সে, ডটটি শুধুমাত্র দুটি আইনি অক্ষরের স্ট্রিংগুলির মধ্যে একটি বিভাজক হিসাবে অনুমোদিত, তাই পরপর দুটি বিন্দু বৈধ নয়৷

পরপর দুটি বিন্দু থাকলে একটি ম্যাচ রোধ করতে, আমরা regex নেতিবাচক লুক বিহাইন্ড (?<!\.) ব্যবহার করি যা নির্দিষ্ট করে যে পরবর্তী অক্ষর (একটি বিন্দু) মিলবে না যদি এর আগে একটি বিন্দু থাকে।

Regex চেহারা চারপাশে চেইন করা যেতে পারে. আমরা ডট (?!^) এ যাওয়ার আগে পিছনে আরেকটি নেতিবাচক চেহারা রয়েছে যা এই নিয়মটি প্রয়োগ করে যে বিন্দুটি মেলবক্সের প্রথম অক্ষর হতে পারে না।

বিন্দুর পরে, একটি নেতিবাচক চেহারা_আগামী_ _(?!\.)_ , এটি একটি বিন্দুকে অবিলম্বে একটি বিন্দু দ্বারা অনুসরণ করা হলে তা মেলানো থেকে বাধা দেয়।

ভাঁজ করা হোয়াইটস্পেস

(?<foldedWhiteSpace>\s?\&\#13\;\&\#10\;.)

বার্তাগুলিতে মাল্টি-লাইন হেডারের অনুমতি দেওয়ার বিষয়ে এটি কিছু RFC 5322 বাজে কথা। আমি বাজি ধরতে প্রস্তুত যে ইমেল ঠিকানার ইতিহাসে, এমন কেউ নেই যে একটি মাল্টিলাইন মেলবক্সের সাথে একটি ঠিকানা গুরুতরভাবে তৈরি করেছে (তারা এটি একটি রসিকতা হিসাবে করতে পারে)।

কিন্তু আমি 5322 গেমটি খেলছি তাই এটি এখানে, ইউনিকোড অক্ষরের স্ট্রিং যা একটি বিকল্প ম্যাচ হিসাবে ভাঁজ করা হোয়াইট স্পেস তৈরি করে।

সুষম দ্বৈত উদ্ধৃতি এবং বন্ধনী

উভয় RFCই অক্ষরগুলিকে আবদ্ধ করার (বা এস্কেপিং ) উপায় হিসাবে ডবল কোট ব্যবহারের অনুমতি দেয় যা সাধারণত বেআইনি হবে।

তারা বন্ধনীতে মন্তব্যগুলিকে সংযুক্ত করার অনুমতি দেয় যাতে সেগুলি মানবিকভাবে পাঠযোগ্য হয়, কিন্তু ঠিকানার ব্যাখ্যা করার সময় মেল ট্রান্সফার এজেন্ট (MTA) দ্বারা বিবেচনা করা হয় না।

উভয় ক্ষেত্রেই, অক্ষর ভারসাম্যপূর্ণ হলেই বৈধ। এর অর্থ হল একটি জোড়া অক্ষর থাকতে হবে, একটি যেটি খোলে এবং একটি বন্ধ হয় ।

আমি লিখতে প্রলুব্ধ হয়েছি যে আমি একটি প্রদর্শনী মিরাবিলেম আবিষ্কার করেছি, তবে, এটি সম্ভবত শুধুমাত্র মরণোত্তর কাজ করে। সত্য হল যে এটি ভ্যানিলা রেজেক্সে অ-তুচ্ছ।

আমার একটি অন্তর্দৃষ্টি আছে যে "লোভী" রেজেক্সের পুনরাবৃত্তিমূলক প্রকৃতিকে সুবিধার জন্য ব্যবহার করা যেতে পারে, তবে, আমি আগামী কয়েক বছরের জন্য এই সমস্যাটিকে আক্রমণ করার জন্য প্রয়োজনীয় সময় ব্যয় করার সম্ভাবনা কম, এবং তাই খুব ভাল ঐতিহ্যে, আমি এটি ছেড়ে দিচ্ছি পাঠকের জন্য একটি অনুশীলন হিসাবে।

মেইলবক্সের দৈর্ঘ্য

{1,64}

একটি মেলবক্সের সর্বোচ্চ দৈর্ঘ্য : 64টি অক্ষর।

সুতরাং আমরা একটি চূড়ান্ত বন্ধনী বন্ধনী সহ মেলবক্স ক্যাপচার গ্রুপটি বন্ধ করার পরে, আমরা কোঁকড়া ধনুর্বন্ধনীর মধ্যে একটি কোয়ান্টিফায়ার ব্যবহার করি যে আমাদের অবশ্যই আমাদের বিকল্পগুলির যেকোনো একটির সাথে অন্তত একবার এবং 64 বারের বেশি মেলে না।

সাইন

\s?(?<atSign>(?<!\-)(?<!\.)\@(?!\@))

ডিলিমিটার খণ্ডটি বিশেষ ক্ষেত্রে \s? কারণ Futility অনুসারে, ডিলিমিটারের ঠিক আগে একটি স্থান বৈধ, এবং আমি এটির জন্য তাদের কথা নিচ্ছি।

ক্যাপচার গ্রুপের বাকি অংশ singleDot-এর মতো অনুরূপ প্যাটার্ন অনুসরণ করে; একটি ডট বা ড্যাশ দ্বারা বা অবিলম্বে অন্য @ দ্বারা অনুসরণ করা হলে এটি মিলবে না।

ডোমেন নাম

এখানে, মেইলবক্সের মতো, আমাদের 3টি বিকল্প মিল রয়েছে। আর এর মধ্যে শেষটি বাসা বেঁধেছে আরও ৪টি বিকল্প ম্যাচ।

স্ট্যান্ডার্ড ডিএনএস পার্সেবল

(?<dns>[[:alnum:]]([[:alnum:]\-]{0,63}\.){1,24}[[:alnum:]\-]{1,63}[[:alnum:]])

এটি নিরর্থকতার বেশ কয়েকটি পরীক্ষায় উত্তীর্ণ হবে না, তবে আগেই উল্লেখ করা হয়েছে, এটি RFC 5321 এর সাথে কঠোরভাবে মেনে চলে যার চূড়ান্ত শব্দ রয়েছে।

IPv4

(?<IPv4>\[((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])

এ নিয়ে খুব বেশি কিছু বলার নেই। এটি IPv4 ঠিকানাগুলির জন্য একটি সুপরিচিত এবং সহজে উপলব্ধ রেজেক্স।

IPv6

(?<IPv6>(?<IPv6Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){8}\]))|(?<IPv6Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?\]))|(?<IPv6Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,6}\]))|(?<IPv6Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,6}\:\]))|(?<IPv6Comp4>(\[IPv6\:\:\:)\])|(?<IPv6v4Full>(\[IPv6(\:[0-9a-fA-F]{1,4}){6}\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\])|(?<IPv6v4Comp1>\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,3}(\:([0-9a-fA-F]{1,4})){1,5}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\])|\[IPv6\:((([0-9a-fA-F]{1,4})\:){1,5}(\:([0-9a-fA-F]{1,4})){1,3}?(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp2>(\[IPv6\:\:(\:[0-9a-fA-F]{1,4}){1,5}(\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp3>(\[IPv6\:([0-9a-fA-F]{1,4}\:){1,5}\:(((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))\]))|(?<IPv6v4Comp4>(\[IPv6\:\:\:((?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3})(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\]))

আমি IPv6 (এবং IPv6v4) ঠিকানাগুলির জন্য একটি ভাল রেগুলার এক্সপ্রেশন খুঁজে পাইনি, তাই আমি RFC 5321 থেকে Backus/Naur উল্লেখিত নিয়মগুলি সাবধানতার সাথে অনুসরণ করে আমার নিজের লিখলাম।

আমি IPv6 regex-এর প্রতিটি সাবগ্রুপকে টীকা দেব না, তবে আমি প্রত্যেকটি সাবগ্রুপের নাম দিয়েছি যাতে সহজে আলাদা করা যায় এবং কী ঘটছে তা দেখতে।

আমি যেভাবে IUPv6Comp1 ক্যাপচার গ্রুপে "বাম" দিকে লোভী ম্যাচিং এবং "ডান" দিকে অ-লোভীকে একত্রিত করেছি তা ছাড়া সত্যিই খুব আকর্ষণীয় কিছুই নয়।

সম্পূর্ণ মন্টি

আমি Futility থেকে পরীক্ষার ডেটা সহ চূড়ান্ত regex সংরক্ষণ করেছি এবং আমার নিজস্ব কিছু IPv6 পরীক্ষার ক্ষেত্রে Regex101- এ উন্নত করেছি। আমি আশা করি আপনি এই নিবন্ধটি উপভোগ করেছেন, এবং এটি আপনার অনেকের জন্য দরকারী এবং একটি সময় বাঁচাতে প্রমাণিত হয়েছে।

AZW