ഫോൺ നമ്പറുകൾ സൂക്ഷിക്കുന്നതിലെ വ്യത്യാസം കാരണം ഉണ്ടായ ഒരു ലോഗിൻ പരാജയം ഒരു പിഴവ് വെളിപ്പെടുത്തി. ഒരേ ജർമ്മൻ മൊബൈൽ നമ്പർ തന്നെ രണ്ട് രീതിയിൽ ഡാറ്റാബേസിൽ രേഖപ്പെടുത്തിയതിനാൽ ഒരു ഉപയോക്താവിന്റെ അക്കൗണ്ട് ബ്ലോക്ക് ചെയ്യപ്പെട്ടു—ഒരു വരിയിൽ 0171 5550134 എന്നും മറ്റൊന്നിൽ +49 171 5550134 എന്നും രേഖപ്പെടുത്തിയിരുന്നു—അതുകൊണ്ട് സിസ്റ്റം അവയെ രണ്ട് വ്യത്യസ്ത എൻട്രികളായി കണക്കാക്കി. ഫലമായി, OTP ലഭിച്ചില്ല, കൂടാതെ "send code" ബട്ടൺ ഒരു ഭാഗ്യപരീക്ഷണമായി മാറി.

ഫോൺ നമ്പറുകൾ തീയതികളേക്കാൾ പ്രയാസകരമാകുന്നത് എന്തുകൊണ്ട്

ഫോൺ നമ്പർ ഇൻപുട്ടുകൾ നിയന്ത്രിക്കാൻ ഡെവലപ്പർമാർ പലപ്പോഴും regex-നെ വിശ്വസിക്കാറുണ്ട്. എന്നാൽ ഒരു നമ്പർ അതിർത്തി കടക്കുമ്പോഴോ അല്ലെങ്കിൽ ഒരു രാജ്യത്തെ ഫോൺ പ്ലാനുകളിൽ മാറ്റം വരുമ്പോഴോ ആ വിശ്വാസം തകരുന്നു. തീയതികൾ പ്രവചിക്കാവുന്ന ഒരു കലണ്ടർ പിന്തുടരുന്നു; എന്നാൽ ഫോൺ നമ്പറുകൾ കാരിയറുകൾ, നിയമങ്ങൾ, സാംസ്കാരിക രീതികൾ എന്നിവയ്ക്കനുസരിച്ച് മാറിക്കൊണ്ടിരിക്കും.

റോ (raw) സ്ട്രിംഗുകളുടെ മറഞ്ഞിരിക്കുന്ന ചിലവ്

ഒരു ഫോൺ നമ്പർ പ്ലെയിൻ സ്ട്രിംഗ് ആയി സൂക്ഷിക്കുന്നത് സവിശേഷമാണെന്ന് തോന്നാം—എന്നാൽ രണ്ട് രൂപങ്ങൾ ഒരേ നമ്പറിനെ സൂചിപ്പിക്കുന്നത് വരെ മാത്രം. "ശരിയായ" നമ്പർക്കായി ഡാറ്റാബേസിൽ തിരയുന്ന OTP സിസ്റ്റങ്ങൾ, ഉപയോക്താവിന് ഒരിക്കലും ലഭിക്കാത്ത ഒരു ഡ്യൂപ്ലിക്കേറ്റ് നമ്പറിലേക്ക് കോഡ് അയക്കുന്ന അവസ്ഥയുണ്ടാകുന്നു.

നമ്പറുകൾ numeric ഫീൽഡുകളിൽ സൂക്ഷിക്കുമ്പോൾ പ്രശ്നം വഷളാകുന്നു. ഒരു BIGINT കോളം തുടക്കത്തിലുള്ള +-ഉം തുടക്കത്തിലുള്ള പൂജ്യങ്ങളും നീക്കം ചെയ്യുകയും +49 171 5550134-നെ 491715550134 ആക്കി മാറ്റുകയും ചെയ്യുന്നു. പ്ലസ് ചിഹ്നമില്ലാതെ, യഥാർത്ഥ ഫോർമാറ്റ് വീണ്ടെടുക്കുന്നത് ഒരു ഊഹം മാത്രമായി മാറുന്നു.

E.164 കരാർ

അന്താരാഷ്ട്ര ടെലിഫോൺ നമ്പറിംഗ് പ്ലാനായ E.164, ഒരൊറ്റ ഉപയോഗപ്രദമായ രൂപം നിർവചിക്കുന്നു:

  • + ചിഹ്നത്തിൽ തുടങ്ങുന്നു
  • തുടർന്ന് 1 മുതൽ 3 ഡിജിറ്റ് വരെയുള്ള കൺട്രി കോഡ്
  • അതിനുശേഷം സബ്‌സ്‌ക്രൈബർ നമ്പർ
  • ആകെ 15 ഡിജിറ്റിൽ കൂടാൻ പാടില്ല
  • സ്പേസ്, ഡോട്ട്, അല്ലെങ്കിൽ ഡാഷ് എന്നിവ പാടില്ല

E.164 നമ്പർ സജീവമാണെന്ന് ഉറപ്പ് നൽകുന്നില്ല; ആ സ്ട്രിംഗ് ഒരു സാധുവായ ഘടനാപരമായ പാറ്റേൺ പിന്തുടരുന്നുണ്ടെന്ന് മാത്രമേ അത് ഉറപ്പാക്കുന്നുള്ളൂ. ഇതിനെ ഒരു ഫോർമാറ്റ് കരാറായി കാണുക, നമ്പർ ലഭ്യമാണോ എന്ന് അറിയാനുള്ള മാർഗ്ഗമായി കാണരുത്.

regex-ന് പരിഹരിക്കാൻ കഴിയാത്ത സാധാരണ പിഴവുകൾ

  • Numeric storage – BIGINT ഉപയോഗിക്കുമ്പോൾ +-ഉം തുടക്കത്തിലുള്ള പൂജ്യങ്ങളും നഷ്ടപ്പെടുന്നു. പകരം ഒരു ടെക്സ്റ്റ് കോളം (TEXT അല്ലെങ്കിൽ VARCHAR) ഉപയോഗിക്കുക.
  • Hard-coded regexes – രാജ്യങ്ങളിലെ ഫോൺ പ്ലാനുകൾ മാറിക്കൊണ്ടിരിക്കും. ഉദാഹരണത്തിന്, 2019-ൽ മെക്സിക്കോ അതിന്റെ ട്രങ്ക് പ്രിഫിക്സ് ഒഴിവാക്കി; അർജന്റീനയിൽ ഇപ്പോൾ മൊബൈൽ ലൈനുകൾക്കായി കൺട്രി കോഡിന് ശേഷം 9 ആവശ്യമാണ്. സ്ഥിരമായ ഒരു പാറ്റേൺ പെട്ടെന്ന് കാലഹരണപ്പെട്ടേക്കാം.
  • Blind zero stripping – ഇറ്റാലിയൻ ലാൻഡ്‌ലൈനുകളിൽ തുടക്കത്തിലുള്ള പൂജ്യം നിലനിർത്താറുണ്ട്, എന്നാൽ ജർമ്മൻ നമ്പറുകളിൽ ഇല്ല. എല്ലാ നമ്പറുകളിൽ നിന്നും "തുടക്കത്തിലുള്ള പൂജ്യങ്ങൾ നീക്കം ചെയ്യുക" എന്ന പൊതുവായ നിയമം ഇറ്റാലിയൻ ഡാറ്റയെ തെറ്റായി രേഖപ്പെടുത്താൻ കാരണമാകും.
  • Assuming format equals deliverability – libphonenumber ഫോർമാറ്റ് പരിശോധിക്കുന്നുണ്ടെങ്കിലും, ഫോൺ ഓൺ ആണോ അല്ലെങ്കിൽ നമ്പർ പോർട്ട് ചെയ്തതാണോ എന്ന് പറയാൻ കഴിയില്ല.

വിശ്വസനീയമായ ഒരു പൈപ്പ്‌ലൈൻ നിർമ്മിക്കുക

  1. രാജ്യം ചോദിക്കുക – സൈൻ-അപ്പ് ഫോമുകളിൽ ഒരു കൺട്രി സെലക്ടർ ചേർക്കുകയും ആ റീജിയൻ പാഴ്സറിലേക്ക് (parser) നൽകുകയും ചെയ്യുക.
  2. ലൈവ് ഫോർമാറ്റിംഗ് കാണിക്കുക – ഉപയോക്താക്കൾ ടൈപ്പ് ചെയ്യുമ്പോൾ തന്നെ ശരിയായ പാറ്റേൺ കാണുന്നതിനായി “AsYouType” ഫോർമാറ്റിംഗ് ഉപയോഗിക്കുക.
  3. Validate on blur – ഓരോ കീ അമർത്തുമ്പോഴും പരിശോധിക്കുന്നതിന് പകരം, ഉപയോക്താവ് ആ ഫീൽഡിൽ നിന്ന് മാറുമ്പോൾ (blur) പരിശോധന നടത്തുക; ഇത് ഉപയോഗക്ഷമത വർദ്ധിപ്പിക്കും.
  4. E.164 സ്ട്രിംഗ് മാത്രം സൂക്ഷിക്കുക – നോർമലൈസ് ചെയ്ത + ചിഹ്നത്തോടു കൂടിയ നമ്പർ മാത്രം ഡാറ്റാബേസിൽ സൂക്ഷിക്കുക.
  5. ഫോർമാറ്റിംഗ് അവസാന ഘട്ടത്തിൽ ചെയ്യുക – UI-ലോ ഇമെയിൽ ടെംപ്ലേറ്റുകളിലോ മാത്രം ഉപയോക്താവിന് എളുപ്പത്തിൽ മനസ്സിലാകുന്ന രീതിയിലേക്ക് മാറ്റുക.

പഴയ ഡാറ്റ (legacy data) മാറ്റുന്ന സമയത്ത്, വാലിഡേഷൻ പരാജയപ്പെടുന്ന വരികൾ മാറ്റിവെക്കുക. നിലവിലുള്ള ഓരോ എൻട്രിയും പുതിയൊരു കോളത്തിലേക്ക് മാറ്റുകയും, പരാജയപ്പെട്ടവ അടയാളപ്പെടുത്തി ഒരു റിപ്പോർട്ട് തയ്യാറാക്കുകയും ചെയ്യുക. ഡാറ്റാ നഷ്ടപ്പെടുന്നത് പിന്നീട് വലിയ ചിലവുള്ള പ്രശ്നങ്ങളായി മാറാൻ കാരണമാകും.

ഡെവലപ്പർമാർക്കായുള്ള ഒരു ചെക്ക്‌ലിസ്റ്റ്

  • നമ്പറുകൾ E.164 ഫോർമാറ്റിൽ TEXT/VARCHAR ആയി സൂക്ഷിക്കുക.
  • ഗൂഗിളിന്റെ libphonenumber ലൈബ്രറി ഉപയോഗിക്കുക; ഇത് ആഗോള ഫോൺ പ്ലാനുകളുടെ സങ്കീർണ്ണതകൾ കൈകാര്യം ചെയ്യാൻ സഹായിക്കുന്നു.
  • കൺട്രി കോഡ് നൽകാത്ത ഉപയോക്താക്കൾക്കായി ഒരു ഡിഫോൾട്ട് റീജിയൻ നൽകുക.
  • ലൈവ് സൈൻ-അപ്പുകൾക്കായി is_valid_number ഉപയോഗിക്കുക; ഇത് നമ്പർ പ്രാദേശിക നിയമങ്ങൾ പാലിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു.
  • ബൾക്ക് ഡാറ്റ ക്ലീൻ ചെയ്യുമ്പോൾ is_possible_number ഉപയോഗിക്കുക; ഇത് സംശയാസ്പദമായവ ഒഴിവാക്കാതെ തന്നെ തെറ്റായ എൻട്രികൾ കണ്ടെത്താൻ സഹായിക്കുന്നു.

ശരിയായ രീതിയിലുള്ള ഫോൺ നമ്പർ കൈകാര്യം ചെയ്യുക എന്നത് വെറുമൊരു സൗകര്യമല്ല; ഉപയോക്താക്കളുമായി ബന്ധപ്പെടാൻ ആശ്രയിക്കുന്ന ഏതൊരു സിസ്റ്റത്തിനും അത് അനിവാര്യമാണ്. E.164 രീതിയിലേക്ക് മാറ്റുന്നതിലൂടെയും പാഴ്സിംഗ് ജോലികൾ വിശ്വസനീയമായ ഒരു ലൈബ്രറിക്ക് വിട്ടുകൊടുക്കുന്നതിലൂടെയും, വിശ്വാസ്യതയെയും വരുമാനത്തെയും ബാധിക്കുന്ന ബഗുകൾ ഒഴിവാക്കാൻ ഡെവലപ്പർമാർക്ക് സാധിക്കുന്നു. ഫോൺ നമ്പറുകളെ വെറും ടെക്സ്റ്റ് ആയി കാണാതെ സ്ട്രക്ചർ ചെയ്ത ഡാറ്റയായി കാണുക, സ്റ്റാൻഡേർഡ് രീതികൾ ഉപയോഗിക്കുക.