தொலைபேசி எண் சேமிப்பில் ஏற்பட்ட முரண்பாட்டினால் லாகின் தோல்வி ஏற்பட்டது, இது ஒரு குறைபாட்டை வெளிப்படுத்தியது. ஒரு பயனரின் கணக்கு முடக்கப்பட்டதற்குக் காரணம், தரவுத்தளத்தில் (database) ஒரே ஜெர்மன் மொபைல் எண் இரண்டு வடிவங்களில் இருந்ததே ஆகும்—ஒரு வரிசையில் 0171 5550134 என்றும், மற்றொரு வரிசையில் +49 171 5550134 என்றும் இருந்தது—இதனால் கணினி அவற்றை வெவ்வேறு பதிவுகளாகக் கருதியது. இதன் விளைவாக: OTP வரவில்லை, மேலும் "send code" பொத்தான் ஒரு சூதாட்டமாக மாறியது.
தொலைபேசி எண்கள் ஏன் தேதிகளை விடக் கடினமானவை
டெவலப்பர்கள் பெரும்பாலும் தொலைபேசி எண் உள்ளீட்டைச் சரிசெய்ய regex-ஐ நம்பியிருக்கிறார்கள். ஒரு எண் எல்லையைத் தாண்டும்போதோ அல்லது ஒரு நாட்டின் தொலைத்தொடர்புத் திட்டம் மாறும்போதுயோ அந்த நம்பிக்கை உடைந்துவிடுகிறது. தேதிகள் ஒரு கணிக்கக்கூடிய காலண்டரைப் பின்பற்றுகின்றன; ஆனால் தொலைபேசி எண்கள் சேவை வழங்குநர்கள் (carriers), விதிமுறைகள் மற்றும் கலாச்சார நடைமுறைகளுக்கு ஏற்ப மாறுகின்றன.
வெறும் சரங்களின் (raw strings) மறைமுகச் செலவு
ஒரு தொலைபேசி எண்ணை வெறும் string ஆகச் சேமிப்பது தனித்துவமாகத் தோன்றலாம்—ஆனால் இரண்டு வெவ்வேறு வடிவங்கள் ஒரே எண்ணைக் குறிக்கும் வரை மட்டுமே அது உண்மை. தரவுத்தளத்தில் "அந்த" எண்ணைத் தேடும் OTP அமைப்புகள், பயனரைச் சென்றடையாத ஒரு நகல் எண்ணிற்கு (duplicate) குறியீட்டை அனுப்பிவிடுகின்றன.
எண்கள் எண் சார்ந்த புலங்களில் (numeric fields) இருக்கும்போது இந்தப் பிரச்சனை இன்னும் மோசமடைகிறது. ஒரு BIGINT காலம் (column) முன்னால் உள்ள + மற்றும் எந்தவொரு பூஜ்ஜியங்களையும் நீக்கிவிடும், இதனால் +49 171 5550134 என்பது 491715550134 என மாறிவிடும். பிளஸ் (+) குறியீடு இல்லாமல், அசல் வடிவத்தை மீண்டும் உருவாக்குவது ஒரு யூகமாகிவிடுகிறது.
E.164 ஒப்பந்தம்
சர்வதேச தொலைபேசி எண் திட்டமான E.164, ஒரு நிலையான மற்றும் எளிதில் பயன்படுத்தக்கூடிய வடிவத்தை வரையறுக்கிறது:
+குறியீட்டுடன் தொடங்கும்- அதைத் தொடர்ந்து 1 முதல் 3 இலக்கங்கள் கொண்ட நாடு குறியீடு (country code) வரும்
- பிறகு சந்தாதாரர் எண் (subscriber number) வரும்
- மொத்தம் 15 இலக்கங்களுக்கு மிகாமல் இருக்க வேண்டும்
- இடைவெளிகள், புள்ளிகள் அல்லது கோடுகள் இருக்கக்கூடாது
E.164 அந்த எண் செயல்பாட்டில் (active) இருப்பதை உறுதி செய்வதில்லை; அந்த string ஒரு சரியான கட்டமைப்பு முறையைப் பின்பற்றுகிறது என்பதை மட்டுமே அது உறுதி செய்கிறது. இதை ஒரு வடிவக் ஒப்பந்தமாக (format contract) கருதுங்கள், தொடர்பு கொள்ளக்கூடியதைக் கண்டறியும் கருவியாக அல்ல.
regex மூலம் சரிசெய்ய முடியாத பொதுவான சிக்கல்கள்
- எண் சார்ந்த சேமிப்பு (Numeric storage) – BIGINT ஆனது
+மற்றும் முன்னால் உள்ள பூஜ்ஜியங்களை நீக்கிவிடும். அதற்குப் பதிலாக ஒரு உரைத் தூணைப் (TEXT அல்லது VARCHAR) பயன்படுத்தவும். - நிலையான regex-கள் (Hard-coded regexes) – நாட்டுத் திட்டங்கள் மாறுகின்றன. மெக்ஸிகோ 2019 இல் தனது trunk prefix-ஐ நீக்கியது; அர்ஜென்டினா இப்போது மொபைல் இணைப்புகளுக்கு நாடு குறியீட்டிற்குப் பிறகு
9என்ற எண்ணைக் கோருகிறது. ஒரு நிலையான வடிவம் (static pattern) விரைவில் காலாவதியாகிவிடும். - கண்மூடித்தனமாக பூஜ்ஜியங்களை நீக்குதல் (Blind zero stripping) – இத்தாலிய லேண்ட்லைன்கள் முன்னால் உள்ள பூஜ்ஜியத்தை வைத்திருக்கும், ஜெர்மன் எண்கள் அதை வைத்திருப்பதில்லை. "முன்னால் உள்ள பூஜ்ஜியங்களை நீக்கு" என்ற பொதுவான விதி, இத்தாலியத் தரவைச் சிதைக்கும் அதே வேளையில் ஜெர்மன் எண்களை மாற்றாமல் விட்டுவிடும்.
- வடிவம் என்பது டெலிவரி செய்வதைக் குறிக்கும் என்று கருதுதல் – libphonenumber கட்டமைப்பைச் சரிபார்க்கும், ஆனால் கைபேசி ஆன்லைனில் உள்ளதா அல்லது எண் மாற்றப்பட்டுள்ளதா (ported) என்பதைக் கூற முடியாது.
ஒரு நம்பகமான வழிமுறையை (pipeline) உருவாக்குதல்
- நாட்டைத் தேர்ந்தெடுக்கச் சொல்லுங்கள் – பதிவு செய்யும் படிவங்களில் ஒரு நாடு தேர்வலைச் (country selector) சேர்த்து, அந்தப் பிராந்தியத்தை parser-க்கு அனுப்பவும்.
- நேரடி வடிவமைப்பைக் காட்டுங்கள் – பயனர்கள் தட்டச்சு செய்யும்போதே சரியான வடிவத்தைப் பார்க்க "AsYouType" வடிவமைப்பைப் பயன்படுத்தவும்.
- 'Blur' நிகழ்வின் போது சரிபார்க்கவும் – ஒவ்வொரு தட்டச்சுக்கும் பதிலாக, பயனர் அந்தப் புலத்தை விட்டு வெளியேறிய பிறகு சரிபார்ப்பைச் செய்யவும்; இது பயனரின் சிரமத்தைக் குறைக்கும்.
- E.164 string-ஐ மட்டும் சேமிக்கவும் – தரவுத்தளத்தில்
+முன்னொட்டுடன் கூடிய இயல்பாக்கப்பட்ட (normalized) எண்ணைச் சேமிக்கவும். - இறுதி நிலையில் வடிவமைக்கவும் (Format at the edge) – UI அல்லது மின்னஞ்சல் டெம்ப்ளேட்களில் மட்டுமே மனிதர்கள் எளிதாகப் படிக்கும் வகையில் மாற்றவும்.
பழைய தரவை மாற்றும்போது (migrating legacy data), சரிபார்ப்பில் தோல்வியடையும் வரிசைகளைத் தக்கவைத்துக் கொள்ளுங்கள். ஒவ்வொரு பதிவையும் ஒரு புதிய தூணிற்கு (column) மாற்றி, தோல்விகளைக் குறித்து ஒரு அறிக்கையைத் தயார் செய்யவும். தரவுகளை அமைதியுடன் நீக்குவது (silent drops), பின்னர் அதிகச் செலவு பிடிக்கும் பிழைத் திருத்தங்களாக மாறும்.
டெவலப்பர்களுக்கான விரைவான சரிபார்ப்புப் பட்டியல்
- எண்களை E.164 வடிவத்தில் TEXT/VARCHAR ஆகச் சேமிக்கவும்.
- கூகுளின் libphonenumber நூலகத்தைப் பயன்படுத்தவும்; இது உலகளாவிய திட்டங்களின் சிக்கலான யதார்த்தத்தைக் கையாளும்.
- நாடு குறியீட்டைத் தவிர்க்கும் பயனர்களுக்கு ஒரு இயல்புநிலை பிராந்தியத்தை (default region) வழங்கவும்.
- நேரடிப் பதிவுகளுக்கு
is_valid_number-ஐ அழைக்கவும்; இது எண் அந்தந்த பிராந்திய விதிகளுக்கு உட்பட்டதா என்பதைச் சரிபார்க்கும். - மொத்தத் தரவைச் சுத்தம் செய்யும்போது
is_possible_number-ஐப் பயன்படுத்தவும்; இது தெளிவான பிழையான பதிவுகளைக் கண்டறியும், ஆனால் சந்தேகத்திற்குரிய பதிவுகளை நிராகரிக்காது.
முறையான தொலைபேசி எண் கையாளுதல் என்பது ஒரு கூடுதல் வசதி அல்ல; அது நம்பகமான பயனர் தொடர்பைச் சார்ந்திருக்கும் எந்தவொரு அமைப்புக்கும் ஒரு முன்நிபந்தனை (prerequisite). E.164 முறைக்கு மாற்றியமைப்பதன் மூலமும், parsing பணிகளைச் சோதிக்கப்பட்ட ஒரு நூலகத்திடம் ஒப்படைப்பதன் மூலமும், டெவலப்பர்கள் நம்பிக்கையையும் வருவாயையும் மெல்ல மெல்லக் குறைக்கும் பிழைகளைத் தவிர்க்கலாம். தொலைபேசி எண்களைத் தன்னிச்சையான உரை (free-form text) என்று கருதாமல், கட்டமைக்கப்பட்ட தரவாகக் (structured data) கருதுங்கள், மேலும் தரநிலைகளே கடினமான பணிகளைச் செய்யட்டும்.