حل مشکل اعتبارسنجی اعداد فارسی در فرم های وب

در بسیاری از سامانه های فارسی زبان، یکی از خطاهای پنهان اما بسیار مهم، شکست اعتبارسنجی فرم هنگام وارد کردن عدد با کیبورد فارسی است. کاربر شماره موبایل، کد ملی، کد پستی، مبلغ، شناسه پرداخت یا کد تایید را کاملا درست وارد می کند، اما سیستم آن را نامعتبر تشخیص می دهد. از نگاه کاربر، عدد ۰۹۰۲۲۲۲۳۳۰۱ با 09022223301 هیچ تفاوتی ندارد؛ هر دو یک شماره موبایل هستند. اما از نگاه JavaScript، Backend، Regex، Database و لایه های پردازش داده، این دو رشته کاملا متفاوت هستند. همین تفاوت ظاهرا کوچک، می تواند باعث خطای ثبت نام، شکست پرداخت، رد شدن احراز هویت، ثبت داده نادرست و ایجاد تجربه کاربری ضعیف شود.

مسئله فقط یک Bug ساده در Frontend نیست. این مشکل به طراحی درست جریان داده Data Flow، استاندارد سازی ورودی Input Normalization، اعتبارسنجی Validation، امنیت داده Data Integrity و تجربه کاربری User Experience مربوط می شود. اگر یک سامانه برای کاربران فارسی زبان ساخته شده باشد، باید با واقعیت رفتار کاربر فارسی زبان سازگار باشد. کاربر همیشه کیبورد خود را روی انگلیسی نمی گذارد، همیشه از اعداد لاتین استفاده نمی کند و همیشه تفاوت میان ارقام فارسی، عربی و انگلیسی را نمی داند. نرم افزار حرفه ای باید این تفاوت را بفهمد، ورودی را قبل از پردازش Normalize کند و بعد تصمیم بگیرد که داده معتبر است یا نه.

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

مسئله اصلی چیست؟

تفاوت عدد از نگاه انسان و ماشین

انسان عدد را بر اساس شکل ظاهری می خواند. وقتی کاربر فارسی زبان عدد ۰ را می بیند، آن را صفر می داند. وقتی عدد 0 را می بیند، باز هم آن را صفر می داند. اما کامپیوتر با شکل ظاهری کار نمی کند؛ کامپیوتر با Code Point کار می کند. در استاندارد Unicode، رقم انگلیسی 0، رقم فارسی ۰ و رقم عربی ٠ سه کاراکتر متفاوت هستند. یعنی ممکن است هر سه از نظر معنایی صفر باشند، اما در حافظه، در Regex، در مقایسه رشته ای String Comparison و در اعتبارسنجی، یکسان محسوب نمی شوند.

این تفاوت زمانی مشکل ساز می شود که توسعه دهنده برای اعتبارسنجی عددی از الگوهایی مثل \d یا [0-9] استفاده می کند. در بسیاری از سناریوهای JavaScript، این الگوها عملا اعداد انگلیسی را پوشش می دهند و اعداد فارسی یا عربی را نمی پذیرند. بنابراین اگر کاربر شماره موبایل را به صورت ۰۹۰۲۲۲۲۳۳۰۱ وارد کند، Regex ممکن است آن را رد کند، در حالی که اگر همان مقدار را به صورت 09022223301 وارد کند، تایید می شود.

چرا این مشکل در پروژه های فارسی زیاد دیده می شود؟

بخش بزرگی از پروژه های فارسی زبان با الگوهای عمومی انگلیسی محور توسعه داده می شوند. فرم ها از Template های آماده Bootstrap، Validation Library های عمومی، Regex های Stack Overflow و Snippet های انگلیسی استفاده می کنند. این ابزارها ذاتا بد نیستند، اما برای محیط فارسی باید Localize و Adapt شوند. اگر این مرحله انجام نشود، سیستم فقط در حالت ایده آل کار می کند؛ یعنی زمانی که کاربر با کیبورد انگلیسی عدد وارد کند.

در دنیای واقعی، کاربران با موبایل وارد سایت می شوند، کیبورد آنها فارسی است، اعداد فارسی تایپ می کنند، گاهی از اعداد عربی استفاده می شود، گاهی فاصله اضافی در ورودی می آید و گاهی مرورگر یا سیستم عامل شکل اعداد را بر اساس Locale نمایش می دهد. سامانه حرفه ای باید این ورودی ها را قبل از Validation یکدست کند. این مرحله را Input Normalization می نامیم؛ یعنی تبدیل داده ورودی به یک شکل استاندارد و قابل پردازش.

نمونه سناریو: فرم ثبت نام فارسی

فرض کنید یک فرم ثبت نام دارید که از کاربر نام، شماره موبایل و کد ملی دریافت می کند. کاربر شماره موبایل خود را به صورت ۰۹۰۲۲۲۲۳۳۰۱ وارد می کند. این شماره از نظر کاربر درست است، اما Regex شما فقط این الگو را قبول می کند:

/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/
const mobileRegex = /^09[0-9]{9}$/;

console.log(mobileRegex.test('09022223301'));
console.log(mobileRegex.test('۰۹۰۲۲۲۲۳۳۰۱'));

در این مثال، مقدار انگلیسی تایید می شود، اما مقدار فارسی رد می شود. این رفتار از نظر فنی قابل توضیح است، اما از نظر محصول Product و تجربه کاربری UX اشتباه است. کاربر عدد صحیح وارد کرده و سیستم نباید او را به خاطر نوع کیبورد تنبیه کند. هدف Validation باید تشخیص صحت داده باشد، نه تحمیل عادت تایپ انگلیسی به کاربر فارسی زبان.

همین مسئله در کد ملی نیز دیده می شود. الگوریتم اعتبارسنجی کد ملی ایران بر پایه محاسبه Checksum کار می کند. اگر ورودی قبل از محاسبه به اعداد استاندارد انگلیسی تبدیل نشود، عملیات Split، Number Conversion، Regex و محاسبه رقم کنترل Control Digit ممکن است شکست بخورد یا نتیجه نادرست تولید کند.

اصل طلایی: اول Normalize، بعد Validate

چرا ترتیب عملیات مهم است؟

در فرم های حرفه ای، اعتبارسنجی مستقیم روی ورودی خام Raw Input اشتباه است. ورودی خام باید ابتدا پاکسازی Sanitization و استاندارد سازی Normalization شود، سپس روی مقدار استاندارد شده Validation انجام شود. این اصل در بسیاری از حوزه های مهندسی نرم افزار کاربرد دارد. در امنیت سایبری Cybersecurity نیز پردازش مستقیم داده خام یکی از منابع جدی خطا، دور زدن قوانین و ناسازگاری های امنیتی است.

وقتی کاربر مقدار ۰۹۰۲۲۲۲۳۳۰۱ را وارد می کند، سیستم باید ابتدا فاصله های اضافی را حذف کند، اعداد فارسی را به اعداد انگلیسی تبدیل کند، اعداد عربی را هم پوشش دهد و سپس بررسی کند که آیا مقدار نهایی با 09 شروع شده و 11 رقم است یا نه. اگر این ترتیب رعایت نشود، Validation هم برای کاربر آزاردهنده می شود و هم برای توسعه دهنده منبع خطای دائمی خواهد بود.

تفاوت Normalization با Validation

Normalization یعنی تبدیل ورودی های متفاوت اما هم معنا به یک قالب واحد. مثلا ۰۹۰۲۲۲۲۳۳۰۱، ٠٩٠٢٢٢٢٣٣٠١ و 09022223301 باید در نهایت به 09022223301 تبدیل شوند. اما Validation یعنی بررسی اینکه مقدار استاندارد شده از نظر قواعد کسب و کار Business Rules معتبر است یا نه. برای شماره موبایل ایران، مقدار باید با 09 شروع شود و 11 رقم داشته باشد. برای کد ملی، علاوه بر 10 رقمی بودن، باید Checksum نیز معتبر باشد.

این تفکیک بسیار مهم است. اگر Normalization و Validation را با هم قاطی کنیم، کد پیچیده، آسیب پذیر و غیر قابل نگهداری می شود. معماری درست این است که ابتدا یک تابع مستقل برای تبدیل اعداد فارسی و عربی به انگلیسی داشته باشیم، سپس از آن تابع در همه Validator ها استفاده کنیم.

پیاده سازی استاندارد در JavaScript

تابع تبدیل اعداد فارسی و عربی به انگلیسی

اولین قدم، نوشتن یک تابع قابل استفاده مجدد Reusable Function است. این تابع هر مقدار ورودی را به رشته تبدیل می کند، فاصله های ابتدا و انتها را حذف می کند، ارقام فارسی و عربی را به ارقام انگلیسی تبدیل می کند و در نهایت مقدار استاندارد شده را بر می گرداند.

/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/
function normalizeDigits(value) {
    return String(value ?? '')
        .trim()
        .replace(/[۰-۹]/g, function (digit) {
            return String(digit.charCodeAt(0) - 1776);
        })
        .replace(/[٠-٩]/g, function (digit) {
            return String(digit.charCodeAt(0) - 1632);
        });
}

این تابع پایه بسیاری از Validator های فارسی است. بهتر است آن را در یک فایل Utility عمومی مثل input-normalizer.js قرار دهید تا در بخش های مختلف پروژه تکرار نشود. تکرار منطق Normalization در چند فایل مختلف، در آینده باعث ناسازگاری و خطا می شود. هرجا که شماره موبایل، کد ملی، کد پستی، مبلغ، شناسه عددی یا OTP دارید، باید قبل از Validation از همین تابع استفاده شود.

اعتبارسنجی شماره موبایل ایران

حالا می توانیم یک تابع تمیز برای اعتبارسنجی شماره موبایل ایران بنویسیم. در این مثال، شماره نمونه 09022223301 استفاده شده است. کاربر ممکن است همین شماره را با اعداد فارسی وارد کند، اما سیستم باید آن را به شکل استاندارد تبدیل کند و بعد بررسی کند.

/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/
function isValidIranMobileNumber(input) {
    const mobile = normalizeDigits(input);
    return /^09[0-9]{9}$/.test(mobile);
}

console.log(isValidIranMobileNumber('09022223301'));
console.log(isValidIranMobileNumber('۰۹۰۲۲۲۲۳۳۰۱'));
console.log(isValidIranMobileNumber('٠٩٠٢٢٢٢٣٣٠١'));

این الگو ساده، خوانا و قابل اتکا است. نکته مهم این است که Regex فقط روی مقدار استاندارد شده اجرا می شود. بنابراین دیگر مهم نیست کاربر با چه کیبوردی عدد را وارد کرده است. سیستم همیشه یک مقدار Canonical دریافت می کند و بر اساس همان مقدار تصمیم می گیرد.

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

کد ملی ایران فقط یک عدد 10 رقمی نیست. بسیاری از رشته های 10 رقمی، از نظر ساختار کد ملی معتبر نیستند. اعتبارسنجی درست کد ملی باید چند شرط را بررسی کند: مقدار باید دقیقا 10 رقم باشد، همه ارقام نباید یکسان باشند، و رقم کنترل Control Digit باید با نتیجه الگوریتم Checksum مطابقت داشته باشد.

/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/
function isValidIranNationalId(input) {
    const code = normalizeDigits(input);

    if (!/^[0-9]{10}$/.test(code)) {
        return false;
    }

    if (/^([0-9])\1{9}$/.test(code)) {
        return false;
    }

    const digits = code.split('').map(Number);
    const controlDigit = digits[9];

    let sum = 0;

    for (let i = 0; i < 9; i++) {
        sum += digits[i] * (10 - i);
    }

    const remainder = sum % 11;
    const expectedControlDigit = remainder < 2 ? remainder : 11 - remainder;

    return controlDigit === expectedControlDigit;
}

در اینجا هم اصل مهم همان است: قبل از هر بررسی، ورودی Normalize می شود. این باعث می شود تابع برای اعداد انگلیسی، فارسی و عربی یک رفتار یکسان داشته باشد. از نظر مهندسی، چنین تابعی قابل تست Unit Test، قابل استفاده مجدد و قابل نگهداری است.

اتصال به فرم HTML

انتخاب درست نوع input

یکی از اشتباهات رایج، استفاده از type="number" برای شماره موبایل، کد ملی و کد پستی است. این کار ظاهرا منطقی است، اما در عمل می تواند مشکل ایجاد کند. شماره موبایل و کد ملی عدد محاسباتی نیستند؛ Identifier هستند. یعنی قرار نیست روی آنها عملیات ریاضی انجام شود. شماره موبایل باید صفر اول خود را حفظ کند و کد ملی نیز باید دقیقا به همان طول ثبت شود. بنابراین برای این نوع داده ها، type="text" انتخاب درست تری است.

<input
    type="text"
    name="mobile_number"
    id="mobile_number"
    inputmode="numeric"
    maxlength="11"
    autocomplete="tel"
    placeholder="شماره موبایل را وارد کنید" />

استفاده از inputmode="numeric" باعث می شود در موبایل، کیبورد عددی نمایش داده شود، بدون اینکه محدودیت های مشکل ساز type="number" به ورودی تحمیل شود. این یک تصمیم کوچک اما حرفه ای در طراحی فرم است. کاربر تجربه بهتری دریافت می کند و توسعه دهنده کنترل بیشتری روی پردازش مقدار خواهد داشت.

تبدیل مقدار هنگام تایپ

در برخی پروژه ها بهتر است عدد فارسی همان لحظه به عدد انگلیسی تبدیل شود. این روش برای فرم هایی مناسب است که مقدار نهایی باید در ظاهر نیز به شکل استاندارد نمایش داده شود. البته باید مراقب بود این رفتار برای کاربر ناگهانی و آزاردهنده نباشد. در فرم های حساس مثل پرداخت و احراز هویت، تبدیل لحظه ای معمولا قابل قبول است، زیرا به وضوح و کاهش خطا کمک می کند.

/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/
const mobileInput = document.querySelector('#mobile_number');

if (mobileInput) {
    mobileInput.addEventListener('input', function () {
        const normalizedValue = normalizeDigits(mobileInput.value);

        if (mobileInput.value !== normalizedValue) {
            mobileInput.value = normalizedValue;
        }
    });
}

این کد ساده باعث می شود کاربر حتی اگر با کیبورد فارسی تایپ کند، مقدار داخل فرم به عدد انگلیسی تبدیل شود. با این حال، نباید فقط به این تبدیل ظاهری اعتماد کرد. کاربر می تواند JavaScript را غیرفعال کند، درخواست را دستی ارسال کند یا از کلاینت غیر مرورگری استفاده کند. بنابراین Backend نیز باید همین منطق را اجرا کند.

اعتبارسنجی در Backend

چرا Frontend کافی نیست؟

Frontend برای تجربه کاربری UX عالی است، اما مرجع نهایی امنیت و صحت داده نیست. هر Validation که فقط در مرورگر اجرا شود، قابل دور زدن است. کاربر می تواند Request را مستقیم با ابزارهایی مثل Postman، Burp Suite، curl یا حتی DevTools تغییر دهد. از نگاه امنیت نرم افزار Application Security، Backend باید همیشه ورودی را مستقل از Frontend بررسی کند.

اگر Frontend عدد فارسی را Normalize کند اما Backend این کار را انجام ندهد، همچنان احتمال ثبت داده ناسازگار وجود دارد. ممکن است API از مسیر دیگری فراخوانی شود، اپلیکیشن موبایل جداگانه ای به همان Backend وصل باشد یا یک Integration خارجی داده ارسال کند. بنابراین Normalization باید در مرز ورود داده به Backend نیز انجام شود.

نمونه پیاده سازی در PHP

در بسیاری از پروژه های فارسی، Backend با PHP یا Laravel پیاده سازی می شود. نمونه زیر یک تابع ساده برای تبدیل اعداد فارسی و عربی به انگلیسی در PHP است. این تابع می تواند قبل از Validation یا داخل Request Class استفاده شود.

<?php
/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/

function normalize_digits($value): string
{
    $persianDigits = ['۰','۱','۲','۳','۴','۵','۶','۷','۸','۹'];
    $arabicDigits = ['٠','١','٢','٣','٤','٥','٦','٧','٨','٩'];
    $englishDigits = ['0','1','2','3','4','5','6','7','8','9'];

    $value = trim((string) $value);
    $value = str_replace($persianDigits, $englishDigits, $value);
    $value = str_replace($arabicDigits, $englishDigits, $value);

    return $value;
}

$mobile = normalize_digits('۰۹۰۲۲۲۲۳۳۰۱');

if (preg_match('/^09[0-9]{9}$/', $mobile)) {
    echo 'Valid mobile number';
}

در Laravel بهتر است این منطق قبل از اجرای Rule های اصلی انجام شود. مثلا می توان در Form Request و متد prepareForValidation مقدار ورودی را Normalize کرد. این روش باعث می شود تمام Rule های بعدی روی مقدار استاندارد شده اجرا شوند و کد تمیزتر بماند.

<?php
/*
-------------------------------------------------------------------
Programmer       : Ebrahim Shafiei (EbraSha)
Email                     : [email protected]
-------------------------------------------------------------------
*/

protected function prepareForValidation(): void
{
    $this->merge([
        'mobile_number' => normalize_digits($this->input('mobile_number')),
        'national_id' => normalize_digits($this->input('national_id')),
    ]);
}

این معماری بسیار بهتر از آن است که در هر Controller به صورت پراکنده مقدار را اصلاح کنیم. Controller باید مسئول اجرای منطق کسب و کار باشد، نه اصلاح تکراری ورودی ها. Normalization باید در لایه ورودی Request Layer انجام شود تا همه مسیرهای بعدی داده استاندارد دریافت کنند.

امنیت و کیفیت داده

Normalization و Data Integrity

وقتی داده ها قبل از ذخیره Normalize نشوند، ممکن است در Database چند شکل مختلف از یک مقدار واحد داشته باشید. برای مثال شماره 09022223301 ممکن است یک بار با اعداد انگلیسی، یک بار با اعداد فارسی و یک بار با اعداد عربی ذخیره شود. از نظر کاربر هر سه یکی هستند، اما از نظر Database متفاوتند. در نتیجه جستجو، Unique Constraint، تشخیص حساب تکراری، گزارش گیری و اتصال داده ها دچار مشکل می شود.

اگر ستون شماره موبایل Unique باشد اما یک کاربر بتواند یک بار با 09022223301 و یک بار با ۰۹۰۲۲۲۲۳۳۰۱ ثبت نام کند، سیستم شما از نظر منطق هویت Identity Logic دچار نقص است. این نقص ممکن است فقط یک خطای ساده محصولی نباشد؛ در برخی سیستم ها می تواند به سوء استفاده، چند حسابی شدن، دور زدن محدودیت ها و اختلال در احراز هویت منجر شود.

Normalization و امنیت سایبری

در امنیت سایبری، یکی از مفاهیم مهم، Canonicalization است. یعنی قبل از تصمیم گیری امنیتی، داده باید به فرم استاندارد و یکتا تبدیل شود. اگر سیستم روی داده غیر استاندارد تصمیم امنیتی بگیرد، مهاجم ممکن است با استفاده از نمایش های مختلف یک داده، قوانین را دور بزند. این اصل در مسیر فایل File Path، URL، Encoding، HTML Entity، Unicode و همچنین اعداد محلی کاربرد دارد.

در مورد فرم های فارسی، ممکن است خطر به اندازه حملات کلاسیک مثل SQL Injection یا XSS آشکار نباشد، اما از نظر کنترل هویت، محدودیت ثبت نام، Rate Limit، OTP و Anti Fraud بسیار مهم است. اگر سیستم شماره موبایل را در یک قسمت Normalize کند و در قسمت دیگر نه، ممکن است رفتارهای متناقض ایجاد شود. امنیت پایدار از همین جزئیات ساخته می شود.

طراحی تجربه کاربری بهتر

پیام خطای درست

اگر کاربر عدد فارسی وارد کرده و سیستم آن را رد کند، پیام خطای «شماره موبایل نامعتبر است» برای او ناعادلانه و گیج کننده است. از نگاه کاربر، شماره درست است. بنابراین بهتر است سیستم اصلا چنین خطایی ایجاد نکند و خودش ورودی را Normalize کند. اگر بعد از Normalization مقدار همچنان نامعتبر بود، آن وقت پیام خطا باید دقیق و قابل فهم باشد.

پیام خوب باید به کاربر بگوید مشکل چیست، نه اینکه فقط او را متهم به اشتباه کند. مثلا برای شماره موبایل می توان نوشت: «شماره موبایل باید با 09 شروع شود و 11 رقم داشته باشد». این پیام از نظر فنی واضح است و کاربر را به مسیر اصلاح هدایت می کند. برای کد ملی نیز می توان نوشت: «کد ملی باید 10 رقم باشد و از نظر ساختار معتبر باشد».

جلوگیری از خطا به جای نمایش خطا

طراحی حرفه ای فرم فقط نمایش Error Message نیست. هدف بهتر این است که تا حد امکان از وقوع خطا جلوگیری شود. inputmode="numeric"، maxlength، تبدیل اعداد فارسی به انگلیسی، حذف فاصله اضافی و نمایش Placeholder مناسب، همه در همین مسیر قرار می گیرند. این کارها فشار ذهنی Cognitive Load کاربر را کم می کنند و نرخ تکمیل فرم Conversion Rate را افزایش می دهند.

در محصولات فارسی زبان، جزئیات Locale بسیار مهم است. اگر کاربر فارسی زبان حس کند سیستم زبان و رفتار او را می فهمد، اعتماد بیشتری به محصول پیدا می کند. اعتماد در نرم افزار فقط با شعار امنیت و طراحی زیبا ساخته نمی شود؛ اعتماد از تجربه های کوچک و درست شکل می گیرد.

الگوی پیشنهادی برای پروژه های حرفه ای

لایه بندی درست پردازش ورودی

برای حل اصولی این مشکل، بهتر است یک استاندارد داخلی برای پردازش ورودی های عددی تعریف شود. این استاندارد باید مشخص کند که همه ورودی های عددی محلی قبل از Validation و قبل از ذخیره در Database، Normalize شوند. همچنین باید مشخص شود کدام فیلدها Identifier هستند و نباید با type="number" پیاده سازی شوند.

یک الگوی سالم می تواند این باشد: در Frontend، ورودی هنگام تایپ یا هنگام Submit Normalize شود. سپس Validator های Client Side روی مقدار استاندارد شده اجرا شوند. در Backend، مقدار دوباره در Request Layer Normalize شود. سپس Rule های Backend اجرا شوند. در نهایت مقدار استاندارد شده در Database ذخیره شود. این مسیر باعث می شود سیستم در برابر خطای کاربر، تفاوت مرورگر و ارسال مستقیم Request مقاوم باشد.

تست کردن سناریوهای واقعی

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

در سطح Unit Test، باید تابع Normalization مستقل تست شود. در سطح Integration Test، باید ارسال فرم با ورودی فارسی بررسی شود. در سطح E2E Test، باید رفتار واقعی کاربر در مرورگر تست شود. این سطح از دقت، تفاوت میان یک فرم معمولی و یک فرم حرفه ای را مشخص می کند.

خطاهای رایج توسعه دهندگان

اعتماد کامل به Regex

Regex ابزار قدرتمندی است، اما اگر روی ورودی خام اجرا شود، نتیجه قابل اعتماد نیست. توسعه دهنده باید بداند Regex فقط بخشی از فرآیند Validation است، نه کل آن. برای داده های محلی Localized Data، Regex باید بعد از Normalization اجرا شود. در غیر این صورت، ممکن است مقدار درست را رد کند یا در شرایط خاص مقدار نادرست را بپذیرد.

استفاده اشتباه از type number

همانطور که گفته شد، شماره موبایل، کد ملی، کد پستی و شناسه ها عدد ریاضی نیستند. اگر داده ای با صفر شروع می شود، طول ثابت دارد و قرار نیست روی آن جمع و تفریق انجام شود، بهتر است آن را به عنوان String مدیریت کنید. این نگاه در طراحی Database نیز مهم است. ستون شماره موبایل نباید صرفا به خاطر عددی بودن ظاهری، عددی ذخیره شود. ذخیره به صورت String کنترل دقیق تر و رفتار قابل پیش بینی تری می دهد.

فقط اصلاح Frontend

یکی دیگر از خطاهای رایج این است که تیم فقط در JavaScript مشکل را حل می کند. این کار UX را بهتر می کند، اما امنیت و یکپارچگی داده را تضمین نمی کند. Backend باید همیشه مستقل و سخت گیر باشد. اگر Backend داده خام را بپذیرد، هر کلاینت دیگری می تواند داده ناسازگار وارد سیستم کند.

اصل حرفه ای این است: Frontend برای راحتی کاربر، Backend برای حقیقت سیستم.