फोन नंबरच्या साठवणुकीतील (storage) विसंगतीमुळे लॉगिन अयशस्वी झाल्याने एक त्रुटी समोर आली. एका वापरकर्त्याचे खाते ब्लॉक झाले कारण डेटाबेसमध्ये तोच जर्मन मोबाईल नंबर दोन वेगवेगळ्या स्वरूपात साठवला होता—एका रो (row) मध्ये 0171 5550134 आणि दुसऱ्यामध्ये +49 171 5550134—त्यामुळे सिस्टमने त्यांना दोन वेगळे नंबर मानले. परिणामी: OTP कधीच आला नाही आणि "send code" बटण म्हणजे एक जुगार ठरले.
फोन नंबर तारखांपेक्षा कठीण का आहेत
डेव्हलपर्स अनेकदा फोन नंबरच्या इनपुटसाठी regex वर विश्वास ठेवतात. पण जेव्हा एखादा नंबर सीमा ओलांडतो किंवा देशाचा प्लॅन बदलतो, तेव्हा हा विश्वास तुटतो. तारखा एका अंदाजित कॅलेंडरचे पालन करतात; मात्र फोन नंबर हे टेलिकॉम ऑपरेटर्स, नियम आणि सांस्कृतिक पद्धतीनुसार बदलत असतात.
रॉ स्ट्रिंग्सचा (raw strings) छुपा खर्च
फोन नंबर साध्या स्ट्रिंग (plain string) स्वरूपात साठवणे वेगळे वाटू शकते—जोपर्यंत दोन वेगवेगळे प्रकार एकाच नंबरकडे निर्देश करत नाहीत. OTP सिस्टम जेव्हा डेटाबेसमध्ये "तो" नंबर शोधतात, तेव्हा ते चुकीच्या किंवा डुप्लिकेट नंबरवर कोड पाठवतात, जो वापरकर्त्यापर्यंत कधीच पोहोचत नाही.
जेव्हा नंबर न्यूमेरिक फील्ड्समध्ये (numeric fields) असतात, तेव्हा समस्या अधिक गंभीर होते. BIGINT कॉलम सुरुवातीचा + आणि कोणतेही सुरुवातीचे शून्य (zeros) काढून टाकतो, ज्यामुळे +49 171 5550134 चे रूपांतर 491715550134 मध्ये होते. प्लस साइनशिवाय मूळ फॉरमॅट पुन्हा तयार करणे केवळ एक अंदाज ठरतो.
E.164 करार (contract)
आंतरराष्ट्रीय टेलिफोन-नंबरिंग प्लॅन, E.164, एकच आणि पोर्टेबल स्वरूप परिभाषित करतो:
+ने सुरू होतो- त्यानंतर १ ते ३ अंकी कंट्री कोड (country code)
- त्यानंतर सबस्क्रायबर नंबर
- एकूण १५ अंकांपेक्षा जास्त नसावे
- स्पेस, डॉट्स किंवा डॅश नसावेत
E.164 मुळे नंबर सक्रिय (active) आहे याची हमी मिळत नाही; ते फक्त स्ट्रिंग एका वैध स्ट्रक्चरल पॅटर्नचे पालन करते याची खात्री देते. याकडे फॉरमॅट करार म्हणून पहा, नंबर उपलब्ध आहे की नाही हे सांगणारा मार्गदर्शक (oracle) म्हणून नाही.
सामान्य चुका ज्या regex सुधारू शकत नाही
- Numeric storage – BIGINT मुळे
+आणि सुरुवातीचे शून्य निघून जातात. त्याऐवजी टेक्स्ट कॉलम (TEXT किंवा VARCHAR) वापरा. - Hard-coded regexes – देशांचे प्लॅन्स बदलतात. मेक्सिकोने २०१९ मध्ये आपला ट्रंक प्रीफिक्स (trunk prefix) काढून टाकला; अर्जेंटिनामध्ये आता मोबाईल लाईन्ससाठी कंट्री कोड नंतर
9आवश्यक आहे. स्टॅटिक पॅटर्न लवकरच कालबाह्य होतो. - Blind zero stripping – इटालियन लँडलाईन्समध्ये सुरुवातीचा शून्य असतो, पण जर्मन नंबरमध्ये नसतो. "सुरुवातीचे शून्य काढून टाका" हा सरसकट नियम लावल्यास जर्मन नंबर सुरक्षित राहतील पण इटालियन डेटा खराब होईल.
- Assuming format equals deliverability – libphonenumber स्ट्रक्चरची पडताळणी करते, परंतु हँडसेट चालू आहे की नंबर पोर्ट झाला आहे हे सांगू शकत नाही.
एक विश्वसनीय पाइपलाइन (pipeline) तयार करणे
- देशाची मागणी करा – साइन-अप फॉर्मवर कंट्री सिलेक्टर (country selector) जोडा आणि तो रिजन (region) पार्सरला (parser) पाठवा.
- लाईव्ह फॉरमॅटिंग दाखवा – “AsYouType” फॉरमॅटिंग वापरा जेणेकरून वापरकर्ते टाईप करत असताना त्यांना योग्य पॅटर्न दिसेल.
- Validate on blur – प्रत्येक कीस्ट्रोकवर (keystroke) व्हॅलिडेशन करण्याऐवजी वापरकर्त्याने फील्ड सोडल्यानंतर व्हॅलिडेशन करा; यामुळे अडथळे कमी होतात.
- फक्त E.164 स्ट्रिंग साठवा – डेटाबेसमध्ये नॉर्मलाईज केलेला
+ने सुरू होणारा नंबर साठवा. - Format at the edge – फक्त UI किंवा ईमेल टेम्पलेट्समध्येच मानवी वाचनीय (human-friendly) लेआउटमध्ये रूपांतरित करा.
लेगसी डेटा (legacy data) मायग्रेट करताना, व्हॅलिडेशनमध्ये फेल होणाऱ्या रो (rows) जतन करा. प्रत्येक अस्तित्वात असलेल्या एन्ट्रीचे नवीन कॉलममध्ये पार्सिंग करा, त्रुटी चिन्हांकित करा आणि रिपोर्ट तयार करा. डेटा आपोआप गहाळ झाल्यामुळे (silent drops) सपोर्ट तिकिटे तयार होतात, ज्यांचे नंतर महागड्या दुरुस्त्यांमध्ये रूपांतर होते.
डेव्हलपर्ससाठी एक क्विक चेकलिस्ट
- नंबर E.164 फॉरमॅटमध्ये TEXT/VARCHAR म्हणून साठवा.
- Google ची libphonenumber लायब्ररी वापरा; ती जागतिक प्लॅन्सची गुंतागुंतीची वास्तवता हाताळते.
- ज्या वापरकर्त्यांनी कंट्री कोड टाळला आहे, त्यांच्यासाठी डिफॉल्ट रिजन (default region) द्या.
- लाईव्ह साइन-अपसाठी
is_valid_numberकॉल करा; ते नंबर प्रादेशिक नियमांमध्ये बसतो की नाही हे तपासते. - बल्क डेटा (bulk data) साफ करताना
is_possible_numberवापरा; हे संदिग्ध केसेस नाकारण्याऐवजी स्पष्टपणे चुकीच्या एन्ट्री पकडते.
फोन नंबरचे योग्य व्यवस्थापन करणे ही केवळ एक 'अतिरिक्त सुविधा' नाही; तर विश्वसनीय युजर कॉन्टॅक्टवर अवलंबून असलेल्या कोणत्याही सिस्टमसाठी ती एक पूर्वअट आहे. E.164 नुसार नॉर्मलाईज करून आणि पार्सिंगचे काम एका अनुभवी लायब्ररीकडे सोपवून, डेव्हलपर्स अशा बग्सना दूर करू शकतात जे शांतपणे विश्वास आणि महसूल कमी करतात. फोन नंबरकडे फ्री-फॉर्म टेक्स्ट म्हणून न पाहता स्ट्रक्चर्ड डेटा म्हणून पहा आणि मानकांचा (standards) वापर करून काम सोपे करा.