फोन नंबर के स्टोरेज में विसंगति (mismatch) के कारण हुई एक लॉगिन विफलता ने एक खामी को उजागर किया। एक उपयोगकर्ता का खाता ब्लॉक हो गया क्योंकि डेटाबेस में एक ही जर्मन मोबाइल नंबर दो रूपों में मौजूद था—एक पंक्ति में 0171 5550134 और दूसरी में +49 171 5550134—इसलिए सिस्टम ने उन्हें अलग-अलग प्रविष्टियाँ माना। परिणाम: OTP कभी नहीं आया, और "send code" बटन एक जुआ बन गया।
फोन नंबर तारीखों की तुलना में अधिक कठिन क्यों हैं
डेवलपर्स अक्सर फोन नंबर इनपुट को नियंत्रित करने के लिए regex पर भरोसा करते हैं। यह भरोसा उसी क्षण टूट जाता है जब कोई नंबर सीमा पार करता है या कोई राष्ट्रीय योजना बदलती है। तारीखें एक अनुमानित कैलेंडर का पालन करती हैं; फोन नंबर कैरियर, नियमों और सांस्कृतिक परंपराओं के साथ बदलते रहते हैं।
रॉ स्ट्रिंग्स (raw strings) की छिपी हुई लागत
फोन नंबर को एक साधारण स्ट्रिंग के रूप में स्टोर करना अद्वितीय लगता है—जब तक कि दो निरूपण (representations) एक ही लाइन की ओर इशारा न करें। OTP सिस्टम जो "सही" नंबर के लिए डेटाबेस में क्वेरी करते हैं, वे अंततः एक डुप्लिकेट को कोड भेज देते हैं जो उपयोगकर्ता तक कभी नहीं पहुँचता।
समस्या तब और बढ़ जाती है जब नंबर न्यूमेरिक फ़ील्ड्स में होते हैं। एक BIGINT कॉलम शुरुआती + और किसी भी शुरुआती शून्य (leading zeros) को हटा देता है, जिससे +49 171 5550134 बदलकर 491715550134 हो जाता है। प्लस साइन के बिना, मूल फॉर्मेट को फिर से बनाना केवल एक अनुमान बनकर रह जाता है।
E.164 अनुबंध (contract)
अंतर्राष्ट्रीय टेलीफोन-नंबरिंग योजना, E.164, एक एकल, पोर्टेबल निरूपण को परिभाषित करती है:
+से शुरू होता है- इसके बाद 1 से 3 अंकों का कंट्री कोड होता है
- फिर सब्सक्राइबर नंबर
- कुल 15 से अधिक अंक नहीं
- कोई स्पेस, डॉट या डैश नहीं
E.164 यह गारंटी नहीं देता कि नंबर सक्रिय है; यह केवल यह गारंटी देता है कि स्ट्रिंग एक वैध संरचनात्मक पैटर्न का पालन करती है। इसे एक फॉर्मेट अनुबंध के रूप में मानें, न कि पहुंच (reachability) बताने वाले माध्यम के रूप में।
सामान्य गलतियाँ जिन्हें regex ठीक नहीं कर सकता
- Numeric storage – BIGINT
+और शुरुआती शून्य को हटा देता है। इसके बजाय एक टेक्स्ट कॉलम (TEXT या VARCHAR) का उपयोग करें। - Hard-coded regexes – राष्ट्रीय योजनाएं बदलती रहती हैं। मैक्सिको ने 2019 में अपना ट्रंक प्रीफ़िक्स हटा दिया था; अर्जेंटीना में अब मोबाइल लाइनों के लिए कंट्री कोड के बाद
9की आवश्यकता होती है। एक स्टैटिक पैटर्न जल्दी ही पुराना (obsolete) हो जाता है। - Blind zero stripping – इतालवी लैंडलाइन में शुरुआती शून्य रहता है, जर्मन में नहीं। "शुरुआती शून्य हटाएं" का एक सामान्य नियम इतालवी डेटा को खराब कर देता है जबकि जर्मन नंबरों को अप्रभावित छोड़ देता है।
- Assuming format equals deliverability – libphonenumber संरचना को मान्य करता है लेकिन यह नहीं बता सकता कि हैंडसेट चालू है या नंबर पोर्ट किया गया है।
एक विश्वसनीय पाइपलाइन बनाना
- देश पूछें – साइन-अप फॉर्म पर एक कंट्री सेलेक्टर जोड़ें और उस क्षेत्र को पार्सर (parser) को पास करें।
- लाइव फॉर्मेटिंग दिखाएं – "AsYouType" फॉर्मेटिंग का उपयोग करें ताकि उपयोगकर्ता टाइप करते समय सही पैटर्न देख सकें।
- Blur पर वैलिडेट करें – प्रत्येक कीस्ट्रोक के बजाय उपयोगकर्ता के फ़ील्ड छोड़ने के बाद वैलिडेशन चलाएं; इससे घर्षण (friction) कम होता है।
- केवल E.164 स्ट्रिंग को सुरक्षित रखें – डेटाबेस में सामान्यीकृत (normalized)
+प्रीफ़िक्स वाला नंबर स्टोर करें। - एज (edge) पर फॉर्मेट करें – केवल UI या ईमेल टेम्प्लेट में ही मानव-अनुकूल लेआउट में वापस बदलें।
लीगेसी डेटा (legacy data) को माइग्रेट करते समय, उन पंक्तियों को रखें जो वैलिडेशन में विफल रहती हैं। प्रत्येक मौजूदा प्रविष्टि को एक नए कॉलम में पार्स करें, विफलताओं को फ्लैग करें और एक रिपोर्ट तैयार करें। डेटा का चुपचाप गायब होना (silent drops) ऐसे सपोर्ट टिकट बनाता है जो बाद में महंगे सुधारों में बदल जाते हैं।
डेवलपर्स के लिए एक त्वरित चेकलिस्ट
- नंबरों को E.164 फॉर्मेट में TEXT/VARCHAR के रूप में स्टोर करें।
- Google की libphonenumber लाइब्रेरी का उपयोग करें; यह वैश्विक योजनाओं की जटिल वास्तविकता को संभालती है।
- उन उपयोगकर्ताओं के लिए एक डिफॉल्ट क्षेत्र प्रदान करें जो कंट्री कोड छोड़ देते हैं।
- लाइव साइन-अप के लिए
is_valid_numberको कॉल करें; यह जाँचता है कि नंबर क्षेत्रीय नियमों के अनुरूप है या नहीं। - बल्क डेटा को साफ करते समय
is_possible_numberका उपयोग करें; यह सीमावर्ती मामलों (borderline cases) को अस्वीकार किए बिना स्पष्ट रूप से गलत प्रविष्टियों को पकड़ लेता है।
फोन नंबरों का उचित प्रबंधन केवल एक "nice-to-have" फीचर नहीं है; यह किसी भी ऐसे सिस्टम के लिए एक पूर्व शर्त है जो विश्वसनीय उपयोगकर्ता संपर्क पर निर्भर करता है। E.164 में सामान्यीकरण करके और पार्सिंग का काम एक परीक्षित (battle-tested) लाइब्रेरी को सौंपकर, डेवलपर्स बग्स के एक पूरे वर्ग को समाप्त कर देते हैं जो चुपचाप विश्वास और राजस्व को कम करते हैं। फोन नंबरों को स्ट्रक्चर्ड डेटा के रूप में मानें, न कि फ्री-फॉर्म टेक्स्ट के रूप में, और मानकों को मुख्य काम करने दें।