چرا استعلام کد ملی با تاریخ تولد نتیجه نمی‌دهد؟ سه حالت

اگر استعلام کد ملی با تاریخ تولد چیزی برنگرداند، سه اتفاق کاملاً متفاوت ممکن است افتاده باشد: ورودی بدشکل بوده، ورودی خوب بوده ولی با هم نخوانده‌اند، یا مشکل از آن طرف بوده. هر سه برای کاربر مثل هم دیده می‌شوند، ولی برای شما سه عمل مختلف لازم دارند.

این نوشته به همین سه حالت می‌پردازد، با نگاه به استعلام اطلاعات هویتی و رفتاری که در API می‌بینید. درباره اینکه چرا تاریخ تولد اجباری است، راهنمای «استعلام اطلاعات هویتی با کد ملی» پیش‌تر توضیح داده؛ اینجا به آن برنمی‌گردیم.

حالت اول: خطای ورودی

ورودی پیش از رفتن به سرویس مرجع بررسی می‌شود. اگر نامعتبر باشد، invalid_input می‌گیرید و هزینه‌ای کسر نمی‌شود. دلایل رایج:

• کد ملی با رقم کنترل نمی‌خواند. ده رقم باید باشد و رقم آخرش از روی نه رقم قبل محاسبه می‌شود. یک رقم جابه‌جا و ساختار می‌شکند.
• تاریخ تولد کامل نیست. هشت رقم لازم است: سال چهاررقمی، ماه و روز دورقمی.
• تاریخ تولد میلادی است. سالی مثل ۱۹۹۰ در بازهٔ سال شمسی قابل قبول نیست و رد می‌شود. این از رایج‌ترین خطاهای کسانی است که از فرم‌های بین‌المللی تاریخ تولد می‌گیرند.
• روز در آن ماه وجود ندارد. شش ماه اول سال سی‌ویک روز دارند، پنج ماه بعدی سی روز، و اسفند بسته به کبیسه‌بودن سال بیست‌ونه یا سی. سی‌ام اسفند در سال غیرکبیسه وجود ندارد.

سه قالب 1370/01/05، 1370-01-05 و 13700105 پذیرفته می‌شوند. ارقام فارسی هم تبدیل می‌شوند. پس «قالب اشتباه» به ندرت علت اصلی است؛ بیشتر «تقویم اشتباه» یا «رقم اشتباه» است.

حالت دوم: ورودی درست، ولی تطابق نیست

اینجا پرسش واقعاً انجام شده و جواب matched: false است. تمام فیلدهای هویتی null برمی‌گردند. مهم‌ترین نکته: این یک پاسخ معتبر است، نه خطا. هزینه دارد، چون سرویس مرجع پرسیده شده است.

علت‌ها:

• تاریخ تولد دقیقاً همان نیست. رایج‌ترین علت. کاربر تاریخ تولدی را که از ذهنش یا از کارت دیگری می‌گوید وارد می‌کند، و ممکن است با تاریخ ثبت‌شده در شناسنامه فرق داشته باشد. اگر کاربر تاریخی را به خاطر می‌آورد که با ثبت‌شده یکی نیست، ما از بیرون نمی‌توانیم این را تشخیص دهیم.
• جابه‌جایی روز و ماه. 1370/05/01 و 1370/01/05 هر دو تاریخ معتبرند و از اعتبارسنجی عبور می‌کنند، پس فقط خود پرسش خطا را نشان می‌دهد.
• کد ملی شخص دیگری (خطای تایپی که تصادفاً رقم کنترل را حفظ کرده). نادر است ولی ممکن.
• تغییر اطلاعات در پایگاه. اگر داده‌ای اخیراً اصلاح شده، ممکن است تفاوتش مدتی دیده شود. دقیق نمی‌دانم چقدر؛ آن را وعده نمی‌دهم.

از بیرون هیچ‌کدام از این‌ها از هم تفکیک نمی‌شوند. سرویس همان یک بیت را برمی‌گرداند.

حالت سوم: مشکل از طرف دیگر

گاهی پرسش را اصلاً نمی‌توان انجام داد. سرویس مرجع جواب نمی‌دهد یا زمان‌بر می‌شود. در API ما این حالت در دستهٔ «در دسترس نبود» می‌افتد، پاسخ ناموفق است، و هزینه‌ای ندارد. برای کاربر معنایش «بعداً دوباره امتحان کنید» است، نه «اطلاعات شما غلط است».

تفکیک این سه حالت در کد شما فقط به همان فیلد ok و error.code و data.matched بستگی دارد:

js if (!body.ok) { // invalid_input: ورودی را اصلاح کن (رایگان) // خطای دردسترس‌نبودن: بعداً (رایگان) } else if (body.data.matched === false) { // پاسخ معتبر و هزینه‌دار؛ ورودی را دوباره از کاربر بخواه } else { // body.data.first_name و ... }

مستندات API فهرست کامل کدها و اینکه کدام صورتحساب می‌شوند را دارد.

چرا حدس‌زدن مجاز نیست (و گران)

وسوسهٔ طبیعی این است که وقتی تطابق نشد، تاریخ را کمی عوض کنند و دوباره بفرستند. چند نکته:

1. هر تلاش یک پرسش جداگانه است. حدس‌های پشت‌سرهم یعنی چند پرسش.
2. اگر سیستم شما این کار را خودکار کند، در واقع دارد تاریخ تولد را «شکار» می‌کند. این همان رفتاری است که اجباری‌بودن تاریخ تولد برای جلوگیری از آن ساخته شده.
3. سرویس‌دهنده ممکن است تلاش‌های مکرر برای یک کد ملی را غیرعادی ببیند. چه واکنشی نشان بدهد را از اینجا نمی‌دانم.

پیشنهاد من: حداکثر دو تلاش برای هر کد ملی در یک نشست، و پیام روشن به کاربر که «تاریخ تولد را همان‌طور که در شناسنامه ثبت است وارد کنید».

کمک به کاربر در فرم

قبل از ارسال، فرم می‌تواند خیلی از حالت‌های اول و دوم را کم کند:

• از تقویم شمسی استفاده کنید، نه از <input type="date"> که معمولاً میلادی است.
• ماه را با نام نشان بدهید (فروردین، اردیبهشت…) تا جابه‌جایی روز و ماه کم شود.
• بعد از پر شدن، تاریخ را به‌صورت خوانا نشان بدهید: «۵ فروردین ۱۳۷۰» و بپرسید درست است؟
• کد ملی را همان لحظه با رقم کنترل بسنجید.

این‌ها هزینه‌ای ندارند و پرسش‌های بی‌دلیل را از بین می‌برند.

یک سناریوی فرضی

تصور کنید یک اپلیکیشن بیمه کاربر را با کد ملی و تاریخ تولد ثبت می‌کند. کاربری تاریخ تولدش را از روی گواهینامه یا پروفایل شبکهٔ اجتماعی‌اش وارد می‌کند. پاسخ matched: false می‌آید. اپلیکیشن دو انتخاب دارد.

انتخاب بد: «کد ملی نامعتبر است». غلط است و کاربر را به کد ملی‌ای که درست است شک می‌اندازد.

انتخاب خوب: «تاریخ تولد با کد ملی نخواند. تاریخ را همان‌طور که در شناسنامه است وارد کنید.» و کنارش یک نمونهٔ قالب. کاربر بعد از نگاه به شناسنامه معمولاً مشکل را خودش پیدا می‌کند.

تفاوت این دو پیام، تفاوت یک تیکت پشتیبانی و یک ثبت‌نام موفق است.

چه چیزی به پشتیبانی بدهید

وقتی کاربری با پشتیبانی تماس می‌گیرد که «استعلام نشد»، پشتیبان باید سه چیز ببیند، نه بیشتر: کدام حالت از سه حالت بالا، زمان درخواست، و requestId که در پاسخ API هست. کد ملی کامل و تاریخ تولد را در پنل پشتیبانی نشان ندهید. با requestId می‌توان پرسش را پی گرفت، و ورودی‌ها را همان کاربر می‌تواند دوباره بگوید.

رویه‌ای ساده: اگر حالت دوم است و کاربر مطمئن است ورودی درست است، راهنمایی کنید که اطلاعاتش را با شناسنامه یا کارت ملی خودش مقایسه کند. از شما کاری برنمی‌آید که تاریخ ثبت‌شده را عوض کند، و نباید وانمود کنید برمی‌آید.

آنچه این سرویس نمی‌کند

• نمی‌گوید کدام فیلد اشتباه است، فقط اینکه جفت نمی‌خواند.
• برای کسی که تاریخ تولدش را نمی‌داند، راه جایگزین ندارد.
• شخص را «پیدا» نمی‌کند: کد ملی را بدون تاریخ تولد نمی‌پذیرد.
• مرجع قضاوت درباره هویت نیست؛ یک بررسی تطابق است. تصمیم نهایی با جریان شماست.

اگر هدفتان فقط بررسی تعلق یک موبایل به کد ملی است، شاهکار ورودی کمتری می‌خواهد و تاریخ تولد نمی‌گیرد.

پیشنهاد من

در استعلام اطلاعات هویتی پیش از اینکه پاسخ «نتیجه‌ای نیامد» را به کاربر نشان بدهید، بپرسید کدام یک از سه حالت است. ورودی بدشکل را در فرم بگیرید، تطابق‌نیافتن را یک پاسخ معتبر بدانید و تعداد تلاش را محدود کنید، و خرابی را به حساب کاربر ننویسید.