التحقق من صحة البيانات في نماذج HTML: كيف تفحص إدخالات المستخدم باستخدام JavaScript

مقدمة: لماذا يُعد التحقق من صحة البيانات ضرورياً؟

تُستخدم النماذج في معظم تطبيقات الويب، سواء لتسجيل المستخدمين، أو إتمام عمليات الشراء، أو إرسال طلبات التمويل، أو حتى طلب وجبة عبر الإنترنت. وبما أن هذه النماذج تستقبل بيانات مباشرة من المستخدم، فمن الضروري التأكد من أن تلك البيانات صحيحة، ومنسقة بالشكل المطلوب، وخالية من أي مدخلات خبيثة قد تؤثر في النظام.

تُعرف هذه العملية باسم Form Validation، وهي خطوة أساسية كلما طُلب من المستخدم إدخال بيانات. فالتحقق لا يقتصر على التأكد من أن الحقل ليس فارغاً فقط، بل يشمل أيضاً فحص نوع البيانات، وصيغتها، وحدودها المقبولة، والتأكد من عدم احتوائها على شيفرات ضارة قد تؤدي إلى هجمات مثل SQL Injection أو إلى أخطاء عند التعامل مع API.

ما المقصود بالتحقق من صحة النماذج؟

التحقق من صحة النماذج هو آلية تهدف إلى التأكد من أن البيانات المُدخلة:

• مكتوبة بالتنسيق الصحيح.
• ضمن النطاق المسموح به، مثل التواريخ أو الأرقام.
• تطابق نوع البيانات المتوقع، مثل البريد الإلكتروني أو رقم الهاتف.
• لا تحتوي على مدخلات ضارة أو غير صالحة.

هذه الخطوة تحسن جودة البيانات، وتقلل الأخطاء البرمجية، وتمنح المستخدم تجربة أكثر وضوحاً وسلاسة.

أنواع التحقق من صحة البيانات في النماذج

التحقق على جهة العميل Client-Side Validation

يحدث هذا النوع داخل المتصفح قبل إرسال النموذج إلى الخادم. وغالباً ما يتم باستخدام خصائص HTML5 أو عبر JavaScript. ميزته الأساسية أنه يمنح المستخدم ملاحظات فورية، مثل رسالة تخبره أن البريد الإلكتروني غير صالح بمجرد كتابته.

التحقق على جهة الخادم Server-Side Validation

يحدث هذا النوع بعد إرسال النموذج إلى الخادم. ويُستخدم عادة عندما تحتاج العملية إلى تحقق أعمق، مثل فحص صلاحية بطاقة ائتمان أو مطابقة البيانات مع قواعد العمل الداخلية. قد يرى المستخدم شاشة تحميل قصيرة ثم تظهر رسالة خطأ بعد انتهاء الفحص.

ورغم أهمية التحقق في جهة العميل، فإنه لا يكفي وحده، لأن المستخدم أو المهاجم يمكنه تجاوزه بسهولة. لذلك يبقى التحقق على جهة الخادم إلزامياً في أي تطبيق جاد.

ما البيانات التي يجب التحقق منها؟

ينبغي التحقق من أي قيمة يرسلها المستخدم تقريباً، ومن أبرز الأمثلة:

• تنسيق الحقول مثل البريد الإلكتروني، رقم الهاتف، الرمز البريدي، الاسم، وكلمة المرور.
• الحقول الإلزامية التي لا يجوز تركها فارغة.
• نوع البيانات، مثل التمييز بين string وnumber.
• القيم المقبولة منطقياً، مثل الدولة أو التاريخ أو النطاق العددي.

كيفية إعداد التحقق على جهة العميل

يمكن تنفيذ التحقق على جهة العميل بطريقتين أساسيتين:

1. باستخدام إمكانات HTML5 المدمجة.
2. باستخدام JavaScript.

التحقق باستخدام خصائص HTML5

توفر HTML5 مجموعة من السمات المدمجة التي تسهّل التحقق من صحة الحقول دون كتابة الكثير من الشيفرة. من أبرز هذه السمات:

• required لجعل الحقل إلزامياً.
• minlength وmaxlength لتقييد طول النص.
• min وmax لتحديد الحدين الأدنى والأقصى في الحقول الرقمية.
• type لتحديد نوع البيانات مثل email أو number.
• pattern لفرض نمط معين باستخدام تعبيرات منتظمة Regex.

عندما تكون قيمة الحقل صحيحة، يحصل العنصر على الحالة :valid، وعندما تكون غير صحيحة يحصل على :invalid.

مثال عملي باستخدام HTML5

<form>
  <label for="firstname">First Name:</label>
  <input type="text" name="firstname" id="firstname" required maxlength="45">

  <label for="lastname">Last Name:</label>
  <input type="text" name="lastname" id="lastname" required maxlength="45">

  <button>Submit</button>
</form>

في هذا المثال، الحقلان First Name وLast Name إلزاميان. إذا حاول المستخدم إرسال النموذج قبل ملئهما، فسيعرض المتصفح رسالة تنبيه تلقائية تفيد بضرورة تعبئة الحقل.

التحقق باستخدام JavaScript

عند بناء نظام تحقق مخصص باستخدام JavaScript، هناك أسئلة مهمة يجب الإجابة عنها قبل كتابة الشيفرة:

• ما تعريف البيانات الصحيحة في هذا النموذج؟
• هل هناك طول أدنى أو أقصى؟
• هل الحقل إلزامي؟
• كيف ستظهر رسالة الخطأ للمستخدم؟
• هل سيتم منع الإرسال بالكامل أم السماح به في حالات معينة؟

يمكن استخدام JavaScript بطريقتين شائعتين:

1. التحقق المباشر داخل الواجهة Inline Validation.
2. الاعتماد على Constraint Validation API الخاصة بالمتصفح.

مثال على التحقق المباشر باستخدام JavaScript

<form id="form">
  <label for="firstname">First Name*</label>
  <input type="text" name="firstname" id="firstname" />
  <button id="submit">Submit</button>
  <span role="alert" id="nameError" aria-hidden="true">
    Please enter First Name
  </span>
</form>

const submit = document.getElementById("submit");
submit.addEventListener("click", validate);

function validate(e) {
  e.preventDefault();
  const firstNameField = document.getElementById("firstname");
  let valid = true;

  if (!firstNameField.value) {
    const nameError = document.getElementById("nameError");
    nameError.classList.add("visible");
    firstNameField.classList.add("invalid");
    nameError.setAttribute("aria-hidden", false);
    nameError.setAttribute("aria-invalid", true);
  }

  return valid;
}

#nameError {
  display: none;
  font-size: 0.8em;
}

#nameError.visible {
  display: block;
}

input.invalid {
  border-color: red;
}

في هذا المثال، يتم التحقق من وجود قيمة داخل الحقل المطلوب. وإذا تُرك فارغاً، تُعرض رسالة خطأ مباشرة بجانب الحقل، مع إضافة تنسيق بصري يوضح المشكلة للمستخدم. كما تُستخدم خصائص ARIA لتحسين الوصول لبرامج قراءة الشاشة، وهو جانب مهم في تجربة المستخدم والامتثال لمعايير الوصول.

استخدام Constraint Validation API لرسائل أكثر دقة

رغم أن السمات مثل required وpattern مناسبة للحالات الأساسية، فإن التطبيقات المتقدمة تحتاج أحياناً إلى رسائل مخصصة وسلوك أكثر مرونة. هنا يأتي دور Constraint Validation API.

من أهم الدوال التي توفرها هذه الواجهة:

• checkValidity()
• setCustomValidity()
• reportValidity()

ومن الخصائص المفيدة أيضاً:

• validity
• validationMessage
• willValidate

مثال عملي على التحقق برسالة مخصصة

<form>
  <label for="firstname">First Name:</label>
  <input type="text" name="firstname" required id="firstname">
  <button>Submit</button>
</form>

const nameField = document.querySelector("input");

nameField.addEventListener("input", () => {
  nameField.setCustomValidity("");
  nameField.checkValidity();
  console.log(nameField.checkValidity());
});

nameField.addEventListener("invalid", () => {
  nameField.setCustomValidity("Please fill in your First Name.");
});

في هذا المثال، يتم مسح رسالة الخطأ المخصصة عند الكتابة داخل الحقل، ثم يُعاد فحص حالته. وإذا حاول المستخدم إرسال النموذج وهو غير صالح، تُعرض رسالة مخصصة أكثر وضوحاً من الرسالة الافتراضية.

لماذا لا يكفي التحقق على جهة العميل فقط؟

التحقق داخل المتصفح مهم لتحسين التجربة وتسريع اكتشاف الخطأ، لكنه ليس حاجزاً أمنياً حقيقياً. يمكن لأي مستخدم متقدم أو أداة آلية تجاوز فحوصات JavaScript أو تعديل الطلب قبل إرساله. لذلك يجب دائماً فحص البيانات مجدداً على الخادم.

يفيد التحقق على جهة الخادم في:

• منع تمرير بيانات خبيثة أو معدلة.
• فرض قواعد العمل الحقيقية التي لا ينبغي كشفها في الواجهة.
• ضمان سلامة البيانات قبل تخزينها في قاعدة البيانات.
• تقليل أخطاء التكامل مع الخدمات الخارجية وواجهات API.

أفضل ممارسات التحقق من صحة النماذج

• احرص دائماً على وجود تحقق على جهة الخادم، حتى لو كان التحقق على جهة العميل ممتازاً.
• اعرض رسالة الخطأ بالقرب من الحقل الذي تسبب بالمشكلة.
• اجعل الرسائل واضحة ومباشرة وتشرح المطلوب بدقة.
• قدّم مثالاً صحيحاً عند الحاجة، مثل: test@example.com.
• حدّد الحقول الإلزامية بشكل مرئي وواضح.
• تجنب نقل المستخدم إلى صفحة خطأ منفصلة؛ فهذا يربك التجربة ويفقده سياق النموذج.
• احرص على أن تكون ألوان ورسائل الخطأ مفهومة ومتوافقة مع معايير الوصول.

مقارنة سريعة بين أساليب التحقق

الخلاصة التقنية

التحقق من صحة بيانات النماذج ليس مجرد تحسين شكلي، بل هو جزء أساسي من الأمان وجودة البيانات وتجربة المستخدم. أفضل نهج عملي هو الجمع بين خصائص HTML5 للفحوصات السريعة، وJavaScript لتحسين التفاعل والرسائل المخصصة، ثم فرض تحقق صارم على جهة الخادم لحماية التطبيق فعلياً. كلما كان نظام التحقق واضحاً ودقيقاً وسهل الفهم، زادت موثوقية النموذج وقلت الأخطاء وارتفعت فرص نجاح التحويلات داخل الموقع.