اعتبارسنجی اطلاعات بعد از OCR کارت ملی

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

این نوشته نشان می‌دهد بعد از دریافت خروجی سرویس OCR کارت ملی چه بررسی‌هایی را بدون هیچ استعلام اضافی انجام بدهید، و کجا باید به استعلام هویتی ارجاع بدهید. اگر دنبال علل شکست خود خواندن هستید، این فهرست را ببینید.

سه لایه، از ارزان به گران

1. بررسی محلی: ساختار هر فیلد. هزینه ندارد و فوری است.
2. تصحیح کاربر: نمایش فیلدها برای تأیید.
3. استعلام هویتی: مقایسه با پایگاه ثبت. این یکی هزینه دارد و فقط وقتی لازم است که ریسک بخواهد.

بیشتر تیم‌ها لایهٔ اول را فراموش می‌کنند و مستقیم لایهٔ سوم را می‌خرند. نتیجه‌اش پرداخت برای فراخوانی است که یک خطای ساختاری ساده آن را بی‌معنی می‌کرد.

کد ملی: رقم کنترلی

کد ملی ایرانی ده رقم دارد و رقم دهم کنترلی است. الگوریتم پرکاربرد عمومی است:

ts function isValidNationalId(code: string): boolean { if (!/^\d{10}$/.test(code)) return false; if (/^(\d)\1{9}$/.test(code)) return false; const sum = [...code.slice(0, 9)] .reduce((acc, d, i) => acc + Number(d) * (10 - i), 0); const r = sum % 11; const check = Number(code[9]); return r < 2 ? check === r : check === 11 - r; }

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

تاریخ‌ها

تاریخ تولد و تاریخ انقضا را به‌صورت جلالی بخوانید و بسنجید.

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

اشتباه رایج در این لایه: پذیرفتن ۳۰ اسفند برای هر سال. یک اعتبارسنج ساده‌نویس همین را می‌پذیرد و ردش بعداً و از سمت مرجع می‌آید.

نام‌ها

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

نمایش به کاربر

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

• کاربر سریع‌ترین کسی است که غلط را می‌بیند.
• هر اصلاح، یک داده برای شماست: اگر در یک فیلد زیاد اصلاح می‌شود، مشکل از عکس یا رابط است.

فیلدهایی که ساختارشان رد شده را خالی نکنید؛ همان را با علامت قرمز و پیام مشخص نشان دهید. «کد ملی معتبر نیست؛ ارقام را بررسی کنید» بهتر از «خطا» است.

کی استعلام هویتی لازم است

OCR می‌گوید روی کارت چه نوشته. نمی‌گوید این نوشته با پایگاه ثبت می‌خواند. اگر خدمت شما ریسک مالی یا حقوقی دارد، بعد از لایهٔ محلی و تأیید کاربر یک استعلام هویتی بزنید. اگر فقط می‌خواهید فرم ثبت‌نام را کوتاه کنید و هیچ تصمیم حساسی روی آن نیست، لایه‌های محلی شاید کافی باشند. تصمیم، تصمیم ریسک است؛ ما حکم کلی نمی‌دهیم.

پس از پایان کار: عکس و داده

پس از استخراج، دو چیز را در سیاست خودتان تعیین کنید.

• تصویر چهره در پاسخ می‌آید و بیومتریک است. در لاگ و کش نگذاریدش و پیش از ثبت از پاسخ حذف کنید.
• تصویر خود کارت را اگر لازم ندارید بعد از استخراج حذف کنید. چیزی که نگه نداشته‌اید نشت نمی‌کند. اگر مقررات صنف شما نگهداری را اجبار می‌کند، با مشاور حقوقی خودتان مشورت کنید؛ این نوشته توصیهٔ حقوقی نیست.

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

دربارهٔ خود سرویس و ورودی دو تصویرش، صفحهٔ OCR کارت ملی را ببینید.

بررسی رقم کنترلی و تاریخ جعلی بودن کارت را تشخیص نمی‌دهد. کدی که ساختارش درست است ممکن است مال شخص دیگری باشد. و OCR خودش هم هویت را احراز نمی‌کند؛ برای آن تشخیص زنده بودن چهره و استعلام هویتی راه‌های جدایی هستند. توجه: مسیر بارگذاری فایل در API فعلاً ارائه نمی‌شود و جزئیات را در صفحهٔ سرویس ببینید.

مثال: یک بار کامل

فرض کنید کاربری دو عکس فرستاده و پاسخ برگشته است. جریان پیشنهادی:

1. فیلدها را دریافت کنید و تصویر چهره را فوراً از پاسخ جدا کنید.
2. کد ملی را با تابع بالا بسنجید. رد شد؟ فقط همین فیلد را قرمز و قابل‌ویرایش نشان دهید.
3. تاریخ‌ها را بسنجید. تاریخ انقضا گذشته؟ پیام جدا، نه خطای عمومی.
4. فرم را با فیلدهای معتبر پر کنید و کاربر را مجبور به تأیید نهایی کنید.
5. فقط بعد از تأیید، اگر ریسک بالاست، استعلام هویتی بگیرید.

ترتیب مهم است. اگر استعلام هویتی را قبل از تأیید کاربر بگیرید، ممکن است برای کدی پول بدهید که او همان لحظه اصلاحش می‌کرد.

اشتباه‌های رایج

• رد کل فرایند به‌خاطر یک فیلد. کاربر باید همان فیلد را اصلاح کند.
• اعتماد به اینکه کد ملی معتبر یعنی کد ملی خودش. ساختار درست، مالکیت را ثابت نمی‌کند.
• ذخیرهٔ بی‌دلیل تصویر. اگر نمی‌خواهید، نگه ندارید.
• اجازه ندادن به ویرایش. کاربری که نمی‌تواند غلط را اصلاح کند، فرم را رها می‌کند.

مقایسه با تایپ دستی

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

لاگ و پایش بعد از OCR

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

اگر درصد ردشدن رقم کنترلی ناگهان بالا رفت، معمولاً رابط دوربین یا یک نسخهٔ اپ عوض شده است، نه این‌که موتور تغییر کرده باشد. نخست آخرین انتشار را بررسی کنید.

پیشنهاد من

اول ساختار، بعد تأیید کاربر، و فقط در صورت لزوم استعلام. این ترتیب هم ارزان‌تر است و هم کاربر را کمتر ناراحت می‌کند.