Kegagalan log masuk yang dikesan berpunca daripada penyimpanan nombor telefon yang tidak sepadan telah mendedahkan satu kelemahan. Akaun seorang pengguna disekat kerana pangkalan data menyimpan nombor mudah alih Jerman yang sama dalam dua bentuk—0171 5550134 dalam satu baris dan +49 171 5550134 dalam baris yang lain—jadi sistem menganggapnya sebagai entri yang berbeza. Hasilnya: OTP tidak pernah sampai, dan butang “send code” menjadi satu perjudian.

Mengapa nombor telefon lebih sukar berbanding tarikh

Pembangun sering mempercayai regex untuk mengawal input nombor telefon. Kepercayaan itu hancur sebaik sahaja sesuatu nombor melintasi sempadan atau pelan nasional berubah. Tarikh mengikut kalendar yang boleh diramal; nombor telefon berubah mengikut pembekal perkhidmatan, peraturan, dan konvensyen budaya.

Kos tersembunyi rentetan mentah (raw strings)

Menyimpan nombor telefon sebagai rentetan biasa (plain string) kelihatan unik—sehinggalah dua representasi merujuk kepada baris yang sama. Sistem OTP yang membuat pertanyaan pada pangkalan data untuk “nombor tersebut” akhirnya menghantar kod ke entri pendua yang tidak akan sampai kepada pengguna.

Masalah menjadi lebih buruk apabila nombor disimpan dalam medan numerik. Lajur BIGINT membuang tanda + di hadapan dan sebarang sifar di hadapan, menukarkan +49 171 5550134 kepada 491715550134. Tanpa tanda tambah, membina semula format asal menjadi satu tekaan semata-mata.

Kontrak E.164

Pelan penomboran telefon antarabangsa, E.164, mentakrifkan satu representasi tunggal yang mudah alih:

  • Bermula dengan +
  • Diikuti oleh kod negara 1 hingga 3 digit
  • Kemudian nombor pelanggan
  • Tidak melebihi 15 digit secara keseluruhan
  • Tiada ruang, titik, atau sempang

E.164 tidak menjamin nombor tersebut aktif; ia hanya menjamin bahawa rentetan tersebut mengikut corak struktur yang sah. Anggap ia sebagai kontrak format, bukan peramal kebolehcapaian (reachability oracle).

Perangkap biasa yang tidak dapat diperbaiki oleh regex

  • Penyimpanan numerik – BIGINT membuang + dan sifar di hadapan. Gunakan lajur teks (TEXT atau VARCHAR) sebagai ganti.
  • Regex yang dikod secara keras (hard-coded) – Pelan nasional berubah. Mexico menggugurkan awalan trunknya pada 2019; Argentina kini memerlukan 9 selepas kod negara untuk talian mudah alih. Corak statik akan cepat menjadi lapuk.
  • Pembuangan sifar secara melulu – Talian tetap Itali mengekalkan sifar di hadapan, manakala Jerman tidak. Peraturan umum “buang sifar di hadapan” akan merosakkan data Itali sambil membiarkan nombor Jerman tidak berubah.
  • Menganggap format sama dengan kebolehcapaian – libphonenumber mengesahkan struktur tetapi tidak dapat memberitahu sama ada peranti sedang dihidupkan atau nombor telah dipindahkan (ported).

Membina saluran (pipeline) yang boleh dipercayai

  1. Minta negara – Tambah pemilih negara pada borang pendaftaran dan hantar wilayah tersebut ke parser.
  2. Paparkan format secara langsung – Gunakan pemformatan “AsYouType” supaya pengguna melihat corak yang betul semasa mereka menaip.
  3. Sahkan pada 'blur' – Jalankan pengesahan selepas pengguna meninggalkan medan tersebut dan bukannya pada setiap tekanan kekunci; ini mengurangkan geseran (friction).
  4. Simpan hanya rentetan E.164 – Simpan nombor berawalan + yang telah dinormalkan dalam pangkalan data.
  5. Format di bahagian hujung (edge) – Tukar semula kepada susun atur mesra manusia hanya dalam UI atau templat e-mel.

Semasa migrasi data lama, simpan baris yang gagal pengesahan. Parse setiap entri sedia ada ke dalam lajur baharu, tandakan kegagalan, dan jana laporan. Pembuangan senyap (silent drops) akan mewujudkan tiket sokongan yang kemudiannya menjadi pembaikan yang mahal.

Senarai semak pantas untuk pembangun

  • Simpan nombor sebagai TEXT/VARCHAR dalam format E.164.
  • Gunakan perpustakaan libphonenumber daripada Google; ia mengendalikan realiti pelan global yang rumit.
  • Sediakan wilayah lalai untuk pengguna yang tidak memasukkan kod negara.
  • Panggil is_valid_number untuk pendaftaran secara langsung; ia menyemak sama ada nombor tersebut mematuhi peraturan wilayah.
  • Gunakan is_possible_number semasa membersihkan data pukal; ia mengesan entri yang jelas salah format tanpa menolak kes yang meragukan.

Pengendalian nombor telefon yang betul bukanlah sesuatu yang sekadar "pilihan"; ia adalah prasyarat bagi mana-mana sistem yang bergantung kepada hubungan pengguna yang boleh dipercayai. Dengan menormalkan kepada E.164 dan menyerahkan tugas parsing kepada perpustakaan yang telah teruji, pembangun dapat menghapuskan satu kelas pepijat yang secara senyap menghakis kepercayaan dan hasil pendapatan. Anggap nombor telefon sebagai data berstruktur, bukan teks bebas, dan biarkan piawaian melakukan kerja berat tersebut.